SmashTheTux - 0x01
The second challenge off SmashTheTux demonstrates improper use of the printf function.
If user input alone is provided to the function, printf will evaluate user input as both a command -to compensate for the lack of format specifier- and input to print.
For example, if our input is “a string %x”, printf(text) would ultimately resolve to printf(”a string %x”)- as an argument has not been supplied for the value of ‘%x’, printf will simply pop the first hexadecimal number from the stack in compensation (I hope this is a satisfactory explanation behind the vulnerability!)
Now, onto the actual exploit, I opted to overwrite the GOT entry of exit with the address of a malicious environment variable holding simple execve(”/bin/sh”) shellcode- this isn’t a completely foolproof exploit as it also relies on the user having the permissions to actually create environment variables; in the situation of a privileged user attempting to gain root privileges via an SUID binary or alike, it’s actually very effective.
This was what I came up with:
The first 8 bytes here shows the GOT entry of the binary’s exit function plus the address+2 (this is because $hn writes 2 bytes at a time, thus we need to perform 2 overwrites on the GOT entry- a 4 byte pointer. The lower 2 bytes start at 0x08049754-%4$hn, the upper 2 at 0x08049756-%5$hn.)
Next, I filled the stack with 49143 characters via the %<int>x specifier- this sends the current address at the top of the stack to stdout padded with whitespace to match the specified length. %5$hn will write the current amount of characters in the buffer to the fifth address on the stack (this is 0x08049756 the second address in the first section, the location discovered by leaking the stack with the %x format specifier.)
I then repeated this step for the lower two bytes at address 54.
You’re probably wondering what the Hell’s going on if you’ve never seen a format string exploit; it’s actually pretty simple once you grasp the logic:
The two large numbers above correspond to our desired address in hex- 49151=bfff while 65482=ffca. Since %n overwrites the specified value with the length of the buffer thus far, this is (one of) the only ways to achieve a value overwrite in the event of a format string vulnerability.
You can attempt to use %n to overwrite all four bytes at once; this can take a considerable amount of time to execute as stdout then has to display these characters (which can be well over a million, should be enough to make you understand!)
I discovered the location of my variable on stack via GDB:
Can you spot my code environment variable I’m too lazy to highlight? The difference in address is due to taking the screenshot at a different time (atleast I think- I definitely got 0xbfffffca from this command when executing the exploit!)
I also put an NOP sled at the beginning to change the length of the shellcode from 23 to 32 bytes (keeps the stack neatly aligned and reduces the chances of leftover stack values interfering with the shellcode execution.)
Not the best screenshot as the exploit produced a lot of whitespace but you can see by the need to close the process that it was successful.
The hint provided was this:
So yeah, I think I can consider this exploit a bit more of a success: I didn’t make any alarmingly obvious noob mistakes and I also learned a little more about the effect environment variables can have on a vulnerable application.
I think I’ll be using pwntools in the future though: it seems to be a cleaner way of ensuring stdin doesn’t close upon execution of /bin/sh as I had to use ‘(./exploit.py ; cat) | pwnme’ or something similar to prevent this issue.
