Researchers at Watchfire Inc. say they have discovered a reliable method for exploiting a common programming error,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
which until now had been considered simply a quality problem and not a security vulnerability.
Jonathan Afek and Adi Sharabani of Watchfire 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 server crashed in the middle of the scan and after some investigation, the pair found that a dangling pointer had been the culprit. This wasn't a surprising result, given that these coding errors are well-known for causing crashes at odd times. But after some further experimentation, Afek and Sharabani found that they could cause the crash intentionally by sending a specially crafted URL to the server and began looking for a way to run their own code on the target machine.
Afek, a senior security researcher at Watchfire, will give a presentation on the technique at the Black Hat Briefings in Las Vegas in August.
Dangling pointers are errors in software code that fail to refer to a valid object. Often the object that was referenced was deleted without changing the value of the pointer.
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.
But now that has changed.
Danny Allansecurity researcherWatchfire Inc.
"The common thought is that this kind of problem isn't exploitable. But we looked at this and thought, wouldn't it be neat if we could implement our own code on this server?" said Danny Allan, research director at Watchfire, based in Waltham, Mass. "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 to do this with generic dangling pointers and run our own shell code."
Afek and Sharabani's discovery is a major step forward and a scary one at that, given the ubiquity of this kind of coding error. The researchers initially were able to exploit the problem on Microsoft Corp.'s IIS 5.1, but Allan said that the technique works on any application in which there is a dangling pointer. Microsoft, of Redmond, Wash., addressed the problem in IIS with one of the July security bulletins, MS07-041 .
"The outcome is much like a buffer overflow. It's very severe," Allan said. "This is a bit of a Pandora's box and once we open it, it will be just the tip of the iceberg. This is a very prevalent problem, especially in low-level languages. A lot of times you might not know there's a dangling pointer."
Thomas Ptacek, of New York-based Matasano Security, said that although he has not seen Watchfire's research results, they sound credible and could be an important advance.
"If it's a new way to reliably exploit this, it's an important step because it's not just one vulnerability, it's a new class of bugs," Ptacek said. "Right now we're at a place where people don't take dangling pointers very seriously, but a lot of us have just been waiting for someone to come up with a reliable way to do this."
Dangling pointers are an especially scary problem for C++ programmers, Ptacek said.
"These bugs happen all the time, but they're very dependent on circumstances," Ptacek said. "The long and short of it is, if you can determine the value of the pointer, it's game over."
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.
"This used to be theoretical and academic. But once we gave them the proof-of-concept code, they were very concerned," Allan said. "They were very interested in the research behind it."
Allan pointed out that Java-based applications are not vulnerable to this exploit because the language has a built-in mechanism for deallocating memory.