Objectives and Logistics
Lab Presentation
The goal of this lab is to learn about and put in practice concepts about memory safety. We will explore a series of attacks exploiting memory vulnerabilities in binary programs. This lab is composed of 3 main exercises:
- Stack Smashing: how a buffer overflow on the stack can be exploited by an attacker to take over the execution flow.
- Setuid Exploitation: how to subvert programs executing with root privileges to bypass file system permission checks.
- Temporal Safety Exploitation: how to exploit use after free bugs to hijack the execution flow of programs.
The first and third exercises are divided into two parts: a guided part with detailed instructions on how to proceed, and an advanced part which is less guided. The second exercise has only a guided part. You can access each exercise from the left menu. In absolute exercises are independent of each other, but we strongly recommend doing them in order. If you are stuck in the advanced part of an exercise, it's OK to start the next one though.
⚠️ Ethical Use Disclaimer
Although part of this lab exercise introduces techniques that are commonly associated with offensive security, their purpose in this context is purely educational. Our goal is to help you understand how attackers operate, so you can build stronger, more secure systems.
You are expected to use the knowledge and skills from this lab responsibly and ethically. Any use of these techniques outside of authorised, educational, or professional penetration testing contexts is strictly prohibited and may be illegal.
Submission Instructions
The deliverable for this exercise is a series of passwords.
The submission is made through the CS Department’s Gitlab.
You should have a fork of the repository named 60261-lab2-s-memory-safety_<your username>.
The passwords should be submitted in a CSV file, that should be pushed alongside the C source code on the main branch.
You can find an empty skeleton for such a file here.
Submission details are given in the relevant parts of this exercise.
To indicate that the submission is ready to be marked create a tag named lab2-submission.
The deadline for this assignment is Friday 31/10 2pm London time.
A few important points regarding the submission:
- ⚠️ Make sure you push to the precise repository mentioned above and not another one (do not fork it or create a new repo), and to tag your submission properly.
- ⚠️ The submission is to be made through GitLab only, there is no need to submit anything to Canvas.
- ⚠️ You need some basic knowledge of git and GitLab to submit that exercise. In the unlikely case you are not familiar with these tools, see some guidance here.
Failure to follow these instructions is likely to result in a mark of 0 for this exercise.
For any issues or questions, feel free to get in touch with the instructor through the discussion board on Canvas or during office hours (see the schedule on Canvas for the their time and location. You can also contact your student representatives.
High-Level Marking Scheme
| Part | Marks |
|---|---|
| Stack Smashing (Guided) | /3.5 |
| Stack Smashing (Advanced) | /5 |
| Setuid Programs (Guided) | /3 |
| Temporal Safety (Guided) | /3.5 |
| Temporal Safety (Advanced) | /5 |
| Total: | /20 |
Intended Learning Outcomes (ILOs)
By the end of this lab, students will be able to:
- Analyse and reverse-engineer compiled binaries to understand their behaviour and detect vulnerabilities such as buffer overflows and use after free.
- Demonstrate how these vulnerabilities can be exploited to bypass security measures by e.g. hijacking the execution flow of a program.
- Understand the security implications of these vulnerabilities and reason about how to minimise the chances of introducing them when designing and implementing systems software.