Almost any piece of code contains bugs. Some bugs more serious than others. But how do you know how serious is a bug once found? In this course we cover the basics of memory corruption issues, specifics of embedded device and kernel exploitation. Is it possible to make software exploitation hard? In this course we look typical mitigation techniques and/or bypassing techniques which make software exploitation hard.
At the end of this course students will learn how to:
Day 1: From stack memory corruption to full control.
We focus on exploiting a simple stack-based buffer overflow, which we use as running example, and see what protection mechanisms are typically available. We discuss how protection mechanisms can be bypassed and what could be the next steps. We close the day with an open discussion on what we learned on stack-based memory corruption attacks and potential defenses.
Day 2: Beyond stack memory corruption.
We focus on heap-based memory corruption, integer overflows, etc. We learn how attackers can turn heap memory corruption into exploits by taking control of the target, and how they can be mitigated. We discuss the basic requirements for memory corruption exploitation and the approaches taken by attackers to achieve these. At the end of day 2 students should be equipped with generic exploitation knowledge that will help them reason about mitigation techniques on their own.
Day 3: Kernel exploitation.
The previous two days we discussed and applied exploitation concepts in the comfort of user-land. In kernel-land, and in the case of embedded systems with RTOSs, a crash of the kernel is likely to result in an unstable system or a non-functional kernel. In this session we discuss the particularities of kernel-level and bare-metal exploitation as compared to user-level exploits. We will also introduce specific issues that appear at the kernel level and introduce the approaches used to exploit them. We introduce kernel-level protection mechanisms. Finally we imagine a world in which memory corruption exploits have been successfully mitigated and/or are too expensive to develop reliably. What is left for an attacker once memory corruption leading to runtime control is not feasible anymore?
Interested in options and availability please contact us by email or phone
Visit our catalog for more information.