Over the weekend 0-day exploit was reported in Microsoft Internet Explorer 6 and 7. Both Threatpost and Heise Security posted that the getElementsByTagName() JavaScript method within Microsoft’s HTML viewer has a dangling pointer. This leaves the browser susceptible to code injection; which in the best case crashes the browser, and in a worse case directs you to a malicious site.

In first tests by heise Security, Internet Explorer crashed when trying to access the HTML page. Security firm Symantec confirms that, while the current zero day exploit is unreliable, more stable exploit code which will present a real threat is expected to appear in the near future. French security firm VUPEN managed to reproduce the security problem in Internet Explorer 6 and 7 on Windows XP SP3, warning that this allows attackers to inject arbitrary code and infect a system with malicious code. Microsoft has not yet commented on the problem.

The workaround is to disable JavaScript until the patch is available. Yeah, yeah, I know, you have heard this before. And this means half the web pages you visit won’t work and every piece of online meeting software is completely hosed, so you will leave it enabled anyway. It was worth a shot. Be careful until you have patched.

Another post on the Hackademix site discusses a flaw with the IE 8 XSS filter.

… it’s way worse than a simple implementation bug. Its root is a flawed design choice: when a potential XSS attack is detected, IE 8 modifies the response (the content of the target page) in order to neuter the malicious code. This is, incidentally, the only significant departure from the NoScript approach, which modifies the request (the data sent by the client) instead, and is therefore immune. … IE 8’s response-changing mechanism can be easily exploited to turn a normally innocuous fragment of the victim page into a XSS injection.

I will update this post when I have additional information from Microsoft on either issue.