CS38, Security and Privacy, Spring 2005


The following is a list of short tutorials, HOWTOs and articles about exploiting buffer oveflow vulnerabilities. Most of these are non-scholarly in nature, and instead of taking a broad view of the problem, dive directly into the details of exploiting a particular architecture. A point of interest about them is that they, to an extent, represent the attackers' view and attitude.

Note: Urls on this page do not necessarily point to the author's page -- in cases when it moved or disappeared, I am merely pointing to an available copy mirrored by someone else.

Note: Shellcoding normally requires some command of the assembly language of the target platform, and some debugger experience. Luckily, you can learn as you read/go along -- see x86 and GDB links below.

Buffer overflows & shellcoding tutorials

Format string vulns

Integer overflows

Return to libc

This technique is used when the stack memory pages are marked non-executable (e.g., ExecShield, used by Fedora Core). The idea is that all the code that the attacker wants executed is likely already contained in the process address space (e.g., in loaded lobraries) or, as an advanced technique, can be loaded into it by the OS dynamic loader, on demand! All that is needed is to skillfully construct the stack frames to point to the desired code.

This technique can be thwarted by randomizing the addresses at which the libraries load in each process, but this only complicates the attack, but does not preclude it. The PaX Linux kernel patch provides both the non-executable stack protection and and address space randomization. The article below deals with overcoming them.

Using GDB and other UNIX tools

There are plenty of GDB tutorials on the web. Please let me know if you find a good one.

Exploiting vulnerabilities, next level

x86 Assembly language

If you look for free x86 assembly references on the web, you
will most likely discover Randall Hyde's voluminous (1000+ pages)
books. These books are not very helpful for learning assembly
hacking, because they often omit "unnecessary" details and
are oriented towards the author's own High Level Assembly language.


Back to Dartmouth CS Home Page     Sergey Bratus