Let’s have a look at the advisory published using Vulnerability-Lab:
This is a perfect example. I’ve got first only control of the ECX, but can gain control over the EIP and therefor application flow too. But what happens exactly ?
The content of the ECX (well at least only 4 bytes, because EAX is referenced as an address) will first be copied to the EAX. After that:
the EAX gets incremented by 12 (0Ch) and is then CALLed - so here could own shellcode be injected and executed. The published Proof of Concept only shows the explicit position of where the ECX gets filled:
After 744 bytes the following 4 bytes are used for the ECX:
Since the content of the ECX is read (and copied to EAX), you can simply replace the “boom” variable from the PoC script with something more useful: Let’s manipulate the ECX to point to the first address after the ECX location (which is 0x007F63A4):
and execute it:
The content of ECX (4bytes) has been copied to EAX, which means control over EAX! Next step: The EAX is read by the application, so all we have to do is put another manipulated address somehwere. What about taking just the next free address: 0x007F63A8 ?! This results in:
Execute and have a look:
Since the EAX gets CALLed we’ve got control over the EIP. Great it points to 0x007F63A8. Doesn’t it ? No, it doesn’t ! The application adds another 12 bytes (0Ch) to the location of the EAX, which moves it 12 bytes onward. To solve this, I add a small nopsled of 12 bytes:
Yay, I’ve got control over EIP due to the CALL which gets executed. Now I can do funny things, but let’s do it the easy way: Let’s just simply point the EIP to the beginning of our input string (which is 0x007F60B8):
Now the shellcode can be placed at the beginning of the whole input string. There are 744 bytes of space for the shellcode… but remember that the number of bytes to fill with junk is relative to the shellcode size, what means you have to decrement the junk1 value to make it working:
Launch the application! Great the calc.exe gets launched.
And by the way: This is quite a stable exploit, since we do not have to rely on 3rd party CALL addresses or something like that. It’s working on Windows XP SP3 and Windows 7 SP1 :-)
If you find other ways of exploiting, just leave a comment here :-)