Stockpiling Browser Exploits
Hi folks,
A really interesting development this month is that security researcher HD Moore has been stockpiling browser exploits, and is intending to release one per day for the month of July... see http://browserfun.blogspot.com/ . What this means is that he has been finding vulnerabilities in browsers, and then proving it by providing a proof of concept (PoC) exploit for each of them.
Most will be Internet Explorer/Windows, and most will be denial of service (that is IE crashers) as opposed to code-running exploits, but here's the potentially problematic part for users ... just about any application crash vulnerability can be turned into arbitrary code execution, if someone is determined enough to work at it. So there is an upside and a downside to what he's doing. The upside is that people can test their own browsers against his PoC, and can tell if they are vulnerable, and more importantly, they can also use the PoC to test their defenses, once they have a patch or some other form of defense in place. The downside is that the Bad Guys watch for these announcements too, and it provides, if not a roadmap for them, a really good clue about how to exploit the vulnerability. Should HD have released them this way? That's a matter for individuals to decide for themselves, but at least it will force a clean-up of a bunch of browser bugs.
It does, however, present Microsoft with a dilemma. They can't possibly patch and test them all (however many of the vulnerabilities are with Internet Explorer as opposed to some other browser) within the month, so which ones do they deal with first? And will the Bad Guys choose one, some or none, to turn into code executers? And if they do attempt something, how long will it take them? We're watching with bated breath.
In the meantime, our plan is to simply add detection for them all as they're released, and monitor the situation. That way our users will be protected, and if the exploits never make it into the wild, we'll just remove the signatures at an appropriate time in the future.
Cheers
Roger
posted by tcsl @ 10:50 PM
1 Comments:
SocketShield handles this just fine. In every case (except many exploit proof-of-concepts) there is the exploit code and the payload. I like to think of these as the bag (the exploit code), and the bomb inside it (the payload) - respectively. This question really goes to the issue of payloads.
One approach for payload prevention might be to watch for a particular code execution behavior whereby something does the equivalent of a shellexecute and simply runs a program. This is what both the WMF and MDAC exploits do (they exploit security vulnerabilities).
However, because we watch for the fingerprint of the exploit itself (the bag) and stop it long before it runs, the shellexecute in the payload (the bomb) never sees the light of day.
Other exploits, like CreateTextRange, rely on an application crash with a runaway instruction pointer (denial of service vulnerability with code execution). Again, because we spot and stop the bag, the runaway instruction pointer never gets to memory to run.
Joe Chiarella, Product Manager and Greg Mosher, VP Development.
Post a Comment
<< Home