DESIGN NOTES



JAVA APPLET: Buffer Overflow

IS 2470: Interactive System Design

December 10, 2002

Submitted by: Ramakrishnan Balakrishnan, Sucai Dong, Zhiping Mi, Yeni Wang

INTRODUCTION

Applet Overview

This applet is designed to graphically simulate the occurrence of buffer overflow within a program. The simulation uses a little program with a set of global variables. As the variables are declared, the simulation shows the memory allocation, direction of memory and actual contents. The simulation then shows the variables being initialized. When one of the variables is overflowed, it shows the contents being written into the memory area of another variable. The overall design is to provide a simple and visualized interface that allows the user to see the end result of buffer overflow.

Client and Users

This topic is given by Dr. Spring and he is the client of this education applet. However, the user of this applet would be the student who is in learning certain programming language. The user is assumed to understand the basic concept of variable declaration, initialization and memory allocation in C programming language, but is not aware of the frustrating results caused by the neglected occurrences of buffer overflow in programming. Simply speaking, they are not holding a clear picture of buffer overflow when programming.

Problem Analysis

Buffer overflow problems are caused by programming errors. Buffer refers to an allocated chunk of memory, such as a pointer, array or string. In C and C++, there is no automatic bound checking on buffers, which means that it is easy for programmers to write past the end of the buffer. In our project, we simulate how improper initialization of variables and definition could result in the contents of one variable being written into the memory area of another variable. As a result, both variables get corrupted.

The corruption is physically presented in a visualized interface to the user.

REQUIREMENT

Dr. Spring is willing to set up a tool to help his student to understand the buffer overflow. The simulation should show:

1. sample source code in C,

2. print output on a console terminal,

3. memory allocation and direction,

4. variables declaration and initialization,

5. actual contents assigned to variables,

6. Contents being overwritten into the memory of other variables when one variable is overflowed.

The students would simply need to webify the application and wrap the explanatory and simulation components around. Here are his requirements on the interface:

• Explanatory material available through extended tool tips and context sensitive help.

• An animated simulation that graphically depicts the critical component being examined.

• A functioning prototype that allows students to see the end result.

• Generic interface that can be reused with little modification on the applet classes.

DESIGN PROCESS

Our first design product is a sketch that tells the interface layout and the contents description. We showed the sketch to our client and fed the feedback to our prototype establishment. Due to the short supply of analytical tool, the design group moved to a prototype early after a relatively brief analysis stage. So, our second design product is a prototype that echoed our sketched screen design and activated main designed interface features. Based on this prototype, we carried out the evaluation activities on our client and users in order to check under realistic conditions whether the design decisions we have already made were sound and to assist in making the decisions that lie ahead. We treated prototyping and evaluation as activities performed in support of our design. So in this way our following design interfaces are the products of this iterative process: the prototype was tested on users, and the results were fed into the next stage of enhancement of the design. Compared to all these interim design, the final design interface we present in this report is valued as a successful solution to the task.

PHASE I – Task and User Analysis

The goal of the final project is to utilize our knowledge of interface, interface design, evaluation and programming to develop a web-based interface that serves real users. Our group chose Buffer overflow, a project provided by Professor Michael Spring, a faculty member in the Department of Information Science and Telecommunication, School of Information Science. The general description and the requirement for the project from our client are listed in description part of this report.

We started our design process following the guidelines for task-centered design. In our first meeting with the client, our goal is to figure out WHO is going to use the system to DO what. After a short discussion with the client, we realized that the system would be used in two ways.

The End-users

Anyone that possesses the basic knowledge of a computer and programming(i.e. memory allocation, binary representation etc). The main task that the end users will perform is to be able to control the execution of the problematic sample code and see the changes in the memory area during the execution.

The Client

Dr. Spring listed the contents that should be shown in the interface. He would like to be able to re-use the system with some little modifications on the source code and he set up the general requirements to the interface.

PHASE II – Initialize Interface Design

After establishing the understanding of the users and their tasks, we started our interface design process. The group discussed the internal memory allocation and contents change with the given code. Since the key element of illustrating the buffer overflow is for users to see what's happening in the internal memory as each statement being executed, the focus of our design is to create a memory area in our interface to graphically depict the changes in memory as users step through each line of the code, an idea inspired by the well established debugging scheme.

After studying various user interfaces for similar purpose, we came up with our first draft of interface in drawing. The interface contains five areas, the code area is to show the sample code that will cause the buffer overflow, the memory area to show how overflow happens and the control area to allow users to go through each line of the code. The printing area to simulate each print statement and a status/explanation area to complement the graphical illustration of the memory area and to provide context sensitive help as requested by our client.

The following page is our original sketch. We attach it here for a kind of record of our design process.

(The original was submitted to the instructor, below is a imitated copy for the reference)

|The simulation of the buffer overflow: |

|START |

|STEPFF |

|STOP |

|RESET |

| |

|Code: |Memory and Variables: |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| |Screen Output: |

| |

|Status: |

Draft

PHASE III – Create a Prototype

We brought the draft to Dr. Spring to get feedback and comments. The layout is what he wants, but he would like it to be more integrated and intuitive. About the direction of the memory allocation and data representation methods, he left us to figure out. After reviewing of our class notes on GUI interface design, especially the discussions on the interface design for homework 4, the group started out the applet programming.

We built the interface with limited features (such as stepping through each line of the code manually and automatically) in Java. The first version of the prototype is shown here.

[pic]

The interface is made of five components: the control panel, code window, memory window, screen window and status panel. The control panel contains three buttons: Play, Step and Reset. The play button is to continually display the execution procedure of the c code. Step button allows the single step display of the execution. Reset button clears the contents and start afresh. The code window lists the complete c code to be executed. The memory window is a table of cells, which represent the memory area and is going to hold the value of the variable. The Screen window shows the actual printf()’s output. The Status window indicates the execution status.

PHASE IV – Communicate the Design With the Client

We showed this initial design prototype to Dr. Spring, who feedback the following comments:

1. Play and Step buttons are duplicated in some degree. Paired with step forward function, he strongly suggested step backward function to be included to assist the user walking through the code freely.

2. Status string needs to be expanded to more detailed explanation to help users understand the contents in other windows.

3. Screen window and status window were put in wrong places. They should be closely combined with the counterpart.

We made the following changes accordingly:

1) Remove the play button and replace it with step back button in order to give the user flexibility to walk back and forward through the source code and investigate the specific statement line. And we rename the Step button to Step Forward in contrast to the Step Back button.

2) Move the screen window to the left side of the interface under the code window and the status/explanation window directly under the memory window. These changes make the overall layout more natural and integrated because the left part presents the front end of the code and the right part now represents the back end.

3) We enriched the status explanation

Here is the version after modifications:

[pic]

PHASE V – Iterate

We went on with the communication with our client and fed back his comments to the design. To solve the design problem empirically, we also evaluated our prototype on different kinds of users. This is an iterative process of design that incorporating the feedback and evaluation result will enhance the design and the enhanced design will arouse more consequential evaluations. The progress is maintained towards a successful conclusion.

The most challenging work is the interface’s reusability required by Dr. Spring. By change of the input parameters, the client could simulate other code with the same interface. We used MVC to accomplish this requirement, which will be introduced in detail in the design-building phase. The limitation is that our prototype can only deal with the variables of int and char array combination.

Since char occupies one byte and int occupies 4, we take byte as the smallest element of memory area, which is represented by rectangle. When the variable is declared, the corresponding rectangles are marked with distinguished color and when it is initialized, the value presented in 8 bits is placed into the corresponding rectangle. All these efforts were to depict the variable as clearly as possible.

During this design process, the group discussed about several technical puzzles about the internal memory allocation mechanism and agreed to stick to Big Endian machines, meaning that multiple byte integers are stored in memory beginning with the most significant byte, in our case is Unix machine.

This is one of our interim prototypes during the design iteration.

[pic]

The design for the memory area also went through several changes:

1) We initially only used the positional difference to distinguish each variable in the memory area. While this is sufficient to represent the changes in memory, we thought it would be better if we could also use color to distinguish each variable and it's content. This way, users could easily see the memory allocated for each variable. When the overflow happens, they could easily figure out that the contents of one variable being written to where they don't belong.

2) More effectively, we added the legend under the byte rectangle, which is the equivalent character value of the variable. In this way, the user can easily read the variable value represented by internal bits. This is especially beneficial to those elementary programmers.

3) In order to depict effectively the occurrence of buffer overflow, we added two more overwritten samples in the simulation. More case studies would deepen the user’s comprehension.

Another interim interface is shown below:

[pic]

As we were implementing and testing the design, we realized that even with the step back function added, the users still need several clicks to get to certain line of the code. We thought that would be nice to provide an additional function that will allow the users to select any line of the code directly. We added this function through associating each line of the code with a mouse action listener. Accordingly, we also added a label to the control area to notify users the existence of this function.

Besides, the tool tips are attached to these buttons that a simple and natural dialog will pop out when the user focus the mouse on these buttons.

The address number beginning with 641 was called into question, since the memory is allocated in multiple of 4 bytes. We changed it to 640.

Dr. Spring doubted the front and background colors combination of the memory cells in our prototype. He thought it borders on the color blinding area. We checked the complementary color rules and adjusted the color assigned.

The source code in the Code window is listed against the boundary. While in real world, indention is used intensively. To speak the user’s language, we improved our interface design to follow this customs.

PHASE VI – Build the Design

The highlight of our design is that the same user interface can be used to simulate any piece of code.

MVC Architecture

The model view controller architecture was followed extensively in the implementation of this project. Since the customer wanted the flexibility to simulate any code with the same interface, we decided to isolate the functionalities associated with the Code/Program to a separate class and the memory representation in a separate class and these two were brought together in the main applet class. The following is a list of classes that we have used

Code

This class handles all the lines of code in the program. This class maintains the following details required for simulating the changes in the memory contents:

• Starting Memory Address of the program.

• Ending Memory Address of the program.

• Program Line (the actual line of code eg: strcpy(line, “howdy”);)

• Print Line (the associated printfs())

• Status Line (the explanation for the line of code).

• Memory Line (a delimited string representing the memory allocations and how they have to be illustrated etc).

The format for the memory line is as described below

/**Format for declaration line- int i or char line[12]

* /;;

* For eg: 640/643:255,255,0;int i

* Format for regular line

* ;;;;;;

* ;;;;:

* ;;;;;;

* ;;;;

*/

- Address location to be accessed.

- Background color of the rectangle address cell.

- foreground of the rectangle address cell.

- Number of bytes occupied

- Data type of the variable. 0 for int, 1 for char and 2 for string

- The actual value of the variable

- Legend Color

- Value of the legend

- Boolean indicating if Overflow has occurred. 1 means overflow, 0 implies no overflow.

- Comma delimited addresses where overflow data is written.

- The color of the overflow cells.

Eg:

"630;18,215,162;255,0,255;14;2;advertisement0;255,0,255; advertisement0;1;640,641,642,643;255,255,0"

By setting the strings for the Program Line, Print Line, Status Line and Memory Line, an y program can be simulated with the same user interface.

myDraw

This is the abstract base class for myDeclare and myRect class.

myRect

This is the class that draws the Rectangular cells in which the memory contents are displayed.

myDeclare

This is the class that draws the rectangular memory cells for the declaration lines like “int i”

Buffer

This is the main applet class which controls the view. The important method in this class of interest to the customer is the initCodeArray() method. This is the method where the data about the code that is going to be simulated is set up. The method uses 4 String[] arrays strCode, strStatus and strPrintLine and strMemory. The array strCode contains all the lines of code in the program. For each line of code in the program, there should be a corresponding PrintLine, StatusLine and MemoryLine. So the arrays strCode, strStatus, strPrintLine and strMemory should be of same size.

To make the applet simulate a new code, the following changes have to be made:

1. Re-initialize the code array strCode[] with the lines of code of the new program.

2. Re-initialize the status array strStatus with the status/explanation for each line of code.

3. Re-initialize the print line array strPrintLine[] with the values of printfs().

4. Re-initialize the memory line array strMemory[] with the memory representation that corresponds to this new program. The format of the memory line has been described in the discussion of the class Code. Please refer to that.

Note: It is important that all these arrays are of the same size. So in case a line of code i.e. an element of strCode[] does not have a corresponding status/explanation or memory representation or print line, then leave that element of strStatus[], strMemory and strPrintLine[] blank (“”).

DESIGN FEATURES

The overall design of the buffer overflow interface is to provide a visualized process of internal memory allocation and contents overwritten as step through the statement line of a block of C code. The screen interface consists of 5 sections: control panel, code window, console window, stack/memory window and status/explanation window. Each section contributes a part of description of changes in its own stand. Together they provide a whole picture of what happens at the front end and back end when buffer overflow occurs.

The top panel provides the user four options to go through the code: step forward, step backward, reset and select randomly statement line. The user can focus on any specific statement line as they like to study it. The upper left window contains the complete source code. The statement line would be highlighted whenever the user steps on it. The left bottom window simulates the real screen output when the user runs this code on Unix machine. The left part as a whole is accessible by a common user on any computer machine. The right part, however, holds the information that is not visible to common user. The right top section graphically illustrates the memory allocation of variable declaration, variable initialization and the value written to the variable. This window is appealing because the colors and contents change as the user walks through the left code. The right bottom window displays the literal explanatory material through extended tool tips to help the user’s understanding.

[pic]

The screen shot shown above is the final version of our applet. The explanations of the various sections of the applet are as follows:

Control Panel

While the applet aims at providing a simple and intuitive interface to most users, four buttons are placed on top panel: Step Forward, Step Backward, Reset and Click to select the statement line, implying the four possible functions that the applet provides for the user. These four functions would offer enough flexibility to meet the requirements of the user.

Coding Window

The source code is displayed in this window just as it is in any text editor, which allows the user to step through. The statement line would be highlighted whenever the user step on it, so it is easy to be referred to at any time. The auto scrolling makes the longer text to be readable as well.

Console Window

The window prints out the actual output on a screen when the source code is run on a Unix machine. The black background and the white front color for the character just simulate the real screen output, which is intuitive and appealing.

Stack/Memory Window

This window is most appealing part of our design. It dynamically displays the process of the back end activities, which includes the allocation of the memory when a variable is declared, the content represented in binary bits when the variable is initialized and assigned value. Most important, it displays the contents changes of the variable resulted by other variable being overwritten to its memory area.

The variable, no matter it is int, char or string, is in unit of byte, each byte is represented by a rectangle. Each rectangle holds 8 bits in 0s or 1s inside. The rectangles simulate the memory area and are labeled with its address number. Each variable is dyed a distinguished color. The variable name is placed just right next to its memory area. The value assigned to variable is expressed in binary form. Besides, the char type variable is also expressed in its character value at the same time. The character value will definitely help the user read the overwritten content so as to really understand the buffer overflow’s occurrence.

The interface is natural and intuitive to the target user. Although the original design of this applet would have included data representation in hex form as well, we later found that would confuse the user to some degree. So we gave up this form of representation in our final version.

Status/Explanation Window

This window provides the literal explanation of what happens in other three sections. This is a complementary material to the graphics in memory section. However, it is indispensable to help the user really understand the activities that are taking placing in other windows.

EVALUATION – Heuristic Analysis

We conducted evaluation on our prototype. Here is the summary report:

|ID |Category |Good feature |Problem |

|HE1: Step Forward and Backward button for user to go back and |Minimize user memory load |[pic] | |

|forward freely | | | |

|HE2: Tool tip for control buttons |Simple and natural dialog |[pic] | |

|HE3: Status explanation is detailed and helpful |Minimize user memory load |[pic] | |

|HE4: The black background in the console window is a very nice way |Speak the user’s language |[pic] | |

|of distinguishing it, same goes for the use of gray background for | | | |

|the memory window | | | |

|HE5: Memory representation in both binary and legend formats |Speak the user’s language |[pic] | |

|HE6: Random access to any code line. |Provide shortcuts |[pic] | |

|HE7: No alerting message for buffer overflow’ occurrence. |Provide feedback | |[pic] |

|HE8: Control button is rigid. |Simple and natural dialog | |[pic] |

|HE9: The direction of memory allocation is reversal to common |Speak the user’s language | |[pic] |

|concept. | | | |

|HE10: The scrolling in memory window is otiose |Simple and Natural dialog | |[pic] |

RESPONSIBILITIES

Responsibilities for this project were divided as follows:

Ramakrishnan Balakrishnan – programming, graphic interface design, testing, evaluating

Sucai Dong – programming, graphic interface design, testing, evaluating

Zhiping Mi -- graphic interface design, testing, report writing, evaluating

Yeni Wang -- graphic interface design, testing, report writing, evaluating

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download