Use a heap overflow to write arbitrary data

Question

I've been trying to learn the basics of a heap overflow attack. I'm mostly interested in using a corruption or modification of the chunk metadata for the basis of the attack, but I'm also open to other suggestions. I know that my goal of the exploit should be do overwrite the printf() function pointer with that of the challenge() function pointer, but I can't seem to figure out how to achieve that write. I have the following piece of code which I want to exploit, which is using malloc from glibc 2.11.2 :

void challenge() {         puts("you win\n"); }  int main(int argc, char **argv) {         char *inputA, *inputB, *inputC;          inputA = malloc(32);         inputB = malloc(32);         inputC = malloc(32);          strcpy(inputA, argv[1]);         strcpy(inputB, argv[2]);         strcpy(inputC, argv[3]);          free(inputC);         free(inputB);         free(inputA);          printf("execute challenge to win\n"); } 

Obviously, achieving an actual overwrite of an allocated chunk's metadata is trivial. However, I have not been able to find a way to exploit this code using any of the standard techniques. I have read and attempted to implement the techniques from:

• The paper: w00w00 on Heap Overflows
  • Although the paper is very clear, the unlink technique has been obsolete for some time.
• Malloc Maleficarum.txt
  • This paper expands upon the exploit techniques from the w00w00 days, and accounts for the newer versions of glibc. However, I have not found that given the 5 techniques detailed in the paper, that the code above matches any of the prerequisites for those techniques.
• Understanding the Heap By Breaking it(pdf)
  • The pdf gives a pretty good review of how the heap works, but focuses on double free techniques.

I originally tried to exploit this code by manipulating the size value of the chunk for inputC, so that it pointed back to the head of the inputC chunk. When that didn't work, I tried pointing further back to the chunk of inputB. That is when I realized that the new glibc performs a sanity check on the size value.

How can a user craft an exploit to take advantage of a free, assuming he has the ability to edit the allocated chunk's metadata to arbitrary values, and user it to overwrite a value in the GOT or write to any other arbitrary address?

Note: When I write 'arbitrary address' I understand that memory pages may be read only or protected, I mean an address that I can assume I can write to.

Answer 1

Note: I will say before I answer that this is purely an academic answer, not intended to be used for malicious purposes. I am aware of the exercises OP is doing and they are open source and not intended to encourage any users to use these techniques in unapproved circumstances.

I will detail the technique below but for your reference I would take a look at the Vudo malloc tricks (It's referenced in one of your links above) because my overview is going to be a short one: http://www.phrack.com/issues.html?issue=57&id=8

It details how malloc handles creating blocks of memory, pulling memory from lists and other things. In particular the unlink attack is of interest for this attack (note: you're correct that glibc now performs a sanity check on sizes for this particular reason, but you should be on an older libc for this exercise... legacy bro).

From the paper, an allocated block and a free block use the same data structure, but the data is handled differently. See here:

chunk -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          | prev_size: size of the previous chunk, in bytes (used   |          | by dlmalloc only if this previous chunk is free)        |          +---------------------------------------------------------+          | size: size of the chunk (the number of bytes between    |          | "chunk" and "nextchunk") and 2 bits status information  |   mem -> +---------------------------------------------------------+          | fd: not used by dlmalloc because "chunk" is allocated   |          | (user data therefore starts here)                       |          + - - - - - - - - - - - - - - - - - - - - - - - - - - - - +          | bk: not used by dlmalloc because "chunk" is allocated   |          | (there may be user data here)                           |          + - - - - - - - - - - - - - - - - - - - - - - - - - - - - +          |                                                         |          |                                                         |          | user data (may be 0 bytes long)                         |          |                                                         |          |                                                         |  next -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          | prev_size: not used by dlmalloc because "chunk" is      |          | allocated (may hold user data, to decrease wastage)     |          +---------------------------------------------------------+ 

Allocated blocks don't use the fd or bk pointers, but free ones will. This is going to be important later. You should know enough programming to understand that "blocks" in Doug Lea's malloc are organized into a doubly-linked list; there's one list for free blocks and another for allocated ones (technically there are several lists for free depending on sizes but it's irrelevant here since the code allocates blocks of the same size). So when you're freeing a particular block, you have to fix the pointers to keep the list in tact.

e.g. say you're freeing block y from the list below:

x <-> y <-> z 

Notice that in the diagram above the spots for bk and fd contain the necessary pointers to iterate along the list. When malloc wants to take a block p off of the list it calls, among other things, a macro to fix the list:

#define unlink( y, BK, FD ) {                 BK = P->bk;                               FD = P->fd;                               FD->bk = BK;                              BK->fd = FD;                          } 

The macro itself isn't hard to understand, but the important thing to note in older versions of libc is that it doesn't perform sanity checks on the size or the pointers being written to. What it means in your case is that without any sort of address randomization you can predictably and reliably determine the status of the heap and redirect an arbitrary pointer to an address of your choosing by overflowing the heap (via the strncopy here) in a specific way.

There's a few things required to get the attack to work:

• the fd pointer for your block is pointing to the address you want to overwrite minus 12 bytes. The offset has to do with malloc cleaning up the alignment when it modifies the list
• The bk pointer of your block is pointing to your shellcode
• The size needs to be -4. This accomplishes a few things, namely it sets the status bits in the block

So you'll have to play around with the offsets in your specific example, but the general malicious format that you're trying to pass with the strcpy here is of the format:

| junk to fill up the legitimate buffer | -4 | -4 | addr you want to overwrite -12 (0x0C) | addr you want to call instead

Note the negative number sets the prev_size field to -4, which makes the free routing believe that the prev_size chunk actually starts in the current chunk that you control/are corrupting.

And yes, a proper explanation wouldn't be complete without mentioning that this attack doesn't work on current versions of glibc; the size has a sanity check done and the unlink method just won't work. That in combination with mitigations like address randomization make this attack not viable on anything but legacy systems. But the method described here is how I did that challenge ;)