Learning Technology
publication of
IEEE Computer Society
Learning Technology Task
Force (LTTF)
Volume 4 Issue 1
ISSN 1438-0625
|
Learning Technologypublication of
IEEE Computer Society |
|
Overview
Repeatedly, news headlines read: "Buffer overflow in vendor's product allows intruders to take over computer!" This widespread programming mistake is easy to make, exacerbated by the ubiquitous C language, and very simple to exploit. The buffer overflow problem is our starting point for a security module development grant at Embry-Riddle Aeronautical University (http://nsfsecurity.pr.erau.edu/).
Embry-Riddle Aeronautical University students are self-selected for future careers in aviation engineering, intelligence studies, airlines, and the military. The initial steps in this project are targeted topics to (1) maximize current security content of the curriculum (2) assess student interest, and (3) increase faculty competence and involvement. In addition to fitting into existing curricula (1) modules should be interactive using current computing technology, (2) we should apply standard methodology for designing and evaluating instructional modules, and (3) the end results should be disseminated to other training sites.
The Buffer Overflow Module
Among programming bugs notable to the public [News], the "buffer overflow"
is vying with Y2K for top billing. A "buffer overflow" is said to occur
when a pointer (as in C) goes out of range to access memory beyond the
buffer. While Web explanations are readily accessible [IBM,RSA], traditional
textbooks do not directly address the problem. In addition, software testing
for the problem is often minimal at best.
The Buffer Overflow Module was an obvious starting point, given the
notoriety and persistence of the problem. It also fit well with our curricula,
with its first programming courses in C. Starting from an in-depth web
search that identified key papers, the undergraduate co-author developed
the Java applet demonstration prototype at http://nsfsecurity.pr.erau.edu/bom.
Our goal was to drive home the seriousness of buffer overflows. Our primary measure of understanding was that the student as a future programmer never makes a buffer overflow error and the student as future manager is able to take preventative actions and to control the effects of buffer overflow attacks. The prerequisite knowledge necessary for using the module would be about that of a beginning-programming student in C.
The purpose of the Java applet is to provide a visual and animated representation of the different concepts needed to understand buffer overflows. An abstract machine was created in Java to hide details that might hinder the student's understanding, such as the use of a specific memory architecture or assembly code. The user of the applet can be a student trying to learn about buffer overflows or a presenter using the software as a demonstration, perhaps on an overhead projector.
In the abstract machine, a C program is shown on the left. In the color Java applet, each function is a different color. Each function has a corresponding executing code segment (on the right) that is painted the same color. The line of code that is being executed is highlighted. The input and output of the program is shown in the box on the upper right. If the buffer used to store the input is overflowed then anything that comes after it in memory is overwritten. The user of the applet plays the role of the attacker and tries to find an input string that will circumvent the imaginary security measure.
Currently there are four lessons: one to demonstrate the stack structure of activation records, another to demonstrate a buffer overflow attack that overwrites data, the "stack smashing" lesson shown above, and a variation of the "stack smashing" lesson to demonstrate how one particular defense works. Developing new lessons takes very little time because of the object-oriented approach.
Module Experience and Evaluation
Effective evaluation of educational processes can involve many strategies. For interactive learning systems, evaluations are usually conducted in two phases: ongoing formative evaluations during development and a summative evaluation at the conclusion of development.
The goals of the initial analyses were to (1) better understand the preliminary level of knowledge possessed by undergraduate computer science students of the buffer overflow problem, (2) obtain student feedback on the effectiveness of a java applet in presenting the material, and (3) obtain student feedback about possible modifications or additions for best effectiveness when the applet is presented without live interaction from the applet's author.
Formative evaluations thus far reveal that most students were not aware of the details of the buffer overflow problem prior to the applet presentation in class, and students were enthusiastic about the module content and Java applet. Comments about the class presentation will be helpful in designing the module in the next steps of development.
Next Steps
The next steps in development of the Buffer Overflow Module will involve transfer of the live class presentation to a computer-based product. Our intent is to distribute the module through the Internet and on CD-ROM. The interface will be designed using authoring products such as Authorware and Flash (Macromedia). The computer-based product will build around the buffer overflow Java applet with the addition of supportive texts and detailed graphics that go beyond the capabilities of Java.
Feedback gained from the students in initial evaluations of the module will be incorporated into the authored interface, which we expect will undergo revisions as user feedback is gathered at each level of development. Evaluation of the module at the next stage will focus on assessment of the interface design and content incorporation.
References
[IBM] G. McGraw and J. Viega, Make your software behave: Learning the
basics of buffer overflows, IBM Developer Works Series
http://www-106.ibm.com/developerworks/library/overflows/
[RSA] N. Frykholm, Countermeasures against Buffer Overflow Attacks, RSA Tech Note, http://www.rsasecurity.com/rsalabs/technotes/buffer/buffer_overflow.html.
[News] A. Ackerman, Microsoft, Oracle security flaws found, Mercury
News, http://www.siliconvalley.com/docs/news/svfront/secur122101.htm
Supported by: NSF Award No. 0113627
Increasing Security Expertise in Aviation-oriented Computing Education: A Modular Approach
A more detailed version of this document is available at: http://nsfsecurity.pr.erau.edu/bom/ncisse2002.pdf
| Jedidiah R. Crandall, Susan L. Gerhart, Jan G. Hogle
Embry-Riddle Aeronautical University Prescott AZ jan@twinpinefarm.com |
