Jump to content

Microsoft Security Advisory 961051


Recommended Posts

From this page:


I downloaded this file:


Which contains these files:



Would I be correct in assuming that if I were to execute one or both of them on a system that is vulnerable to the current IE data binding flaw, that the code would harmlessly spawn the calc.exe function?

Link to comment
Share on other sites

I couldn't make it work on 98 or 2000, even after fixing the path to calc.exe. On both it just used up memory. That code appears to be for IE7 only, but there are variants of it that work with IE6.


Edited by herbalist
Link to comment
Share on other sites

That code appears to be for IE7 only, but there are variants of it that work with IE6.

When you say "there are variants that work on IE6", do you mean

a) there is example code on milw0rm.com that will work on IE6? or

b) you are *speculating* that somewhere on the web real circulating code has been deployed specifically against IE6 or someone else has published example code that works on IE6, or

c) you are repeating the microsoft PR material that says that IE6 is equally (if not identically) exploitable.


Link to comment
Share on other sites

Milworm doesn't appear to have a variant that affects other versions of Internet Explorer at present. No, I don't have a sample that does affect IE6. Microsofts own advisory, what you call PR material says:

Microsoft Internet Explorer 5.01 Service Pack 4, Microsoft Internet Explorer 6 Service Pack 1, Microsoft Internet Explorer 6, and Windows Internet Explorer 8 Beta 2 on all supported versions of Microsoft Windows are potentially vulnerable.

They mentioned IE8, so they're not just steering users away from IE6. Their advisory also mentions

The vulnerability exists as an invalid pointer reference in the data binding function of Internet Explorer. When data binding is enabled (which is the default state), it is possible under certain conditions for an object to be released without updating the array length, leaving the potential to access the deleted object's memory space. This can cause Internet Explorer to exit unexpectedly, in a state that is exploitable.

More info on this here and here.

Link to comment
Share on other sites

So the code on Milworm doesn't affect IE6 (on win-98 systems anyways).

Does that mean we can assume that a single example of exploit code can't exploit ie6 AND ie7 at the same time?

What if the code at Milworm were to be run on XP-sp2 with IE6, and the exploit worked in that case? How would that alter your theory?

In any case, what do we know about the version history, and the similarities between the 9x and NT versions of oledb32.dll?

Link to comment
Share on other sites

What if the code at Milworm were to be run on XP-sp2 with IE6, and the exploit worked in that case? How would that alter your theory?

Getting the targeted application to execute the code is only half the battle. Assuming that the exploit code itself worked on IE6, it would then depend on the command or instructions that it's attempting to execute. The majority of the time, the injected command will direct the browser to download and execute a malicious file from a preset location. Quite often those instructions are to download and execute a single file, which may or may not affect a given OS. At times it's much more involved. The malicious site will attempt to determine the OS and browser of the target and select a payload specific for that target. In this situation, a 9X system can be very vulnerable. PoC demonstrations like the one from you linked to from milworm often fail to show the real abilities of the code because the location of the harmless item they use changes from one OS to another. In your sample, the path is invalid for 9X systems and Win2K. If you'd like to see a better example of how an application exploit works, take a look at this one. This one worked on 98 thru XP as a demonstration because the instructions it injects are understood on all the operating systems. Direct link to the PDF PoC here.


Did you try to open that file with another browser on XP? When I tried to open it with SeaMonkey on both 98 and 2K, I experienced the same memory drain that I did when I used IE6.

Link to comment
Share on other sites

The milworm html code page described above does not appear to trigger the exploit on an XP-SP2 system with IE6. The system in question was last updated / patched (via windows update) on October 29, and IE7 was never installed on it.

On that system, task manager showed that IE6 memory usage reached between 150 and 200 mb before it stabilized.

The exploit page took a few seconds to be processed, and resulted in a small blank frame in the upper left corner of the page with a small red X icon (similar to a missing page icon). I'm not sure if this is supposed to happen, or if it indicates that the second part of the exploit (the iframe.html page) wasn't found or loaded.

I had to turn off the information bar in IE6 in order for the page to load without requiring any user prompting or permission.

I've been looking for definative accounts that IE6 is vulnerable, or if IE6-specific test code is available. Best I can tell, Microsoft is the only source of the claim that IE6 is vulnerable (and all other web-info sources simply are repeating the MS claim).



"At first it looked like it was just an IE 6 thing on XP, but then it encompassed IE 7 on XP, and Vista platforms might also be impacted. Now it appears that all versions of Internet Explorer from 5.x up to 8 betas are probably at risk."



"Microsoft is continuing its investigation of public reports of attacks against a new vulnerability in Internet Explorer. Our investigation so far has shown that these attacks are only against Windows Internet Explorer 7 on supported editions of Windows XP Service Pack 2, Windows XP Service Pack 3, Windows Server 2003 Service Pack 1, Windows Server 2003 Service Pack 2, Windows Vista, Windows Vista Service Pack 1, and Windows Server 2008."



And this I don't understand:


In a revised security advisory, Microsoft said research confirmed that the bug is within all its browsers, including those it currently supports -- IE5.01, IE6 and IE7 -- as well as IE8 Beta 2, a preview version that the company doesn't support through normal channels. Users running any of those browsers on Windows 2000, XP, Vista, Server 2003 or Server 2008 are at risk, Microsoft said.


First, I don't trust that Microsoft is the only source of the claim that IE5 and IE6 are also vulnerable. I would like to see an independent confirmation of that.

Second, why is MS still supporting IE5.01 ??? I thought that they are ONLY STILL SUPPORTING 2K SP4 - if so doesn't that also mean IE5.5 or possibly 6 at a minimum - not 5.01?

And for all you firewall and AV fans, note this:


He also points out that anti-virus programs have turned up less-than-remarkable results for the exploit, with VirusTotal.com reporting that only four out of the 32 of these anti-virus programs flagged the exploit as malicious or suspicious.


It's like I always said. Your AV program will eventually tell you that your system is infected, but only a few weeks or months AFTER the initial infection. And even so, the detection will be of some other malware, not the original infector, and the AV software will be of no help in actually *removing* the malware.

Link to comment
Share on other sites

Guys, ole32db doesn't have a flaw, per se. It's the application calling ole32db that is doing the use-after-free that causes the exploit to be possible. Hence why mshtml.dll was patched in IE, rather than ole32db.dll. The vulnerability is in HOW the APIs that are called are used, not the APIs exported by ole32db itself.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...