# Return-to-libc

(This is part of my series on program vulnerability exploitation.)

So far, our method of code execution has been to write a shellcode on the stack, and execute it from there. Since there is normally no reason why a program should need to execute anything on the stack, an obvious countermeasure was to make the stack non-executable. Indeed, if you omit the -z execstack compilation flag on the programs of the previous two posts, the attacks will fail with a segmentation fault. So executing code on the stack is no longer possible.

A new method, now referred to as return-to-libc (or ret2libc for short), was introduced by Solar Designer in 1997. As its name implies, instead of overwriting the return address of our vulnerable function with an address on the stack, we will overwrite it with the address of a libc function. The libc library contains all the standard functions such as printf() and exit(), so there is almost surely a function in it that does what we need.

# NOP sleds

(This is part of my series on program vulnerability exploitation.)

In the following program, the register eax no longer contains the address of buffer at the end of the execution of the function vuln():

# Return-to-register

(This is part of my series on program vulnerability exploitation.)

We saw in the previous post what a shellcode was, and studied one in detail. We also discussed the basic idea of what we want to do with it: write it in memory, and have the processor execute it. The first part is easy: since a shellcode is just a string of bytes, we can pass it to a vulnerable program like we would any other string. The second part is where the challenge is. In this post, we will see one way to do it, which is very simple but works only under very favourable conditions.

# Shellcodes

(This is part of my series on program vulnerability exploitation.)

Our ultimate goal when exploiting a program is to make it run arbitrary code. In general, especially in proof-of-concept exploits, we will want to spawn a shell since then from a shell we can execute arbitrary commands (so we consider that if we can spawn a shell, we can do anything). If the program already contains some code which spawns a shell, we can just replace a return address to jump to it in exactly the same way as in the previous post. You could try to exploit this program as an exercise:

# Overwriting a variable

(This is part of my series on program vulnerability exploitation.)

Before going on to arbitrary code execution, we will try our hand at something more mundane: overwriting a variable. The vulnerable program which we will exploit is as follows:

# The Stack (theory)

(This is part of my series on program vulnerability exploitation.)

Most of the techniques we will see here manipulate the program stack in some way or other, so it is imperative to have a good understanding of it, and we will describe it in some length. Again, the book by Bryant and O’Hallaron is an excellent reference for these topics.

# Exploiting basic vulnerabilities

By popular demand (sort of), I have started writing a series of posts on my Tumblr to explain and demonstrate how some basic vulnerabilities in computer programs can be exploited by an attacker to compromise the security of the system on which the program runs (typically, an attacker will be able to run arbitrary code with the privileges of the user running the vulnerable program). So I’m putting them here as well.

# Niveau 5 : Buffer overflow, part 2

Le niveau 3 n’était pas très réaliste : le code qui lançait un shell était déjà dans le programme, ainsi que le code pour l’appeler, et il ne restait plus qu’à modifier une adresse. Le niveau 5 l’est un peu plus :

level5@io:/tmp/bach\$ cat /levels/level05.c
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {

char buf[128];

if(argc < 2) return 1;

strcpy(buf, argv[1]);

printf("%s\n", buf);

return 0;
}