Slashdot Mirror
New Hack Exploits Common Programming Error
buzzardsbay writes "TechTarget's security editor, Dennis Fisher is reporting that researchers at Watchfire Inc. have discovered a reliable method for exploiting a common programming error, which until now had been considered simply a quality problem and not a security vulnerability. According to the article, the researchers stumbled upon the method for remotely exploiting dangling pointers by chance while they were running the company's AppScan software against a Web server. The good folks at Watchfire will detail the technique in a presentation at the Black Hat Briefings in Las Vegas in August, Fisher writes."
OK, you load the code into memory with the dangling pointer, now, how to you get the instruction pointer to go and execute said code?
well duh yourself... none of the smart minds looking at this, obviously a lot more retarded than you are, thought it was possible to do this for years.
But I guess you have no clue about programming and what dangling pointers really are, and you're just replying cause it's slashdot..
"When Watchfire first alerted Microsoft's security response team to what Afek and Sharabani had found, they were met with skepticism, and understandably so, Allan said. The company had known since 2005 about the IIS bug that caused the crash, but it was considered a simple denial-of-service problem and not remotely exploitable."
Worded a little ambiguously, but I presume it's Microsoft their talking about... How can a bug like this get through the QA process since 2005 and multiple product versions without getting fixed?
Yes and no. The pointer in question may have a lifetime greater than that of the object being pointed to. Example:
// myFuncPtr is now dangling!
void (*myFuncPtr)() = NULL;
void cleanUp() {
item listItem = firstItem;
while ( listItem != NULL ) {
myFuncPtr = listItem->fcn;
myFuncPtr();
tempItem = listItem->next;
free(listItem);
listItem = tempItem;
}
}
A little contrived, sure, but it is an example of how a pointer might get left dangling.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Destroying a pointer isn't the same as destroying the object-pointed-to.
C++ gives you a lot of choices, and thus lots of ways to shoot yourself in the foot if you don't understand those choices and make the correct ones.
The backwards-compatible C-style "dumb" pointers don't do any reference counting, so there's no way for a heap object to know that it's no longer needed. There are other tools to do this job (auto_ptr and others) if that's what you want and need. And you could add GC to your C++ system if you want, though that still leaves you a window of vulnerability between end-of-life and actual cleanup. (Few heap management libraries zero out freed memory, so pointers inside deallocated objects can still be read; they may or may not point to still-valid objects. Even if these internal pointers are not "dangling", they're still a security hole if you hand them to other malicious code in the same address space.)
I have written a bunch of C code, and a little C++ code. I have made it a habit to set a pointer to NULL after I free the pointer's data. If I had code that allocates a FOO structure, I would make a function to free the FOO structure; in C, my FreeFoo() function would not take a pointer to a FOO, but a pointer to a pointer to a FOO, and after freeing the FOO it would set the pointer to NULL. Like so:
/* C code */
void
FreeFoo(PFOO *ppfoo)
{
PFOO pfoo;
assert(NULL != ppfoo);
if (NULL == ppfoo)
return;
pfoo = *ppfoo;
assert(NULL != pfoo);
if (NULL == pfoo)
return;
free(pfoo);
*ppfoo = NULL;
}
/* typical use:
PFOO pfoo = PfooNew(args);
...do something with FOO object...
FreeFoo(&pfoo);
*/
Note that if you acidentally try to double-free the FOO, the above code will not crash; the first free sets the FOO pointer to NULL, and the second one notices that the pointer is already NULL and exits early. It does assert() when you try to free a NULL pointer, so you can catch the error and see what else you might have messed up.
For C++ you should be able to write a template that takes a reference to any pointer type and applies the above logic.
I once had to maintain a legacy code base, a whole bunch of C implementing a fairly complicated application. The app had a whole bunch of crashing bugs. I went through and applied the above logic everywhere the app was calling free() and suddenly the app stopped crashing. I wonder if the previous developers were using a different compiler or something, and the dangling pointers just happened to work for them?
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
In OO languages a pointer to an object works almost as well. The object pointed to in many implementations begins with a type field. This is usually a pointer to the class's virtual function table - usually implemented as a table of function pointers.
That is to say - if the object is referenced through a bad pointer, *and executes* any methods of that object's type - then it could be used to run someone elses code. They'll need to have filled some memory with something that can be interpreted as a virtual function table that points at something that can be interpreted as code. Which is doable.
If the processor/OS has set an app to able to write to it's executable memory, then it is vulnerable to this class of vulnerability.
Many OS's and C++, Objective C and *java* implementations default to this.
Pascal and perl used (maybe they still do) stubby things that required that the *stack* be executable, nevermind just data... *buffer overruns* are much easier when the stack is executable.
Java is interesting. Modern VMs do a lot of dynamic optimization - this means that they write on code that is actually running. They need OS permission to do so (in decent OSs?) so now you *have* to give the VM's process that permission in order to run Java. Now any dangling pointers in the VM implemention are potentially exploitable. Or if the memory manager has a bug and improperly deallocates an object... Or if the application has to call a library and that library accidentally accesses a reference to an object that was already released by java. Or maybe the app calls the OS - and the OS has a dangling pointer (say to a data structure that the Java VM needed to allocate). If you can fill the Java heap with executable exploit data, then if someone, anyone, jumps into it - they are toast.
I hope this helps. There is likely an actual paper that they will present. It will document one or several of the myriad ways to exploit dangling pointers - hopefully more efficiently than previously.
After discussing it with a fellow developer, here's what we thought might be happening:
1. Application allocates a C++ object, deletes it, but continues to point to it. The exploit code is likely to force this condition. The attacker has to know the type (and size) of the C++ object.
2. Exploit code sends a packet to the server causing it to allocate memory of exactly the same size as the C++ object that was deleted and store the exploit payload in that memory. For example, in case of a web server it might be an HTTP request of size X or an HTTP request with multiple HTTP headers of size X, depending how the implementation stores whatever it receives on port 80.
3. The heap allocation algorithm would presumably re-use the space that was deallocated when the C++ object was deleted. The exploit payload is copied over into the allocated buffer, examined and discarded (e.g. the payload is not valid HTTP). This is OK since the dangling pointer is still pointing to the memory area with the exploit payload.
4. Now the exploit causes the dangling pointer to be used to reference a virtual function and it's game over.
The exploit payload needs to act like a virtual table. It can reference exploit code in itself or jump somewhere in the running process which would make it exploitable (e.g. "DeinitializeSecurity" function).
Hopefully the paper is more interesting than this.
Nope, because they get freed when it exits.
In short-running programs with no persistant side effects (sysv shared memory, semas, or msg queues, for instance) there's really nothing wrong with letting the OS clean up after you.
GC does eliminate a few classes of bugs: