Project 1 -- Standard I/O and Device Drivers

NOTE: This assignment, like the other projects in this class, is due at the beginning of the class period. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your homework ahead of time. Do this by submitting them electronically then giving the hard copy to me or the TA during office hours or by sliding it under my office door within twenty-four hours after the time it is due. Do not send assignments to me through email or leave them in my departmental mail box.

As discussed in class, I/O can be a security risk, if not handled properly. One risk we discussed was that of buffer overflows, which often enter into our code through poorly designed input functions, such as gets.

This assignment will investigate the two risks that buffer overflows can have for us: (1) Compromised data within a program, and (2) compromised files belonging to the user of the program. To do this, I am giving you two simple programs that you will analyze and modify, according to the instructions below.

First, examine the code BufferOverflow.c (provided in source code and html for easy web viewing). Compile and run the code on one of the gpel machines in the CS lab as needed to answer the following four questions and be sure to EXPLAIN YOUR ANSWERS.

1. What statement(s) in the code make buffer overflows possible?
2. Which data in this program might be compromised?
3. Where is the memory in which the buffer overflow(s) happen? (Possible choices include main memory - user space, main memory - system space, registers of one sort or another, device-specific memory, etc.)
4. By how much must each buffer overflow before there is a problem?

Second, rewrite this program so that it does not use any C Standard I/O library routine that you implicated above as allowing a buffer overflow to occur. Be sure that your program uses a different C Standard I/O library routine that still allows for buffer overflows. Answer the same four questions as above for your new version of the program. Again, be sure to EXPLAIN YOUR ANSWERS.

Third, rewrite this program again so that it does not use any C Standard I/O library routine that you implicated in parts one or two as allowing a buffer overflow to occur. Be sure that your program uses yet another different C Standard I/O library routine from those used in parts one or two but that still allows for buffer overflows. Answer the same four questions as above for your new version of the program. Again, be sure to EXPLAIN YOUR ANSWERS.

Fourth, rewrite this program a third time so that it does not use any C Standard I/O library routine that you implicated in parts one, two, or three as allowing a buffer overflow to occur. This time be sure that your program uses C Standard I/O library routines that do not allow buffer overflows.

Fifth, examine the code BufferOverflow2.c (provided in source code and html for easy web viewing). Compile and run the code on one of the gpel machines in the CS lab as needed to answer the following five questions and be sure to EXPLAIN YOUR ANSWERS.

WHEN RUNNING THIS CODE, BE SURE YOU DO NOT ACTUALLY DAMAGE OR DESTROY ANY OF YOUR IMPORTANT FILES!

1. What statement(s) in the code make buffer overflows possible?
2. Which data in this program might be compromised?
3. Where is the memory in which the buffer overflow(s) happen? (Possible choices include main memory - user space, main memory - system space, registers of one sort or another, device-specific memory, etc.)
4. By how much must each buffer overflow before there is a problem?
5. How might a buffer overflow put the user's files at risk?

For part five, I am expecting a simple example based on the fact that the code uses data to determine what program to run. More sophisticated examples involving stack overflows that overwrite return pointers are not necessary for this project. (In fact, such stack overflows, while a common problem in primitive systems, are currently countered in a number of ways, both hardware and software, on sophisticated systems.)

All of your input and output in this assignment should use C Standard I/O function calls, not POSIX system calls.

You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a write-up answering the questions above for each part, plus all source code you used in collecting your results. The electronic copy will also contain three executable versions of your code for parts two through four. The electronic copy of your write-up should not be in a proprietary format (such as MS Word); it should be either in plain ASCII text or in a portable format (such as Postscript or PDF). Your source code for each version should be in a single file called BufferOverflowParti.c and your executable code should be called BufferOverflowParti, where i is 2 through 4 for the three versions.

Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks).

Besides the answers and explanations mentioned above, your write-up will include 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanation, which are encouraged and may take up any amount of space. (This explanation does not remove the requirement that your code be well commented.)

You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.

As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your write-up, including the names and student ID numbers of everyone involved.

Each group member is required to contribute equally to each project, as far as is possible. You must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, both your write-up and the comments in your code must clearly indicate this division of labor.

Note that we will cover execlp in detail later in the course. For now, you only need to know that it runs the program given by its first argument, passing the other arguments to that program.