1 Purpose

The purpose of this assignment is to allow you to demonstrate that you have acquired the knowledge and skills necessary to design and construct secure programs in C.

2 Part 0

For Part 0 you must create a high-quality list of concerns that is appropriate for a code inspection of this project. It must be based on the rules (not the recommendations) in the SEI CERT C Coding Standard. It must include vulnerabilities that might lead to confidentiality, integrity, and availability attacks at an appropriate level of detail for a formal inspection. You may include all of the rules if you wish, though it will make it more difficult for you to complete the review in Part 2.

Though you will not be submitting your list of concerns until you use it to complet Part 2, you will be well-served to complete it before you start working on Part 1 (so that you can use it to ensure that your implementation is secure).

3 Part 1

For Part 1 you must design and construct a program named CenTable, a system for generating tabular reports from county-level U.S. Census data.

You have been provided with: a data dictionary that is believed to be accurate but may include defects (e.g., spelling errors, type misclassifications) that you should correct if you find them, data from the 2000 U.S. Census, and a description of the format of the data.

The following Software Requirements Specification (SRS) exists for CenTable.

In addition, your implementation must satisfy the following course-related requirements:

1. The program must be written in C.
2. You must write all of the code yourself. You must not use any existing frameworks or libraries (other than the standard libraries that are part of most C implementations). While this will not result in the most secure code possible, it will help you learn the material. Also, it will ensure that any vulnerabilities in the product were introduced by you.

4 Part 2

For Part 2 you must "critique" the implementations of one other student. That is, you must conduct a code review and write a report that documents any concerns that you have using the list of concerns you created for Part 0).

Your report must include one checklist for each file (where the items in the checklist correspond to the rules you identified in Part 0). For each item in the checklist you must include the (line numbers of the) lines in the file that are of concern for that rule. (Obviously, a particular file may not have any lines that are of concern for a particular rule. In other words, some items in the checklist may have no lines of code associated with them.)

If the code includes easily exploitable vulnerabilities then your report should include demonstration exploits.

5 Hints

You may want to consider the following when working on Part 1.

1. Since the report description file must be read from standard in, you will probably want to redirect a file (i.e., using <) to standard in when testing.
2. Since the output must be written to standard out, you will probably want to redirect standard out to a file (i.e., using >) when testing.

You may want to consider the following when working on Part 2.

1. As a reviewer, your job is to identify concerns, if they exist, even though the code was written by another student (with whom you might be friendly). Remember that reviewers will be anonymous and that the quality of your review will be assessed and be a factor in your grade.
2. Note that this project is intentionally long, in part so that you are forced to deal with the real-world conundrum of trading-off security for features (or vice versa). With that in mind, during your review, you should look for situations in which the designer/programmer got "sloppy" because they were facing time pressure. For example, look for situations in which the implementation in one part of the system is secure but in another, very similar part of the system, they were not. In other words, don't assume that because the "right" decision was made in one location it was made everywhere.

6 Submission

For Part 1, you must post your implementation on stu. It must be in a single file named part1.zip in the cproject directory (under the www directory so that it is available to reviewers). The .zip file must contain the following.

1. All of the source code (both .c and .h files, as necessary).
2. A makefile that can be used to build the executable on a "normal" Linux platform using the GNU Compiler Collection.
3. The county-level census data file.
4. The data dictionary.
5. All of the report description files you used for testing your implementation.
6. An ASCII text file named readme.txt that explains how to execute the program from the command-line.

In other words, it must contain everything that anyone would need to build and run CenTable.

For Part 2, you must submit the results of the code review that you conducted using Canvas. It must be in a single PDF file named eid.pdf (where eid is the JMU electronic ID of the student who wrote the code). Do not include any information that would identify you as the reviewer. (In other words, reviewers are to remain anonymous.)

7 Visibility

Your deliverables will be public (i.e., available to both other students in the course and the general population).