Security Blog
Posts tagged xploits
Testing Your Unix-Based Shellcode on a Non-Executable Stack or Heap
12 years
I’ve been meaning to post about this technique I figured out while developing the OSX x86_64 setuid/shell shellcode [1] [2] I posted about last week but school and work have been pretty busy. It’s a simple technique that allows you to still test your shellcode on Unix-based OSes with non-executable stacks and heaps and can come in pretty handy for making sure your shellcode is right.
Format String Vulnerabilities:Part 2
13 years
In part one of Format String Vulnerabilities I showed you some simple code with a very serious format string vulnerability. I showed you how you could exploit this vulnerability to read any part of memory. In section two, I’m going to show you how you can write to any address in memory!
Writing to Memory
Exploiting format string vulnerabilities is all about providing input that uses a format character that expects its value to be passed by reference and you control that reference. I used ‘%s’ to read from memory. I’m going to use %n to write to memory.
%n Number of characters written by this printf.
Lucky for us, there is a really easy way to control the number of characters written by printf. When you specify a format character, you can optionally give it an integer for the width of the format character.
%#x Number of characters prepended as padding.
We can use this to control how many characters are written by printf.
If you’re following at this point, you’re probably wondering how we’re going to use %n to write to memory. We can use %n to write the integer value of our 4 byte target address one byte at a time.
We can write the lower order bits and shift the target address by a byte, utilizing width padding characters to control the integer value we write to a given byte.
Target = 0xAAAA1111 0xAAAA1111 = <int> 0xAAAA1112 = <int> 0xAAAA1113 = <int> 0xAAAA1114 = <int>
If we can overwrite an address, we can control the flow of execution. Let’s overwrite the address of printf! First we need to find the address for printf
nobody@nobody:~$ objdump -R ./text_to_print ... 08049660 R_386_JUMP_SLOT printf ...
Next we need to craft a string to overwrite this address using %n and width padding. We’ll also use printf’s ability to argument swap:
One can also specify explicitly which argument is taken by writing '%m$' instead of '%'
Lastly, instead of writing a byte at a time, we can use printf’s ‘length modifier’ to tell printf what type it’s writing %n too. We’ll use ‘l’ (ell) for long unsigned int.
0x0000beef seems like a good address to overwrite printf with since everyone loves beef! Our input will be a 4 byte address (to printf) and the decimal value of beef – 4 (to accommodate the length of the address) = 48875.
Here’s what It looks like when we run it (note we have to escape the $ with a for the shell):
nobody@nobody:~$ ./text_to_print $(python -c 'print "x60x96x04x08"')%48875x%4$ln Program received signal SIGSEGV, Segmentation fault. 0x0000beef in ?? ()
You can see that the program tried to jump to 0x0000beef and crashed! Be sure to check out the full section on format string vulnerabilities inHacking: The Art of Exploitation, it talks all about these techniques and more.
Format String Vulnerabilities:Part 1
13 years
I have to admit that I’ve heard of format string vulnerabilities but I never knew exactly what they were. After reading about them in Hacking: The Art of Exploitation I’m surprised I didn’t know more about them since they are extremely dangerous! Take this code for instance:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]) {
char text[1024];
if(argc < 2) {
printf("Usage: <text to print>n", argv[0]);
exit(0);
}
strncpy(text, argv[1], 1024);
printf(text);
printf("n");
return EXIT_SUCCESS;
}
Normal usage would look like this:
nobody@nobody:~$ ./text_to_print "Hello World!" Hello World!
Looks harmless right? It’s not! This code is very vulnerable to a format string vulnerability. The problem is, the call to printf, should have been:
printf("%s", text);
Why does it matter? Well the way that printf works is that all of the variable arguments for the format strings are passed in reverse order onto the stack. Printf then parses the input until it reaches a format character and references the argument on the stack based on the index of the format character.
If we specially craft the input to take format characters, printf will mistakenly reference previous elements on stack. We can use this to effectively read the stack. For instance
nobody@nobody:~$ ./text_to_print "AAAA %x %x %x %x" AAAA bffff9ba 3f0 0 41414141
It gets better though! The previous stack frame before printf is called contains the string argument passed to printf. Did you notice in the output above, the last ‘%x’ printed the first ‘AAAA’?
We can use this to read the contents of any memory address by putting the address we want to read at the first of the string, followed by 3 stack positions (8 bytes each), and then putting a ‘%s’ format character at the 4th position to read our address. Like this (the ‘+’ is used to separate for readability)
nobody@nobody:~$ ./text_to_print $(printf "x34xf8xffxbf")%08x%08x%08x%s 4���bffff9b5+000003eb+00000000+
or with Python like this
nobody@nobody:~$ ./text_to_print $(printf "x34xf8xffxbf")$(python -c 'print "%08x+"*3')%s 4���bffff9b5+000003eb+00000000+
00000000 is the contents of address xbffff834!
More to come on using format string vulnerabilities to write to any place in memory in Part Two of Format String Vulnerabilities!
PS3 Heap Overflow Exploit Explained
13 years
by Dustin Schultz
in Security News
As of very recently the PS3′s security has been finally been compromised!
Commercially, a company is selling a USB device called PSJailBreak (for a steep $130) which takes advantage of this exploit but it was reverse engineered and released as an open source project, yesterday, called PSGroove. The open source release is targeted towards homebrew developers who want to develop their own things on the PS3.
The guys over at lan.st have a really nice wiki post about the reverse engineering they did on PSJailBreak. Be sure to check out the original article for a more in depth explanation. I’ve summarized the exploit below. I take no credit for any of these findings. All the credit goes to the awesome PS3 hackers out there (GeoHot)!
Summarizing the Exploit
The exploit takes advantage of a heap overflow by making the PS3 think the single USB device that’s plugged in is a 6 port USB hub. The single USB then tells the PS3 to allocate/unallocate large chunks of heap space (4K) (using large device descriptors) by faking that devices are being plugged and unplugged from the USB hub.
One of the fake USB devices thats plugged in manages to overwrite another USB device’s heap space when allocating it’s configuration data. The key point here is that when it overwrites this data, it overwrites malloc’s pointer to where the next free memory block is. That means when malloc gets called again, it allocates space to wherever that pointer is pointing. The exploit overwrites it with a pointer to a function that it knows the PS3 will need to call. The function has something to do with freeing memory when a USB device is unplugged. (You might see where this is going)
All PS3′s have special built in functionality that allows an authorized USB “Jig” device to be plugged into the PS3 which turns it into development/debug mode. Sony uses this for repairing PS3′s and likely distributes it to game developers.
The exploit takes advantage of this fact and tells the PS3 that a “Jig” device has been plugged in. The PS3 sends an authentication challenge to the device to verify it’s authenticity. A real device with a key from Sony would be able to compute the response, respond, and continue on it’s merry way but the exploit takes advantage of the fact that the PS3 has to call malloc to allocate space for the challenge response. Malloc’s pointer to the next free space in memory was overwritten earlier. That means malloc will allocate space in the wrong place, overwriting a function the PS3 calls when a USB device gets unplugged. That means we can send a function of our choice (the shellcode) as the challenge response and the PS3 will overwrite another function with our function!
This is where the exploit gets invoked. The exploit explicitly unplugs one of it’s fake USB devices causing the PS3 to call the function related to freeing device memory which was overwritten with our challenge response data. The PS3 happily starts executing our code. From here we can now start patching memory to tell the PS3 that it’s in debug mode!
So what can you do in debug mode? You can start writing code and developing on the PS3!
Sony is very likely to patch this ASAP. In the meantime, you better hurry and get yourself a PS3. I know I’m thinking about it!