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."
Who would have thought that invalid pointers and buffer overruns might be exploitable as a security hole?
Quick, someone alert Bill Gates!
I found that if I stop programming every 15 minutes or so and look up some pr0n, I significantly reduced my chances of having a "dangling pointer."
Presumably what they have here is a dangling pointer to a function, which they can get IIS to then call. They state that this used to be a "denial of service" attack - meaning that if IIS attempted the call before, it would execute garbage and cause a runtime fault. Now, however, they can change the value of the dangling pointer and when IIS does the jump this time, it executes their exploit code instead.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
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)
Garbage collected languages is no solution to poor programming. If you can't remember to not call a function pointer that you just freed, you'll probably forget to close /etc/passwd before dropping privs, or something equally stupid.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
I dunno. I manage to write C++ and never overflow a buffer, always release all resources when I'm done with them, and never throw away an error. Why can't the other 95% of the programmers out there do the same thing?
They are busy being yelled at by their boss to "just make it work" and to "not worry about getting it perfect" and they are dealing the idiot "build master" over in change-management who doesn't know what "make clean" is or how to read a make file, but thinks that he's some master csh hacker... Everyone wants that just not everyone works in a perfect world.
Shit, most of us are just happy when we are able to beat clear requirements out of people and get reasonable bug reports.
Pete/Petri "damn, my chainsaw is clogged with 1's and 0's again." --clyde
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.