IFN657: Analyzing Vulnerabilities in Real-World Software with AFL - Report Writing - IT Computer Science Assignment Help

Assignment Task

Overview

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 2000 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 opensource 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?
• 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 on using the input to reproduce the vulnerability).

Please note that some vulnerabilities are more interesting and/or easier to document than others. In case 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.

Exploit Vulnerabilities (Optional for Bonus)

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, that 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 overcoming 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?

In addition to the write-up, you should also include (in the appendix) any test harnesses and 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 including the originality of the discovered vulnerabilities)
• Target Software (e.g. details and characteristics of a chosen software such as size/features, URL of the code repository, version and date)
• 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

This IFN657 - IT Computer Science has been solved by our Phd Experts at My Uni Paper. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+ Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing Style.

Be it a used or new solution, the quality of the work submitted by our assignment experts remains unhampered.You may continue to expect the same or even better quality with the used and new assignment solution files respectively. There’s one thing to be noticed that you could choose one between the two and acquire an HD either way. You could choose a new assignment solution file to get yourself an exclusive, plagiarism (with free Turn tin file), expert quality assignment or order an old solution file that was considered worthy of the highest distinction.