22C3 - 2.2
22nd Chaos Communication Congress
Private Investigations
| Referenten | |
|---|---|
|
Christiane Ruetten |
| Programm | |
|---|---|
| Tag | 1 |
| Raum | Saal 3 |
| Beginn | 12:00 |
| Dauer | 01:00 |
| Info | |
| ID | 571 |
| Veranstaltungstyp | Vortrag |
| Track | Hacking |
| Sprache | englisch |
| Feedback | |
|---|---|
|
Haben Sie diese Veranstaltung besucht? Feedback abgeben |
Understanding buffer overflow exploitation
The fascinating interplay of CPU, stack, C-compiler and shellcode in a nutshell
Everything started with Aleph One's paper "Smashing the Stack for Fun and Profit". These techniques are still the basis for modern exploitation of buffer, heap and format string vulnerabilities. We will give a swift overview about C functions, stack usage, assembler, gcc, gdb and how these few tools can be used to understand and write shell-code to turn simple buffer overflows into backdoors that open whole systems to potential attackers. Sure you want to know how to defend against that. We also will tell you about that!
This course essentially was held at Informatica Feminale in Bremen in September 2005. Not by accident, there is a strong alignment to Aleph1's popular paper on this topic. We will start by looking at the i386 architecture, the linux memory model, typical C functions, how function parameters are pushed onto the stack according to standard C calling convetions and how space is allocated on the stack for local variables. We will take a closer look at the steps neccessary to open a shell and exit cleanly and how to find out how to implement these functions in assembler to build a shellcode, which yields a pretty universal howto of shellcode writing on nearly any architecture, just using gcc and gdb. Finally, we will see how the vital stack space of some vulnerable programs gets overwritten and and how to cleverly do that to force even unknown programs into doing what WE want them to do. The conclusion of this course will put buffer overflows into a wider perspective. How are they related to those other vulnerabilities, like heap overflows and format string vulnerabilities and what can we do to prevent them?