SmashTheTux - 0x05|0x06|0x07
So -after scratching my head over 0x08 for several days- I’ve decided to call it quits with SmashTheTux; I completed every challenge apart from the last (see my blog for earlier walkthroughs.)
Nonetheless, I really think SmashTheTux is a valuable experience for those interested in exploring virus and exploit development in the future (I say virus dev as the challenges force you to think more low-level.)
I’d also say -to a degree- it’s ideal for OSCP buffer overflow prep: not only is the first challenge a simple B/O similar to what you’ll encounter in the exam, but the experience of completing the 8 challenges (or 9; from the brief research I did, no one has managed to exploit 0x08) is also useful for building your confidence with using GDB and interacting with programs at a lower level.
Additionally, I found some of the challenges interesting as they required you to think independently of ways you could change the control flow of the program to achieve the desired reuslt- for example, I completed 0x04 (integer overflow) in a way different to hinted at (this is why I don’t look at hints- encourage that creative thinking, man!) and I feel there would have been a few interesting ways to exploit 0x05 (will be below somewhere.)
All in all, I definitely recommend this machine to anyone intrigued by low-level exploit development or to those who want to build their confidence in the use of GDB.
Anyway, enough rambling, time for my last 3 exploits.
0x05
Well, it’s lucky I don’t look at hints! 0x05 was a very basic program- a call is made to system which executes the passed parameter as a terminal command, displaying the contents of /home/tux and then exiting.
The only input we have control over here is the files that appear within /home/tux; as the output of the command is not being placed in any sort of limited buffer or printf call, there’s little we can expect to achieve here.
So... What we need to do is hijack the call to ls which is actually pretty simple:
These are the commands I used to redirect the call to ls- first I created /tmp/ls and inserted the directory of /bin/sh before changing the permissions on /tmp/ls.
Finally, I added /tmp to the PATH environment variable- that’s it. Very simple but very effective.
When ls executes, the shell will look for a program file called ‘ls’ within the shell’s environment (aka: it will check each directory specified in the PATH environment variable for an executable file named ‘ls’)
Since /tmp is now the first directory within the variable, it will look there first and execute our modified /ls file as a result. It kind of acts like a symbolic link- when /tmp/ls is executed, the shell will execute the line ‘/bin/sh’.
This challenge could have potentially be completed by creating an alias for ‘ls’ also, to be honest there’s probably a few little tricks that could have been done here!
Although not directly related to C vulnerabilities, it does demonstrate the danger of loose access rights and permissions: it was my ability to change critical environment variables that made this possible.
0x06
Ah another hintless one, and here’s me feeling clever for not looking at the hints. xD
Here we have another format string vulnerability within sprintf (the same as printf but content is placed into the specified string as apposed to STDOUT); this time we are limited to input (not including the null) of 64 bytes.
Obviously this means EIP overwrite must occur within the first 64 bytes of input.
With some trial and error, I discovered that popping 10 addresses from the stack got us to the point of EBP/EIP overwrite- now to simply place our shellcode and jump to it.
I simply placed my shellcode at the end of the payload and -using GDB- found the rough location of the code.
From here I just played with the found address until I had execution outside of GDB.
0x07
0x07 was very interesting for me as it was my first encounter with malloc and heap overflow.
We have 3 declared pointers to member structs- m1, m2 and m3. M3 is never interacted with further from it’s declaration.
M1 and m2, however, are allocated a memory size of 8 bytes, given their own id values and a further 8 bytes allocation for their name properties.
The first two commandline arguments passed to the program are finally copied into the name properties of m1 and m2 respectively with no length checks on the provided arguments.
It took me a while to analyze my exploit for this- I understand everything so well at the time but then I find I’ve forgotten why it actually worked. (Note to self: work on organization!)
After looking into it again, however, I understand the logic behind this attack:
With the input provided to argv[1], we overwrite the value of m2 with the address of exit, occurring just 4 lines below the second strcpy- if our buffer is on the heap, any changes to the stack shouldn’t effect the value copied to exit. This is followed by basic shellcode starting at 0x804a030.
In the strcpy call to m2->name, we provide the start of our heap stored shellcode.
This will be the moment when our shellcode is actually copied into the value at 0x80497f4.