NOTE: Keep in mind I'm using a specially set up box that's vulnerable
[----------------------------------]
Paper: Format string overflows
Author: Chroniccommand
Sources: wikipedia, HTAOE
http://iexploit.org
[----------------------------------]
[--Contents--]
1 - Intro
2 - Intro to exploitation
2.1 - Types of exploitation
3 - Format strings
3.1 - Exploiting format string vulnerabilities
4 - Where to go from here

[--Intro--]
I've decided to write this simple paper for all those interested in application vulnerabilities. I've written papers on BoF's, the stack structure, etc. Now I think it's time for me to write a paper on Format string vulnerabilities(FS's). Enough with the intro, now onto section 2.

[--Intro to exploitation--]
Most tech savvy people know what exploitation is. Finding a hole(vulnerability) in a piece of software and making this piece of software do something it's not supposed to do. If you have some knowledge of computers(Which, if you're on this site, you probably do), then you'll know that computers are dumb shits. They just like to preform repetitive tasks over..and over... and over.... and over. They just do exactly what you tell them to do. At a computers core is basically a calculator. One of the basic forms of programming is Assembly. Assembly is less known than languages such as perl and python. Assembly is one of the most basic forms of computer programming. Assembly produces code for the x86 class of processors. It interacts with the stack and uses functions such as:
push
pop
call
ret
etc...
x86 assembly language has two main syntax branches: intel and AT&T. Intel syntax is used more in the windows world. Both are used in the UNIX/Linux world. x86 assembly instruction uses byte code. For example, NOP(No OPeration) instructions translate to 0x90(\x90). ASM uses registers to preform some operations. For example. EIP is a register(Instruction Pointer). Most exploitable programs are written in C. This is because C is a very powerful, low level language that can do tons of things such as memory manipulation. But of course, with great power comes great responsibility. If the code is written wrong, it can be exploited. All humans screw up. It's human nature to fuck up. All code is written by humans(obviously). This is why we have vulnerable applications. For example, take a look at this C code. It works fine, but it's vulnerable to a Buffer OverFlow, or buffer overrun.
-----C code-----
#include <stdio.h>
int main(int argc, char *argv[]) {
char buffer[256]; //This is the buffer. 256 is a common number so I'm using it
if(argc < 2)
{
printf("Usage: %s <input>\n", argv[0]);
return 0;
}
strcpy(buffer, argv[1]); //This is where the vuln is!
printf("%s", buffer);
}
----End C code-----

If you compile this code, you will most likely get this warning that GCC spits out at you:
------------------
chronic@vandal:~/c$ gcc -o boftest boftest.c
boftest.c: In function ‘main’:
boftest.c:9: warning: incompatible implicit declaration of built-in function ‘strcpy’
-------------------
This is just a warning. You can still run the code with ./boftest, but GCC is telling you that strcpy is possibly vulnerable to BoF's. We can exploit this easily. If I type this at the command line:
---------------------
./boftest AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
---------------------
We get this output:
*** stack smashing detected ***: ./boftest terminated
Segmentation fault

This is because GCC now has stack smashing detection. But of course there's way's around this.

[--Types of exploitation--]
This is quite a short subsection. I'll just be going over the basic types of application exploitation.
1 - Buffer OverFlow(BoF) - BoF's are well known in todays security world. A BoF occurs when the program tries to write data to a buffer and the data overruns the buffers boundaries. strcpy() doesn't preform boundary checking, that's why it's possibly vulnerable.

2 - Heap overflow - A type of BoF that occurs in the heap data segment(in the stack) Exploitation causes data in the program to be corrupt

3 - Format String overflow - This type of exploit can cause a vulnerable program to crash, and run harmful code. An attacker can use format strings such as %s to print sections from the stack, or other locations in memory. Format string vuln's aren't very common anymore, but I've decided to make this paper focusing on them because it's always great being able to exploit this type of vuln.

[--Format strings--]
So what exactly is a format string? Take a look at this code:
------C code------
#include <stdio.h>

int main() {
char test[] = "Test\n";
printf("%s", test);
}
------End C code-----
What this code does is very simple. It first creates a new character that holds the string "Test". Then, using printf we can print out test using %s. That's what a format string is. Lets have a look at other format strings:
%d Decimal value
%x Hexadecimal value
%u Unsigned decimal value
%s String
These are just a couple. Theres more. When any function is called(including the printf()), the arguments are pushed to the stack(In reverse order). But sometimes a programmer will use printf(string), instead of printf("%s", string). It works fine, but it's insecure. The wrong way:
printf(string);
Right way:
printf("%s", string);
Consider this C code:
----fmsvuln.c----
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
char string[1024];

if(argc < 2)
{
printf("Usage: %s <input>\n", argv[0]);
return 0;
}

strcpy(string, argv[1]);
printf("The right way:\n");
printf("%s", string);

printf("\nThe wrong way:\n");
printf(string);
printf("\n");
return 0;
}
----End C code----
First we have our imports. Then we have our int main(). Then we create the char string with 1024 bytes. If argc(argument count) is less than 2, we print the usage message. Then we copy string into argv[1](The first command line argument). Then we print the string the right way with printf("%s", string); Then we try printing it the wrong with with printf(string). Try compiling this. We get a warning from GCC, but we can still run it. Try this:
chronic@vandal:~/c$ ./fmsvuln a
The right way:
a
The wrong way:
a

The program functions the correct way, but watch what happens here:
chronic@vandal:~/c$ ./fmsvuln test%x
The right way:
test%x
The wrong way:
testbffff440

Uh oh. What happened there? When we used the %x format string, the hexadecimal 4 byte word in the stack was printed. The attacker can use this to their advantage and read memory addresses.
------
chronic@vandal:~/c$ ./fmsvuln TEST-%08x.%08x.%08x
The right way:
TEST-%08x.%08x.%08x
The wrong way:
TEST-ffffffff.cc271df0.cbfcb500
------
As you can see, now we get memory addresses :D

[--Where to go from here--]
Well, format string vuln's aren't as common these days. But I bet they're still out there. I've also included a little bit of BoF info in this paper. If you want to find vulns in actual applications, you can look through the source. Here are some key things to look for:
BoF's - strcpy(), gets(), scanf(), sprintf(), strcat()
Format String - printf(), vsnprintf(), vprintf()

If you visit http://exploit-db.com/ you can browse through some exploits written by others. If you take a look at the C exploits you can get an idea of writing exploits in C. If you browse exploit-db you can see they have perl and python exploits too. If you are familiar with perl and/or python, you can find vuln's and exploit them. For remote exploits in python you can use sockets to connect to a remote machine, and send over a payload(The shellcode, nop, junk etc).

--EOF