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."

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:But later

[Anonymous Coward]

No, both our and Eeye's patches don't overwrite the actual files on disk. Eeye redirects the file to a patched copy, Determina fixes the bug by applying the patch when the faulty DLL is loaded in memory. When Microsoft releases the official patch, it will replace the file on disk and the Determina patch will not apply any more. I am not sure if you have to uninstall the Eeye patch or not, but it won't cause any catastrophic failures either.

Alexander Sotirov
Security Research
Determina Inc.

Tested and deployed

[ninja_assault_kitten]

I had our IT department test and deploy the silent installation this morning. We're a web-based software company and there's been zero reported impact to our development staff as 6pm EST.

While it's clearly not the best solution, it does work and provides a much needed layer for the vast majority of corporations who simply cannot and will not disable active script.

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: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.

Assembler and debugging references

[AltControlsDelete]

For x86 assembler, Intel is a good source of information: http://www.intel.com/design/Pentium4/documentation .htm#manuals [intel.com]. You'll want to check out volumes 2A and 2B at a minimum for reference material.

I would be surprised if Alexander used the Visual Studio debugger; more likely he used SoftICE or one of the Windows debuggers (NTSD/CDB/KD/WinDbg). SoftICE is a commercial product sold by Compuware and provides both user-mode and kernel-mode debugging. A version of the NTSD debugger comes with Windows, but is less useful than the one that comes with Debugging Tools for Windows [microsoft.com]. NTSD and CDB provide user-mode debugging, the only difference between the applications being that NTSD opens a new console window and CDB does not. KD is the kernel debugger. WinDbg provides the same functionality as NTSD/CDB/KD but with a (spartan) Windows interface.

Re:opensource?

[Zarel]

From the article:

"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.

Re:Applying Patches Is Not Free

[Anonymous Coward]

You are right, but that's not how the industry looks at it. The time to patch after a patch is released is more of an audit issue. Most companies can cram in a patch outage once a month, but not more then that. Waiting a month on a critical vulnerability that has a patch is not acceptable by most security standards published. However, if there wasn't a patch released for 3 weeks for that vulnerability, and then you patch one week after (same amount of time vulnerable), then you're compliant.

It's stupid, but that's how it seems to work. I'd say that it doesn't work, because security organizations end up spending a lot of extra hours attempting to mitigate the risks. (AV/IDS/Reg hacks/etc..).

For this exploit, I've deployed an IDS signature in IPS mode (drops the exploit packet) for all non-SSL traffic in my company, and rely on content filtering and anti-virus to do the rest. After all this testing and effort on the side of security, and we still have a risk.