FIT3173 Software Security Assignment-1 (S1 2024)
Total Marks 100
Due on March 27th, 2024, Wednesday, 11:55:00 pm
1 Overview
The primary learning objective of this assignment is to provide you with firsthand experience in exploiting buffer overflow vulnerabilities and format string issues. Additionally, it aims to deepen your understanding of how operating system countermeasures function in response to these security challenges. All tasks in this assignment can be done on Ubuntu VM as used in the labs. Please refer to Section 2 for submission notes.
2 Submission
You need to submit a lab report (one single PDF file) to describe what you have done and what you have observed with screenshots whenever necessary; you also need to provide explanation or codes to the obser- vations that are interesting or surprising. In your report, you need to answer all the questions listed in this manual. Please answer each question using at most 200 words. Typeset your report into .pdf format (make sure it can be opened with Adobe Reader) and name it as the format: [Your Name]-[Student ID]-FIT3173- Assignment, e.g., HarryPotter-12345678-FIT3173-Assignment.pdf.
All source code, if required, should be embedded in your report. In addition, if a demonstration video is required, you should record your screen demonstration with your voice explanation and upload the video to your Monash Google Drive or any online service which allows you to share videos. The shared URL of the video should be mentioned in your report wherever required. You can use this free tool to make the video:https://monash-panopto.aarnet.edu.au/ ; other tools, such as Zoom, are also fine. Then, please upload the PDF file to Moodle.
Important notes and penalties:
• It is the student’s responsibility that the submitted video file can be opened on a standard Windows computer (without requiring specialised software), and that the images and texts shown in the video are understandable/readable (in English). If the video file cannot be opened, you will receive zero mark. After making a draft submission (before finalising it), we recommend you to download your submitted file and check that it opens and runs properly. Once you finalise your submission, you will not be able to revise it.
• A part of the submitted video (at a corner) must clearly show your face at all times. Penalties may apply when that’s not the case.
• Late submissions incur a 10-point deduction per day. For example, if you submit 2 days and 1 hour late, that incurs 30-point deduction. Submissions more than 7 days late will receive a zero mark.
• Ifyourequireextensionorspecialconsideration,refertohttps://www.monash.edu/students/ admin/assessments/extensions-special-consideration. No teaching team mem- ber is allowed to give you extension or special consideration, so please do not reach out to a teaching team member about this. Follow the guidelines in the aforementioned link.
• The maximum allowed duration for the recorded video is 15 mins. Therefore, only the first 15:00 mins of your submitted video will be marked. Any exceeding video components will be ignored.
• If your device does not have a camera (or for whatever reason you can’t use your device), you can borrow a device from Monash Connect or Library. It’s your responsibility to plan ahead for this. Monash Connect or Library not having available devices for loan at a particular point in time is not a valid excuse.
• You can create multiple video parts at different times, and combine and submit a single video at the end. Make sure that the final video is clear and understandable.
• If any task requires installing new software, you are allowed to do that in advance of recording your video. You do not need to demonstrate software installation in the video.
• Youcando(online)researchinadvance,takenotesandmakeuseofthemduringyourvideorecording. You may also prepare exploit scripts in advance. But you cannot simply copy-paste commands to carry out the tasks without any explanations. Explanations (of what the code does) while completing the tasks are particularly important.
• Zero tolerance on plagiarism and academic integrity violations: If you are found cheating, penalties will apply, e.g., a zero grade for the unit. The demonstration video is also used to detect/avoid plagia- rism. University policies can be found at
Buffer Overflow Vulnerability [65 Marks]
You will be given a program deliberately containing a buffer-overflow vulnerability. Your objective is to de- vise a strategy to exploit this vulnerability and send a remote access to an attacker. Furthermore, beyond ex- ecuting the attacks, you will be guided through an examination of various protection schemes implemented in the operating system designed to thwart buffer overflow vulnerabilities. Your task involves assessing the efficacy of these countermeasures and providing explanations for their success or failure.
3.1 Initial setup
You can execute the tasks using our pre-built Ubuntu virtual machines. Ubuntu and other Linux dis- tributions have implemented several security mechanisms to make the buffer-overflow attack difficult. To simplify our attacks, we need to disable them first.
Address Space Randomisation. Ubuntu and several other Linux-based systems uses address space ran- domisation to randomise the starting address of heap and stack. This makes guessing the exact addresses difficult; guessing addresses is one of the critical steps of buffer-overflow attacks. In this part, we disable these features using the following commands:
$ sudo sysctl -w kernel.randomize_va_space=0
The StackGuard Protection Scheme. The GCC compiler implements a security mechanism called “Stack Guard” to prevent buffer overflows. In the presence of this protection, buffer overflow will not work. You can disable this protection if you compile the program using the -fno-stack-protector switch. For example, to compile a program example.c with Stack Guard disabled, you may use the following command:
$ gcc -m32 -fno-stack-protector example.c
Non-Executable Stack. Ubuntu used to allow executable stacks, but this has now changed: the binary images of programs (and shared libraries) must declare whether they require executable stacks or not, i.e., they need to mark a field in the program header. Kernel or dynamic linker uses this marking to decide whether to make the stack of this running program executable or non-executable. This marking is done automatically by the recent versions of gcc, and by default, the stack is set to be non-executable. To change that, use the following option when compiling programs:
For executable stack:
$ gcc -m32 -z execstack -o test test.c
For non-executable stack:
$ gcc -m32 -z noexecstack -o test test.c
3.2 Warm Up: Shellcode Practice
Before you start the attack, we want you to exercise with a shellcode example. A shellcode is the code to launch a shell. It is a list of carefully crafted instructions created by malicious users/attackers so that it can be executed once the code is injected into a vulnerable program. Therefore, it has to be loaded into the memory so that we can force the vulnerable program to jump to it. Consider the following program:
