Two Unofficial IE Patches Block Attacks

Pentrex writes "eWeek reports that two well-respected Internet security companies (eEye and Determina) have released unofficial patches to correct the vulnerability being exploited to load spyware, bots and Trojan downloaders on Windows machines. Microsoft isn't sanctioning the third-party patches, which include source code for review. As always, the advice is to weigh the risks before opting for an unofficial hotfix."

Comments

Other patches:

[NilObject]

There's two other patches out there that work pretty damn well:

1 and 2.

Re:Other patches:

[Volanin]

1. [apple.com] and 2. [mozilla.com]

Yeah, but only number 2 "include source code for review."

Re:Other patches:

[chrome]

Yeah, but only number 2 "include source code for review."

Not entirely true. You can review the code for darwin, and you can review the code for WebKit.

The only thing you can't review is the UI drawing code in AppKit/Quartz/Cocoa etc.

Re:Why doesn't Microsoft...

[Dante Shamest]

Why doesn't Microsoft just tell people to switch to Ubuntu and use Firefox? It would save them a hassle and a lot of work.

Are you related to my girlfriend? Because she asks smart questions like you. =)

Are there not risks even with official patches?

[El Cubano]

As always, the advice is to weigh the risks before opting for an unofficial hotfix.

Is this not something that smart admins/companies so even with official patches and fixes? To me, the fact that the source was released shows that these people are quite serious about being taken seriously. I suppose that is better than MS assurances that they extensively tested the fix before release.

Re:Are there not risks even with official patches?

[tshak]

I suppose that is better than MS assurances that they extensively tested the fix before release.

This quite far from the truth. Reading source code will not find the integration problems that can come up when you release a patch on millions of machines with different configurations.

Re:Are there not risks even with official patches?

[whitehatlurker]

And yet, we will accept the same from MicroSoft without the assurance of source ;-)

How do they even write these patches???

[MoxFulder]

I don't even understand how they manage to *write* third-party patches. I mean, it must be hard as hell to do without the IE source code. I think they write a separate DLL which acts as an intermediary to the flawed insecure library or something, but it sounds like an enormous pain-in-the-ass process. Or do these companies have access to MS code through Shared Source program or something?

Yep, the more I watch the ills that befall the Microsoft-bound, the more I'm happy with my decision to go Linux-only a few years back.

Re:How do they even write these patches???

[Anonymous Coward]

We certainly don't have access to Microsoft source code. I ran Internet Explorer in a debugger and traced through the execution of the exploit (which was publicly available at this point). Most memory corruption vulnerabilities result in an exception, which is caught by the debugger. Once you have the location of the exception, you can identify which function the vulnerable code is in.

Once I had the name of faulty function, I disassembled it using IDA Pro and found the bug by reading the disassembly. With enough reverse engineering experience reading disassembled code is not much harder than reading C source code. It just takes longer.

The IE vulnerability is caused by a funcion called with incorrect parameters which returns SUCCESS instead of an error code. The caller belives that the function suceeded and tries to use an uninitialized variable. The patch is a single byte change in mshtml.dll. The patched function now returns a valid error code and the vulnerability is stopped.

This free patch is just a demonstration of what we do every month as part of our LiveShield product. It is a lot more advanced, but the idea is similar. We use the vulnerability analysis techniques described above to create "shields" that detect and stop specific Microsoft vulnerabilities. The coolest part is that the shields can be inserted and removed at runtime, without having to reboot any of the running applications.

Alexander Sotirov
Security Research
Determina Inc.

Re:How do they even write these patches???

[romka1]

"The fix is a DLL that gets injected into all applications via the AppInit_DLLs registry key," Sotirov wrote in a message posted to security mailing lists. He said the DLL fixes the bug by patching a single byte in MSHTML.DLL when it is loaded in memory. "This change makes the 'createTextRange()' function return an error code instead of returning 0. This exactly how the problem was fixed in the latest IE7 beta from March 20," Sotirov explained.
from the article

Re:How do they even write these patches???

[QuantumG]

You should do your work here in Australia. We have laws that guarentee our right to reverse engineer software to fix security issues.

Re:How do they even write these patches???

[Anonymous Coward]

I don't use debuggers as much as you'd think. I prefer to disassemble the code and read it until I understand what's going on, and then confirm it with a debugger. Some other people use debuggers as their primary tool, and resort to disassembers only when they are really stuck. I guess it's just a matter of personal preference and temperament.

When I do use a debugger, it's usually WinDbg. I like the command line interface and it has very good support for all versions of Windows. A lot of other security researchers use OllyDbg. For kernel debugging I use both WinDbg and SoftIce. SoftIce has the advantage of being able to follow code from user space to kernel space and back, which is very useful for analyzing kernel vulnerabilities.

Alexander Sotirov
Security Research
Determina Inc.

But how many would install them?

[E IS mC(Square)]

Given the fact that the average IE user would not even be aware of the flaw, how would he even know such third party patches even exist?

Most of them are going to be patched only when MS releases the patch, AND they have selected to be updated automatically.

Its a horrible situation.

Re:Fat, slow, and lazy

[dtfinch]

If it was just a testing thing, they wouldn't wait until the 2nd Tuesday of the following month. Minor patches can wait, but delaying critical patches is inexcusable.

Applying Patches Is Not Free

[patio11]

Microsoft releases one patch day a month because their corporate customers, the lion's share of their market, demand it. And they demand it because "release a million little patches as soon as that individual patch is done" is unworkable in a corporate environment. You can plan around one big patch a month -- the magic word is "scheduled downtime". It is less bad for some customers to be periodically marginally more vulnerable for a period of two weeks or so then to be continusouly vulnerable to unscheduled downtime due to patching. "Publish early and often" works well with an enthusiast running one machine but when you've got an IT department overseeing a cast of thousands spread over 14 time zones things get a little more dicey.

Re:Applying Patches Is Not Free

[apoc.famine]

I'm missing the part where the sense is....If MS released all patches as soon as they were ready, everyone who wanted to patch right away could. If large corporate IT depts still want to patch every 2nd tuesday, they still can! Scheduled Downtime is Scheduled Downtime is Scheduled Downtime. I see no connection between when MS releases a patch and when an IT department schedules their downtime to roll that patch out. (Well, other than the fact that the patch has to come first. ;)

This whole "scheduled patching" bit really is BS. All it does is leave critical problems unpatched longer than necessary, so that managers can point to MS when bad shit happens to the network. "Well, we couldn't patch until two days after patch-day, because we needed to test the patches." works lots better than "We got fucked because I decided that it wasn't critical enough to test and deploy right away."

While I can see where it would make a lot of people more confortable to know that there is patching every third Wed or something, I just don't see the value in withholding critical patches because "they aren't scheduled yet". At the very worst, let the IT departments decide if they want to schedule additional downtime, because ultimately, they know whether it will affect their systems or not. But then again, MS knows best, all the time, doesn't it?

In memory fix

[roman_mir]

the patch fixes the affected DLL in memory by overwriting a byte that is stored in RAM for MSHTML.DLL this begs a freaking question, should a modern OS even allow some application to modify behaviour of another application in memory, especially behaviour of a system level application, an OS DLL? I believe the patch needs to be installed from an administrator account, but even then, this doesn't mean that it is good design decision, to allow an arbitrary application to overwrite in memory code of another application. Of-course if that wasn't possible this specific patch couldn't exist, but still, the OS allows questionable application behaviour to say the least.

Anyone remember?

[WalterGR]

Does anyone remember the previous third-party patch to IE? This is from December of '03.

Slashdot: "Open Source Firm Releases Patch for IE Bug [UPDATED]"

An open source and freeware software development web site has released a patch to fix the URL spoofing vulnerability in Internet Explorer... Update: Sadly, the patch appears to contain a buffer overflow and some possibly-malicious code. (link)