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!
..is down to dangly bits.
Enough with all of this talk of "dangling pointers" you perverts.
Dedicated Cthulhu Cultist since 4523 BC.
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."
Finally, an indisputable reason for choosing Java over C++.
occultae nullus est respectus musicae - originally a Greek proverb
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)
"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?
And this isn't a "use Python" or "use Java" rant, either. I will say, however, UNIT TEST YOUR SHIT! EVERY LINE! Even the little inline function, you need to test it all! Repeat after me: Resource Acquisition Is Initialization. Resource Release Is Destruction. -Wall -Werror, no, warnings aren't OK. No, not even signed vs unsigned comparison warnings, you need to either get your data types straight or wrap that in a partial-specialization template functor that correctly checks that you won't be killed by sign-promotion when you compare int and unsigned long long. strncpy(), not strcpy()! -fprofile-arcs -ftest-coverage! Valgrind!
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?
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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>
But wouldn't said exploit code need to reside in a part of memory that the operating system had previously allocated for executable instructions? I mean I can understand how you could potentially make code that was already part of the program execute without the intention of the programmer, but how do you make code that isn't part of the executable in the first place execute? I mean sure you can put the opcodes for particular instructions into data space, but if you try to branch there, why would the OS even allow that unless the area the program uses for data is also marked as an area where executable instructions can be?
File under 'M' for 'Manic ranting'
The OS has very little to do with it. It's the hardware, specifically the MMU, which will do this checking. If you are using something like OpenBSD, then it will not let a page be both executable and writeable at the same time, but that requires doing some messy things with segments on x86 (unless you have a new chip with page-level execute permissions). On most x86 hardware, if memory is readable, it is executable, and anything you allocate with malloc() and friends will have read/write/execute permissions.
I am TheRaven on Soylent News
From the article:
Dangling pointers are quite common, but security experts and developers have said for years that there is no practical way to exploit them, so they've been considered quality-assurance problems and not security flaws.Any security expert with at least half a brain is going to assume that a remotely-triggered crash might be exploitable, unless he can actually prove otherwise.
That said, I've known plenty "security experts" who weren't.
http://outcampaign.org/
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.
They are not saying they "change the value of the dangling pointer".
From the FA: "The problem before was, you had to override the exact location that the pointer was pointing to. It was considered impossible. But we discovered a way... The long and short of it is, if you can determine the value of the pointer, it's game over."
There are theoretically two ways to exploit a dangling pointer - change the address that it points to (which they don't do), or discover the address it is pointing to, and put some code there (considered impossible). Most likely, it is pointing to memory space within the program that once held valid executable code. They say this "was considered impossible, but we discovered a way". So I suspect they just stuck a jump instruction at the location the pointer was pointing to instead of trying to cram executable code into an unknown sized space. The jump would of course be to some space they allocated, with a known size, big enough to hold their exploit. Determining the value of the dangling pointer would be easy enough - you would get a message when it crashed that the app tried to access invalid memory at addr: 0x????????. Just stick a jump at that location - then get a big warm hug from Microsoft when you show them how you did it.
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.
"This is a bit of a Pandora's box and once we open it, it will be just the tip of the iceberg."
Did anyone else think:
"If we hit that bullseye, the rest of the dominoes will fall like a house of cards! Checkmate." - Zapp Brannigan
https://www.accountkiller.com/removal-requested
Mozilla has considered dangling pointer use to be "probably exploitable to run arbitrary code" for a long time. I even blogged about that fact, describing what types of dangling point use are most likely to be exploitable. If other software companies refuse to prioritize those bugs until the reporter supplies a demonstration exploit that launches calc.exe or Calculator.app, they've been asking for trouble for years.
The shareholder is always right.