CS 5493/6493: Applied Software Security Testing
Final Project (collected via Canvas)
Instructions: Using your skills from Labs 1–3, team-up in groups of two to four students to hunt bugs in a real-world software of your choice! Upon choosing a target, your team must figure out how to (1) harness it, (2) fuzz it, and (3) triage any discovered bugs. You may select any target you like (e.g., popular APIs, video games, kernels), provided it has not been fuzzed before—or has demonstrably not been fuzzed effectively. Failure to do your due dilligence will cause your team to lose points—or worse yet—have to find a different target!
Halfway through the semester, your team will present a 5-minute project lightning proposal to the class outlining your chosen target, your proposed approach, and the significance of your work. At the semester's end, you will prepare and deliver a final in-class presentation along with submitting a final project report outlining your ultimate approach, findings, and any discovered bugs.
Heilmeier's Catechism will serve as the high-level rubric for your proposal, presentation, and report—so be ready to answer why your project idea matters! But most importantly, get creative and have fun. Besides Heilmeier's Catechism, other important criterion include:
- Responsible Disclosure: Discovered bugs must be disclosed to developers! Include any bug report links (e.g., GitHub issues) in your final report. If bug reports are not public, you may include screenshots of your correspondence (e.g., emails) with developers.
- Project signup sheet is available: here (accessible only via your
@gcloud.utah.eduaccount; requests from non-UofU emails will be denied).
Working Solo: Solo projects are permitted only in special circumstances and require prior instructor approval. Consult the Schedule for the solo project approval deadline and meet with the instructor ahead of time. Be prepared to justify why your project is doable by you alone.
Lab Exercises (collected via Canvas)
| Assignment | Deadline (by 11:59PM) |
|---|---|
| Lab 1: Beginner Fuzzing | Wednesday, January 28 |
|
Overview: In preparation for the semester project, this lab will familiarize you with AFL++ (the world's most popular and extensible fuzzing platform). You will test several of AFL's features in fuzzing an application of your choice.
Learning Objectives:
Your task: Select three of AFL++'s user-configurable features and evaluate their impacts on fuzzing:
Other Notes:
Recommended Readings:
What to Submit:
Submit a 1–3 page report detailing your experimental findings.
There are no "right" or "wrong" answers—your work will be assessed by your overall effort.
You have full creative liberty—feel free to use images, tables, etc.
|
|
| Lab 2: Crash Triage | Wednesday, February 04 |
|
Overview: In this lab, you will leverage AddressSanitizer (ASAN)—today's state-of-the-art memory error detection tool—to perform post-fuzzing crash triage for crashing test cases you found during your Lab 1 fuzzing campaign.
Learning Objectives:
Your task: Replay the fuzzer-found crashing test cases you found during Lab 1 on an ASAN-instrumented version of your target program, and collect and analyze their resulting crash report information:
Other Notes:
Recommended Readings: What to Submit:
Submit a 1–3 page report detailing your experimental findings.
There are no "right" or "wrong" answers—your work will be assessed by your overall effort.
You have full creative liberty—feel free to use images, tables, etc.
|
|
| Lab 3: Harnessing | Monday, February 23 |
|
Overview: In this lab, you will learn the art of writing fuzzing harnesses for a real-world software API (libArchive).
Learning Objectives:
Your task: Develop a correct (i.e., upholds the API's intended usage) and AFL-compatible (i.e., accepts file inputs via AFL's
Other Notes:
Recommended Readings:
What to Submit:
Submit a 1–3 page report detailing your experimental findings (including your harness code).
We'll especially scrutinize how you "prove" the correctness of your harnesses—so be sure to thoroughly show that it works correctly.
As usual, you have full creative liberty—feel free to use images, tables, etc. Be sure to append your harness code as the final page of your report!
|
|
Research Paper Presentations (collected via Canvas)
Instructions: Select one paper from the course Schedule to present to the class in a 10–15 minute presentation, totaling 10% of your course grade. You are free to borrow visual aides from existing slide decks such as the authors' own presentation, but the overarching presentation must be in your own words. Following each presentation will be a 5–10 minute audience discussion.
Paper signup sheet is available: here (accessible only via your @gcloud.utah.edu account; requests from non-UofU emails will be denied).
- CS 5493 students must team-up and present in pairs of two.
- CS 6493 students must deliver their presentation solo.
Presenters: your responsibility is to teach us the paper:
- Prepare a 10-15 minute oral presentation on your own with an accompanying slide deck.
- Outline the paper's context, main contributions, key assumptions, results, and pros/cons.
- Do your own research on the field—you are expected to be "the expert" on your paper!
- Minimize background information to only what's new—don't re-teach us what fuzzing is!
- Following your presentation, submit your slides in PDF format to Canvas by 11:59PM that day.
Audience: you are not required to read the paper, but you must participate in the class discussion following each paper presentation.
Participation (collected via PollEverywhere)
Attendance: Regular attendance in this class is required as the lectures and discussions are designed to prepare you for success in the final course project. To monitor attendance, we'll issue attendance codes in-class via PollEverywhere for five randomly-chosen lectures throughout the semester, totaling 10% of your overall course grade.
We'll drop one absence at zero penalty. We'll track this automatically—you don't need to notify us about using any of your absences.