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."

Comments

Re:Pleasantly surprised!

[Wavicle]

Yes and no. The pointer in question may have a lifetime greater than that of the object being pointed to. Example:


void (*myFuncPtr)() = NULL;

void cleanUp() {
    item listItem = firstItem;

    while ( listItem != NULL ) {

        myFuncPtr = listItem->fcn;
        myFuncPtr();

        tempItem = listItem->next;
        free(listItem);
        listItem = tempItem;
    }
} // myFuncPtr is now dangling!


A little contrived, sure, but it is an example of how a pointer might get left dangling.

- It doesn't have to be a function pointer.

[DogFacedJo]

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.