In this post i will quickly show you an integer overflow found in OllyDbg v1.10. This leads to a buffer overflow, which can be exploited to execute code arbitrarily.
In brief, all you have to do is set the size of Resource table to 0xFFFFFFF7.
Olly adds 0x9 to 0xFFFFFFF7, which sums up to Zero due to an integer overflow. Zero byte is then allocated by calling the "GlobalAlloc" function. Finally the "_Readmemory" function is called to copy 0xFFFFFFF7 bytes to the newly allocated memory causing a buffer overflow. See the image below.
But wait, there is a minor issue that i need to shed some light on. The "_Readmemory" function, as its name implies, is a wrapper of the kernel32.dll "ReadProcessMemory" function. So why did this call succeed if the number of bytes to copy is that huge? the reason behind this is that the "_Readmemory" function checks to see if data at the target address is cached. If it is cached, the "memcpy" function is directly called and this is where the buffer overflow occurs.
Here you can find the demo.
You can follow me on Twitter @waleedassar
In brief, all you have to do is set the size of Resource table to 0xFFFFFFF7.
Olly adds 0x9 to 0xFFFFFFF7, which sums up to Zero due to an integer overflow. Zero byte is then allocated by calling the "GlobalAlloc" function. Finally the "_Readmemory" function is called to copy 0xFFFFFFF7 bytes to the newly allocated memory causing a buffer overflow. See the image below.
But wait, there is a minor issue that i need to shed some light on. The "_Readmemory" function, as its name implies, is a wrapper of the kernel32.dll "ReadProcessMemory" function. So why did this call succeed if the number of bytes to copy is that huge? the reason behind this is that the "_Readmemory" function checks to see if data at the target address is cached. If it is cached, the "memcpy" function is directly called and this is where the buffer overflow occurs.
Here you can find the demo.
You can follow me on Twitter @waleedassar
Great Work :D
ReplyDelete