Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
IFN657 Assignment 2 1 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 G itHub, S ourceForge, G NU, 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 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.
- 经济Economics
- 金融Finance
- 会计Accounting
- 工商管理Business Management
- 计算机computer science
- 商业分析business analysis
- 法律Law
- 管理Management
- 市场营销Marketing
- 哲学Philosophy
- 心理学Psychology
- 物理Physical
- 统计学statistics
- 电气工程electric engineering
- 化学chemistry
- 生物biology
- 数学mathematics
- 语言学linguistics
- 土木工程civil engineering
- 工程力学engineering mechanics
- 艺术art
PROFESSIONAL HELP!
在线咨询
立即下单
Wechat：THEend8_ 
Email：