IFN657 Assignment 2 1
IFN657 Assignment 2
Total weight: 20% (+ 5% bonus)
Due date: 31 October 2021 (Week 13)
Overview
This assessment is individual work to be submitted via Blackboard. While you can discuss the
assessment with your tutors and peers, your submissions must be your own original work.
We have had some experience with buffer overflow and other common software vulnerabilities. The
objective of this assignment is to analyse vulnerabilities in real-world software with AFL. You will gain
hands-on experience with investigating and documenting vulnerabilities (optionally exploiting them) and
understand some of the benefits and costs of fuzz testing.
Choose a Target
You are free to analyse any open-source project in C/C++ (so that AFL can instrument the source code).
Any target project should contain at least 3000 lines of code and optionally include a test suite. You may
find many different projects listed on GitHub, SourceForge, GNU, or other public repositories of open-
source software. For example, just to name a few common software: openssl, boringssl, c-ares, json,
lcms, libarchive, openthread, pcre2, re2, sqlite, vorbis, woff2 and hundreds more.
You can choose some older outdated software where it may be easier to find bugs, or some newer up-to-
date software where finding bugs may be harder but also more interesting. Moreover, the more well-
known the software is, the fewer vulnerabilities it will likely have (you aren't the only one looking for bugs).
To keep it simple, choose some software that can take a single file as input on the command line. Please
ask if you have questions about the suitability of particular software.
Keep in mind that there is always a possibility that AFL cannot find any bug in some software or some
versions of the software. After all, the fuzzing process is probabilistic and the software may be largely
bug-free. Therefore, you may need to scan multiple software with AFL until you find bugs. But you only
need to report the software of your best attempt.
Investigate Vulnerabilities
You should investigate the crashes reported by AFL and find out if they may be vulnerable. For each
vulnerability, you should provide the following details in your report:
What is the cause of the vulnerability? (i.e. what is the fundamental bug in the code that causes it)?
You should be very specific (e.g. if it's a buffer overflow, explain what the specific error with the use of
buffer is, and how the given input file triggers this error).
Where does the vulnerability take place (i.e. wherein the code of the target is it located)? Please
specify the source file and line number, as well as any other functions that are relevant to creating the
conditions of the bug.
How exploitable is this vulnerability? Does it just crash the program, or can the attacker take
advantage of it to do more things (inject shellcode, corrupt metadata used by memory management,
etc.)? What would an attacker need to do in order to exploit?
IFN657 Assignment 2 2
How would you fix this vulnerability? (i.e. how would you modify the specific code of the program to
prevent this vulnerability?)
Include at least one input file that reproduces the vulnerability. If the input is text-based, you can
include it in the appendix of the report; otherwise, submit it along with the report (your report should
provide the instruction of using the input to reproduce the vulnerability).
Please note that some vulnerabilities are more interesting and/or easier to document than others. In case
that AFL reports lots of vulnerabilities, feel free to investigate several before picking the specific ones you
want to document.
If the vulnerabilities you find are already documented where else, you must give references to previous
reports (and/or their CVE numbers if available). You must provide full evidence of how you detect the
known vulnerabilities with your own analysis (see the marking criteria below).
Exploit Vulnerabilities (Optional for Bonus 5%)
For students seeking challenges, you may optionally construct a working exploit (along with instructions
on using it) that successfully leverages one of the vulnerabilities you find to exploit the software in some
manner. At a minimum, the exploit must do more than just crash the program. If you include an exploit,
please also include the following in your report:
The expected consequence of using your exploit on the software, as well as some proof showing that
the exploit works.
Detailed instructions on how to compile and run the exploit code, as well as how to verify the results.
A brief description of why the exploit works and how it leverages the vulnerability you find in the
software.
Please note, in order to receive any bonus credit, your exploit must be original and created by yourself.
Your exploit code needs to be submitted along with the report.
Document the Process
You will document the details of your experience with fuzzing in a report. You must explain
your approach and report your findings in a self-contained and understandable way. For us to
understand the report better, you may include screenshots or other means (e.g. graphs or diagrams) as
evidence of successful fuzzing, which must be clearly visible and easy to read. If gdb is used to analyse
the vulnerabilities, you may use screenshots to explain how you use gdb to find out the memory or code
information. Screenshots can be either placed in the main text of the report or in the appendix (in which
case they should be clearly marked and referenced in the main text). Remember, the goal of your report is
to clearly show what you have done.
At the beginning of your report, you must provide a completion statement for everything you have
delivered in the report. If you used any help from any source (e.g. books, papers, online articles, etc.) in
the assignment, you must provide full references to them, and in addition, you must clearly identify your
own contributions to the assignment. It is plagiarism to use other people's work as your own!
In the last part of your report, you should reflect on the challenges you faced during this process, as well
as your approaches to overcome them. You should observe the strengths and weaknesses of the fuzzing
and/or sanitiser tools you used for the projects you examined. If any, are these reflected in your results,
and why?
IFN657 Assignment 2 3
In addition to the write-up, you should also include (in the appendix) any test harnesses, input test files
corresponding to vulnerabilities along the output of the overall testing process. As previously mentioned,
you should submit any non-text inputs (e.g. images, sounds, or other binary formats) along with the
report.
While you are free to organise your report in any suitable way, you may choose to use the following
structure as a guideline.
Introduction (e.g. summary of the report, claims of results)
Target Software (e.g. details and characteristics of a chosen software such as size/features, URL of
the code repository)
Fuzzing Process (e.g. compilation including necessary modification of the build process, harness,
statistics of fuzzing runtime such as time/crashes/coverage, etc.)
Result Analysis (e.g. investigation of AFL outputs, identification of vulnerabilities, and suggestion of
fixes)
(Optional) Exploitation (e.g. the process of exploitation)
Conclusions and Reflection
Marking Criteria
Your submission will be judged based on its overall quality, including technical details, clarity, accuracy,
depth, critical and original thinking, as well as the effort, techniques used, tools explored (AFL, possibly in
combination with other tools such as sanitisers), coverage obtained and vulnerabilities reported. The
following criteria should be used as guidelines only:
A report that is made as informative as possible.
Demonstration of how you discover vulnerabilities in the software you fuzz-tested.
The difficulty of fuzzing.
Tools explored and used (AFL, sanitisers, etc).
Vulnerabilities reported (originality and exploitability)
A bonus credit up to 5% of the grade of this unit (i.e. it may be possible to receive a maximum of 25%
from this assignment) may be given to an original working exploit, evaluated based on its difficulty,
originality, and effects/significance.
General Fuzzing Tips
A simple method to find vulnerable software is to use GitHub Search. You can search for a vulnerable
function name (gets, strcpy, etc.), which could return thousands of results. Go to the commits category of
the results where you may find the repositories and particular versions where the vulnerable function was
used or removed. These versions of software can be a good starting point to begin fuzzing.
To build the software, look for the notes or instruction come with the source code project.
You can use AFL to directly fuzz applications that have the main function. For libraries, you may need to
use/modify existing test cases or write your own test harness (the tutorials may help).
Try sanitisers in combination with AFL, as they should report more detailed information.
IFN657 Assignment 2 4
As we learnt from the tutorials, AFL and related tools would not take a long time or much effort to set up
and use. You will, however, ideally allocate 12-24 hours of total running time for the tools to get a better
picture of the behaviour and find more interesting things. This can be done overnight or during the
weekend.
When fuzzing each software for the first time, you should try running it for a few minutes first in order to
monitor the progress and sanity check that the way you are using the tool is working. You should run AFL
for at least 4 hours or until the first crash. If you identify one path after many executions, it's possible that
you are not running AFL correctly on the target software. Please refer to the lectures/tutorials where we
have discussed some of the issues.
In order for AFL to find more bugs, sometimes you may need to fix a bug that is preventing AFL from
executing paths (the fuzzing could go slower when this happens).
While AFL can report unique crashes, they don't necessarily mean unique vulnerabilities. Multiple unique
crashes may be caused by a single vulnerability. You should only report distinct vulnerabilities that occur
in different logical blocks of code within the program.
Submission
Please submit your assignment via the IFN657 Blackboard website under the Assessment section. You
should submit one PDF document with no more than 12 pages in length, excluding the appendix. It is
recommended to use A4 page size with 2cm in margins on all sides; 12-point Times New Roman or 11-
point Arial font or something equivalent, and in single space.
Any other files, such as AFL inputs that reproduce the vulnerabilities and the optional exploit code, should
be submitted in one ZIP file.

欢迎咨询51作业君