Format string exploitations

I’ve been interested in security quite some time and I came to a conclusion -that I read from other guys yesterday as well- but it is common to most people out there. When you develop an application, most of the times this application takes input and reacts to it. When it comes to security, this application -under any circumstances- must filter input and distinct between what is allowed and what is not. What is not allowed may be invalid strings for example or specially crafted strings that will exploit a vulnerability thus “adding” new features to the application such as reverse TCP shells, privilege escalations, whatever the attacker feels like.

In that aspect, a vulnerability called format string exploitation exists but I haven’t seen one for a while up until May 2012 where a guy found a format string exploitation. More info about this vulnerability can be found here.

So, what is a format string exploitation? It is mentioned a lot and in various sources that strings should be treated as strings. Mistreating strings may lead to “random” features that certainly were unintentional and unwanted.

Historically talking, format string exploitations has taken by surprise the security community during 2000. Like every new class of vulnerabilities, what followed format string vulnerabilities was a huge amount of bugs and exploits. Format string vulnerabilities are programming bugs firstly and then security threats but I’ll come back to this later.

A format function, such as printf() in C, is a function that takes data and some conversion parameters and prints the data in a human readable format. It must be clear that what is human readable can be in most cases understood by humen with some knowledge.  The most common example of a format string vulnerability lies in this code

char theVuln (char *theExploit){
printf(theExploit);
}

The above block of code prints data without formatting it. If a user inputs “Hello world” everything will look fine, the vulnerability will not be exploited but there will be a vulnerability.  To correct the vulnerability the developer should add a formatting parameter to the function. The function should look like

printf("%s",theExploit);

In order to understand how and why this vulnerability works and what happens when exploited it is necessary to dive a little deeper, in order to do so I will refer quickly to stacks.

Stacks are data structures that are built in such a way so that the last member added to a stack is able to leave the stack first, because of this “behaviour” stacks are called Last In First Out or in short LIFO. When someone is dealing with stacks it is said that he is pushing -adding to the stack- data or popping -removing from the stack- data. It is obvious that the two most common commands about stacks are POP and PUSH. It is thus obvious that even CPUs have commands so that they are able to deal with stacks. The prevalent CPU architecture which is Intel x86 has two commands known as POP and PUSH. They are called OPCODES and Intel offers a range of OPCODES when it comes to stacks but this is out of scope. There are also other data structures such as lists, queues etc but I won’t refer to them here.

When we exeucte a program the operating system “creates” two data structures. The first one is a queue, which stores all the code and the data that doesn’t change during execution mostly. Queues grow upwards (meaning to higher memory ranges) while stacks grows downwards. Stacks are used to store functions mostly. The exact actions in a stack, such as when it pushes the parameters of the function, in what order etc are out of scope in this article :)

When I was referring to the printf I was referring to a function. Since this is a function it is obvious from what I stated before that it is pushed onto a stack. Printf is a dynamic library thus it is not embedded in every executable but is loaded by the OS and the OS points the executable to the address where the printf function “lives”.

printf("This is a %d decimal while this a %s string",theDecimal, theString);

Diving into the stack of the above printf the first parameter we locate the parameters in reverse order, meaning that the last parameter is found first and the first last. This is not clear enough but if you deal a little bit with functions and stack you’ll get it.

Attacking the vulnerable function is easy. The attacker can input whatever he wants -for example %n %x etc- and check the output which may indicate memory ranges thus allowing further exploitation via a shell loaded into an environmental variable etc. It is possible to crash the program, it happened in Linux where the program used coredump which allowed for an insight.

The main problem is -if the input is for example multiple %s- the attacker may access data not intended for him to read or not intended for anyone to see, read an illegal address not mapped, get an address range etc thus extracting a safe assumption of how the vulnerability works or what the program does which is definitely unwanted. Exploiting such a vulnerability a few times, there is a high chance of crashing the program thus leading to a DoS attack.

Attacking further than that, an attacker can see any memory range he wants or overwriting arbitrary memory addresses thus executing our own code. By the way and since I mentioned this, the CPU does not discern between data and OPCODES and if he is fed OPCODES when he should take data he is happily executing the OPCODES. 😛 The most common parameter is %08x which leads steadily towards the top of the stack enabling us to map the whole stack. Last thing to mention is that buffer overflows sometimes offer limitations, format string exploitations allow an attacker to overcome these limitations.

Exploiting such vulnerabilities depends heavily on the type of the vulnerability since format string vulnerabilities is a class of vulnerabilities. There may be as simple as buffer overflows, may just need string stretching or may be highly complicated and need environmental variables to hold the exploit etc.

One response to “Format string exploitations

  1. Hi Dear, are you in fact visiting this website regularly, if so then you will absolutely
    obtain pleasant know-how.

Leave a Reply

Your email address will not be published. Required fields are marked *