Tuesday 16 December 2008

Microsoft Security Advisory 961051

There is a lot of chatter around at the moment about a security vulnerability in all versions of Internet Explorer. What seems to have happened is:

1. Someone found a remote code execution vulnerability exploitable from IE.

2. Someone packaged a malware to install via this vulnerability. At the moment, the reports say that it is stealing game passwords but hey, if the bad guy can run arbitrary code then it could do more than that. The malware is not being recognised by much at the moment and could change at any time. The malware seems to have an all numeric name and load into svchost.

3. Someone hacked a bunch of websites to include malicious content. In most or all cases, this was done using a SQL injection attack. It continues to amaze me that there are still sites vulnerable to this class of attack as a trivial code review can find that type of flaw.

So, the situation as I write is that all versions of IE are vulnerable to this form of attack but you probably could not get infected via an HTML email because scripting is disabled by default and because on Windows Server 2003, 2008 and Vista, the rights used for HTML displayed in the mail client or the browser are so reduced that the malware shouldn’t be able to hook itself in.

Now, Microsoft are calling it an IE vulnerability but the mitigation advice includes unregistering oledb32.dll which suggests that it isn’t IE that is at fault – it is just passing along information from a script and the underlying OS has an issue. Now, if that is the case then I would be willing to bet that this was exploitable from Office as well but there are no current reports of this. The advisory also says that the issue is with data binding. Since OLEDB is a COM DLL and there is no direct way of calling into a DLL from Jscript anyway, the exploit is going to look like a couple of data binds, sharing an object of some sort. There won’t be an external database, just some XML embedded in the HTML.

One of the mitigations that Microsoft are offering is to turn on DEP which means that this has to be an old school exploit involving a stack overrun so you shouldn’t expect to see a separate payload on the heap. The installation code should be right there in the XML.

So far, there is no clear pattern as to what sort of sites are hosting this. A Chinese motherboard manufacturer, some porn sites, a Taiwanese search engine and a couple of sites in HongKong, most of which are in Chinese. Spotting a pattern? The hackers can speak Mandarin. What is being stolen? World of Warcraft passwords among others. I would suspect that a gold farming operation has decided to expand.

Much is being made in the press about how open Microsoft have been about this vulnerability and some people have drawn the conclusion that this is an especially bad vulnerability. Hmmm, does that bear up to examination? Remote Code Execution vulnerabilities are fairly common in all browsers. MS08-052 patched an important one in GDIPLUS, a much patched component. MS07-055 was another, that time in the vector markup parser – and again, it needed repatching later that year because the same errors were found in other code in the same module. MS07-045? Some were patched there too. MS07-058 also resolved remote code execution vulnerabilities accessible via Internet Explorer. On a technical level, the only unusual thing is that this particular vulnerability doesn’t need a separate payload on the heap. This one is only unusually bad because there are exploits on the web for it.

Signing off

Mark Long, Digital Looking Glass Ltd

No comments: