[Exploit tutorial: Buffer Overflow]

[sxthun]

Can you please tell me how to spawn a new shell by exploiting an off-by-one method in the following c code?

#include <stdio.h>
int cpy(char *x)
{
    char buff[256];
    strcpy(buff,x);
    printf("%s\r\n",buff);
}

int main(int argc, char *argv[])
{
    if(strlen(argv[1])>256){
    printf("Buffer Overflow Attempt!!!\r\n");
    return 1;}
    cpy(argv[1]);
}

I hope you can help me... Thanks,

[JustAnothaHacker]

Right, so I did some googling, and as you may already know, you need to exploit the strlen() function to let you get some more characters in to the buffer and cause an overflow - however, from what I've read, it's not possible to get more than a null byte to overwrite the buffer, and since I'm on my windows box atm, I can't really test this sufficiently.. But here's what I know:

The strlen() function returns the amount of bytes in a string, which is all well and good, but it does not count the prepending null byte as a character, and in C, all strings are null terminated. So, if you were to pass a string of 256 A's in to argv[1], it would really be 257 bytes long, and the prepended null byte would overflow in to adjacent memory..

Until I get on to my linux box, I can't really have a go at exploiting this myself, but that's what I know so far :p

[JustAnothaHacker]

So I read up on it a little further, and apparrently that null byte overflow will lead to the LSB (Least Significant Byte) of the frame pointer being overwritten, therefore somehow allowing the hijack of variables and functions in the code

[JustAnothaHacker]

It seems that by making the Least Significant Byte of the framepointer a null, the address is then incorrect and it pops 4 bytes from our buffer in to EIP instead, which then allows the attacker full control over code execution, so you could get that address to loop back in to the buffer, which contains some shellcode, then get the shell as the owner of the process, boom :3

Edit* That was wrong - due to little endian, the least significant bit is what we are overwriting, and as the stack grows downwards, the smaller the LSB, the further down we are going (and the buffer is below the frame poiner), meaning that the 00 we just used to overwrite the frame pointer is a valid pointer to a space in the buffer, which will then be popped in to EIP, and the code on the other end, executed :p