By Carsten Eiram
As everyone using Internet Explorer hopefully are aware of, then there's a new 0-day circulating. There has been a lot of confusion as to both the problem cause and the browser versions affected, but in this blog, I should be able to sort it all out.
Basically, this vulnerability was initially reported by everyone (including ourselves) as an XML processing vulnerability in Internet Explorer 7. PoCs and working exploits were immediately made publicly available by various sources and security vendors were quick to report that their products were successfully detecting attacks. But were they really?
My team and I take pride in delivering the most accurate vulnerability information available! In order to do so, we naturally have to go that extra mile compared to other vulnerability information providers and thus sort out the real cause of a vulnerability, filling in any blanks in the process. Naturally, nice Christmas postcards sent to our office as thanks or alternatively an Xmas beer cheers for us are most welcome.
After having published our initial advisory concerning this 0-day, one of my guys was therefore tasked with figuring out the exact nature of the problem. It turned out that a lot of available information and assumptions were wrong. Assumptions usually are, which is also why my department treasures the saying: "Assumption is the mother of all fuck-ups" (and people claim nothing good ever came out of a Steven Seagal movie)…
Yesterday, I therefore gave Microsoft a heads-up about this and then had our advisory updated accordingly. A binary analysis was also provided to the security vendors on our BA service to ensure that their signatures actually do catch attacks. Over night (Danish night that is), Microsoft updated their advisory to reflect this new information.
To clarify three common incorrect assumptions about this vulnerability:
Assumption: Only Internet Explorer 7 is vulnerable.
Correction: No, at least Internet Explorer 6 is also affected, but not by the public exploits that are currently available. According to Microsoft's updated advisory, IE 5.01 is also affected. We have not confirmed this yet, but it seems plausible.
Assumption: The core problem is related to XML processing.
Correction: No, it's related to data binding. Working exploits can be created nicely without using XML.
Assumption: Setting the security level to "High" for the "Internet" security zone or disabling "Active Scripting" support protects me against attacks.
Correction: Technically no. It is still possible to trigger the vulnerability. However, it does make exploitation trickier as it protects against attacks using scripting.
I think this is a perfect example of why a service like our BA Service is so important (and why we decided to provide it in the first place). Creating signatures based on publicly available PoCs and exploits, optionally supported by various commercial PoC and exploits offerings from some of the serious players in this industry is fine for quick protection (and a nice complement to our BA service).
However, it is often possible to construct these without knowing full details of the vulnerability. In order to successfully detect attacks, it is imperative to understand the underlying core problem of the vulnerability. Security vendors solely creating signatures based on available PoCs and exploits may often not fully protect against exploitation of a vulnerability.
In this case, any security vendor basing their detection rules on the publicly available exploits is not detecting attacks fully. Users should therefore not just browse around using their IE browser, thinking that they're safe. Setting the security level to "High" for the "Internet" security zone will somewhat protect you and combined with Microsoft's suggestions related to OLEDB32.DLL you should be able to keep your system to yourself.
Remember those postcards…
Chief Security Specialist
P.S. Speaking of insufficient IDS signatures, then we've received word that the common detections rules used by security vendors to detect MS08-070 (CVE-2008-4254) and MS08-073 (CVE-2008-4261) are not complete either. It should be possible to bypass them using attacks described in our BAs…