Part 1 (Build it) Due 11/27 @10:59am
Part 2 (Break it) Due 12/6 @10:59am
In this project, you will implement a secure log to describe the state
of an art gallery: the guests and employees who have entered and left,
and persons that are in rooms. The log will be used by two
programs. One program, logappend
, will append new information to this file,
and the other, logread
, will read from the file and display the state of the art
gallery according to a given query over the log. Both programs will
use an authentication token, supplied as a command-line argument, to
authenticate each other. Specifications for these two programs and the security model are described in more
detail below.
You will build the most secure implementation you can; then you will have the opportunity to attack other teams' implementations.
You may work in teams of up to three people. Choose a team name and then email Prof. Dachman-Soled with the team name and the list of who is on your team (one email per team is sufficient). Make sure you include both your team name and the names all team members in your writeups.
You will write your implementation in C. There is some basic starting code available. There are example makefiles available.
This project will operate using infrastructure from the Build it, Break it, Fix it contest developed at UMD. Please note that your grade in for the project and your score in the contest are not the same (although they are likely to be correlated). Details of grading and scoring are below. Scoring well in the contest is good for bragging rights and for extra credit.
Part 1: Build it
You should submit:
Part 2: Break it
We will assign you three teams' implementations to examine. You should submit:
If you demonstrate a working security break, then your vulnerability analysis document only needs to include your description of that one vulnerability, you don't need to go any further.
Please note that while correctness bugs count for the contest, they do not count for your vulnerability analysis -- for this analysis, you must identify security-relevant issues. For points in the contest, you are welcome to also look at other implementations beyond the three you have been assigned.
If one of your assigned implementations doesn't work well enough to analyze, please request an alternate implementation from an instructor.
Part 1 will be worth 100 points:
Part 2 will be worth 25 points:
Contest scores are primarily for fun and bragging rights. We may assign some limited extra credit to teams who finish at or near the top, but contest scores do not affect your overall grade directly. You can feel free to attack your friends' implementations without worrying that you are hurting their GPA.
Your team will design a log format and implement both logappend
and
logread
to use it. Each program's description is linked below.
logread
contains a number of features that are optional. If you do not implement an optional feature, be sure to print unimplemented
to standard output.
Look at the page of examples for examples of using the logappend
and logread
tools together.
The system as a whole must guarantee the privacy and integrity of the log in
the presence of an adversary that does not know the authentication token. This token
is used by both the logappend
and logread
tools, specified on the command
line. Without knowledge of the token an attacker should not be able to:
logread
or otherwise learn facts
about the names of guests, employees, room numbers, or times by
inspecting the log itselflogappend
. logread
or logappend
into accepting a bogus file. In
particular, modifications made to the log by means other than correct use of logappend
should be detected by (subsequent calls to) logread
or logappend
when the correct token is suppliedAn oracle reference implementation is provided to demonstrate the expected output of a series of commands run on logread
and logappend
.
Contestants may run the reference implementation by going to the team participation page on the website and clicking on "Oracle Submissions". Here is an example of the expected input format for the oracle, structured as a series of command-line calls within brackets:
[
"logappend -T 1 -K secret -A -E Fred log1",
"logappend -T 2 -K secret -A -G Jill log1",
"logappend -T 3 -K secret -A -E Fred -R 1 log1",
"logappend -T 4 -K secret -A -G Jill -R 1 log1",
"logread -K secret -S log1"
]
Each team should initialize a git repository on gitlab and share it with the
cmsc414-p4
user. You MUST NOT make your repository public; doing so will be treated as an academic integrity
violation.
Create a directory named build
in the top-level directory of your repository and commit your code into that
folder. Your submission will be scored after every push to the repository.
To score a submission, an automated system will invoke make
in the build
directory of your submission. The only requirement on make
are that it
must function without internet connectivity, it must return within ten minutes,
and it must build from source (committing binaries only is not acceptable). We
will provide sample makefiles for C and java.
Once make finishes, logread
and logappend
should be executable
files within the build
directory. An automated system will invoke them with a
variety of options and measure their responses.
The executables must be able to be run from any working directory.
For the break-it round, you will be providing test cases that provide evidence of a bug in one of your target implementations. Bugs can include correctness violations, crashes, integrity violations, and confidentiality violations. Further details will be forthcoming when we get closer to the beginning of the break-it round.