IFN657 Assignment 2 1
IFN657 Assignment 2
Total weight: 20% (+ 5% bonus)
Due date: 28 October 2020
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 of buffer overflow and other common software
vulnerabilities. The objective of this assignment is to analyse vulnerabilities in
real-world software with basic fuzzing. 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, libxml2, openthread, pcre2,
re2, sqlite, vorbis, woff2.
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
less number of 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
IFN657 Assignment 2 2
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 are
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 use of buffer is, and how the
given input file triggers this error).
Where does the vulnerability take place (i.e. where in 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?
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 along with the report (you 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 should provide full evidence of how you detect the known vulnerabilities
by your own analysis (see the marking criteria below).
IFN657 Assignment 2 3
Exploit Vulnerabilities (Optional for Bonus
Credit)
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. You 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.
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 4
In addition to the write-up, you should also include (in the appendix) any test
harnesses, input test files corresponding to vulnerabilities along with 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)
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.
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
IFN657 Assignment 2 5
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.
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.
IFN657 Assignment 2 6
Submission
Please submit your assignment via the IFN657 Blackboard web site 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作业君