In the previous part of this series we introduced remote code arbitrary execution via buffer overflows using all of our past experiences.
As I said back then, today I'll be explaining the other way you may use to redirect execution flow: using a NOP sled, along with some other informations I gathered to conveniently end this first part of the guide to then start preparing some new topics.
In the last few days, a new vulnerability has been discovered, called the VENOM vulnerability.
The guest operating system communicates with the FDC by sending commands such as seek, read, write, format, etc. to the FDC's input/output port. QEMU's virtual FDC uses a fixed-size buffer for storing these commands and their associated data parameters. The FDC keeps track of how much data to expect for each command and, after all expected data for a given command is received from the guest system, the FDC executes the command and clears the buffer for the next command.
This buffer reset is performed immediately at the completion of processing for all FDC commands, except for two of the defined commands. An attacker can send these commands and specially crafted parameter data from the guest system to the FDC to overflow the data buffer and execute arbitrary code in the context of the host's hypervisor process.
As you can see, even a so known and used piece of code like this can host very serious vulnerabilities, exploitable via relatively easy techniques. They are just waiting you to discover them!
Today, I got a schedule that looks a little bit different than always.
After repeating the last words of the previous part, I will introduce the NOP sled technique, how it works and on what relies: we'll then try the technique to run arbitrary code in our case, but first we'll try to predict where the sled should be, so that we can write down a general formula to apply when doing this process.
Finally, we'll try out the formula and provide examples of special cases to conclude this first trilogy of topics. Don't worry, the real end is not even close, so keep coming!
Starting from where we left.
Let's start this off by making some assumptions and preparing the context. How should our input string look like if using the NOP sled technique?
How can we predict where the NOP sled approximatively will be in memory?
If we are able to get a fixed standard ESP value, we can then add and subtract from that all the variables that might affect the differences between our program's stack and a standard one. This is a technique that was first introduced by Aleph1 in his famous "Smashing the Stack for Fun and Profit", I'm just trying to break it into steps so it's easier to follow and reproduce.
If you can't read the code, here it is:
unsigned long get_sp(void)
Obviously, it's C code, and at this point you should be able to compile it.
Now that we now what's the minimal ESP value we can get (thus, the littlest stack), we can write down the formula and test it.
Where we conclude the explanation of the topic with bytes alignment and a proof that, under gdb (remember, all of this just does't work out of a controlled environment like this, we will discuss mitigation later in the series), we are able to get a shell on the system.
Aleph1's "Smashing the Stack for Fun and Profit"
"Hacking, The Art of Exploitation"
"Buffer Overflow Demistified" by murat.
"The Shellcoder's Handbook"
Part 1 of "Attack On Stack"
Part 2 of "Attack On Stack"
Part 3 of "Attack On Stack"
Part 4 of "Attack On Stack"
Part 5 of "Attack On Stack"
Prelude to Reverse Engineering: IDA and Hopper Binary Patching Introduction
64 bit shellcoding by Winter Drawlace
Hey everyone! How is it going?
Glad to say, I finally finished publishing the almost 90 pictures that I started preparing around two months ago. Once again, I'd like to thank the user CyberHitchHiker, that kept me going with this project. When I asked him how could I start learning these things, he first introduced me to the NOP sled technique as a starting point. Even if I wasn't able to explain the topic like a real teacher would do, I hope that at least I provided you strong bases to then study it yourself. I strongly recommend you to study the references too, my job is only a synthesis of what's written there.
However, this series is not finished yet. During the holidays, I'll continue studying and building new chapters with new exploitation techniques, story, culture and new references.
Again, the feedback was overwhelming, so, even if I didn't thank you one by one, I do it here: thank you guys for everything! You helped me go trough a tough time in my life (I owe you all the good results I was able to achieve), but now I have time to continue provide Null Byte with new contents, especially about this topic, so keep coming!
To those who are daily, monthly visitors of Null Byte, to those that are not here anymore, and to all of those who constantly fight for knowledge, no matter what: thank you for being there, you are way more special than you could ever think.