Dangling Pointer Exploitation
Posted in hacking, programming, lowlevel | by evilbitz |Just saw this: New hacking technique exploits common programming error on Slashdot.
Hmmm… It seems interesting, Exploiting a dangling pointer in a generic way seems to be far fetched IMO. Exploiting it in a specific way is much more feasible, but it’ll be dependant on the specific bug. Until they publish their research about dangling pointers and show that their method applies to ANY dangling pointer without modifications, its just marketing.
Using a dangling pointer in order to execute code may look like this:
- You cause function A to be called, where you can control the data of the local variables, when it returns the stack is prepared for function B and initialized with your data.
- You cause function B to be called (it could be the next function in the flow), where it takes a stack variable and decides to pass it by reference to function C, which has some arguments defined as “IN OUT” -> Function B holds the bug.
- In function C, the initialized data (you initialized it) is being treated somehow and might be exploited to execute code.
A common programming error?
Trying to think about a common programming error that could be exploited using a dangling buffer, I came up with this piece of code:
CHAR unintialized_data[64];
WCHAR wideLinkName[64] = {0};
…
swprintf(wideLinkName, L”\\DosDevices\\CdRom%d”, cdromNumber);
RtlInitUnicodeString(&unicodeLinkName, wideLinkName);
…
if (err) {
RtlFreeUnicodeString // <- You're dead!
}
What is common here you ask?
You should not use RtlInitUnicodeString to initialize a string that is located on the stack. If you’ll look at its implementation (ntoskrnl.exe), you’ll see that a UNICODE_STRING structure is just a placeholder for the pointer and the string length, a UNICODE_STRING structure is reffered as a “counted string“. This is not obvious for beginners, and they may think that RtlInitUnicodeString also allocates a seperate buffer. More specifically, the bug happens if calling to RtlFreeUnicodeString (maybe in some other function or alternate flow of code), This bug could be exploited since RtlFreeUnicodeString frees the buffer, which in our case is on the stack itself, and since you controll the buffer header using the dangling buffer, you could execute code -> using regular heap overflow techniques.