Network News

X My Profile
View More Activity

Guarding Against the New IE Exploit

Earlier this week Security Fix wrote about a newly discovered vulnerability in Microsoft's Internet Explorer Web browser that bad guys were exploiting to install malicious software when users merely browsed certain nasty Web sites.

That post advised users who wanted to continue using IE to jack up the Javascript security settings on the browser, but as the most recent attacks with this exploit have shown, the bad guys don't need to use Javascript to execute their attacks with this vulnerability.

Microsoft has since published an advisory with a workaround that seems to be pretty effective at stopping these attacks, pending the release of a patch from Microsoft (the company says it may not arrive until Oct. 10). The temporary fix involves "unregistering" the vulnerable Windows component, and is pretty straightforward step that should help mitigate this threat.

The problem is present in all versions of IE 5.0 and higher, according to US-CERT. I have not seen anyone test this exploit against IE 7 yet, but I've not heard of any evidence that the later version is vulnerable.

The following workaround works on Windows XP Service Pack 1 and 2, Windows Server 2003 and Windows Server 2003 Service Pack 1:

1) Open up a command prompt: Click "Start," then "Run," and a text box should pop up.

2) Cut and paste the following text into that box: regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll

3) Then hit enter or click "Ok." You should then receive a pop-up window stating that the vulnerable component has been unregistered.

Even if you don't use IE as your default browser, disabling this Windows component may prove essential. One need only look back at the security headaches Windows users had earlier this year with the Windows meta file (WMF) vulnerabilities, when Microsoft was forced to issue a patch outside of its normal monthly patching process in part due to the creation of unofficial patches from third-party security vendors.

With that problem, it was sufficient for Windows users merely to have the vulnerable WMF component active on a system for it to be compromised by a variety of different means, whether through a third-party e-mail client or other software that might invoke the flawed component.

Incidentally, anyone willing to take bets on how long it will be until we start to see a repeat of third-party patches to fix this problem?

By Brian Krebs  |  September 21, 2006; 2:29 PM ET
Categories:  Latest Warnings  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Newly Detected IE Exploit Spells Massive Spyware Trouble
Next: Apple Issues Patches for Laptop Wireless Flaws

Comments

Brian,

What do you know about some malware named Movieland and how can we shame them from loading on unsuspecting people's computers?Please contact me at Cox_xe@yahoo.com

Thanks,

MsFixIt.

Posted by: MsFixIt | September 21, 2006 2:52 PM | Report abuse

Thanks for the tip. I've unregistered the vulnerable component. But I have two questions:

1. Will unregistering this component cause any problems when surfing the Web? I use Firefox for most things but I also make use of IE.

2. When Microsoft issues a patch, will it re-register the patched component?

Posted by: William | September 21, 2006 3:06 PM | Report abuse

William -- Thanks for the question. I don't know any programs that require the vulnerable component besides IE, so it's probably not exactly like the WMF problem where disabling the DLL caused some thumbnail images not to render.

IF, however, you find this does cause problems, you can re-register the DLL by opening up the Run prompt again and typing:

regsvr32 "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll

I don't know what Microsoft's approach will be in patching this flaw, sorry. I'll check back and see what the experience was from the WMF patch earlier this year for people who had unregistered the WMF dll. If I find out I'll post back here.

Posted by: Bk | September 21, 2006 3:16 PM | Report abuse

Thanks for the update, Brian. I was afraid that disabling scripting might not be enough.

With regard to William's questions earlier, my understanding is that 'vgx.dll' handles VML [Vector Markup Language] processing, so that some pages may not render properly in IE. Fortunately, I don't think that VML is all that widely used.

As far as re-registering the DLL goes, it appears that the "unregistration" does not survive a Windows reboot. I'm still testing this, but you may actually need to apply this fix each time the machine boots. [sigh]

Brian: one minor correction. There is a missing double-quote (") at the end of your 'regsvr32' commands, in the original article and in your comment above. This might confuse some folks. The double-quotes are needed because there are spaces in the path. (Since this is a family show, I will not express my opinion of that "feature".)

Rich [richg74 AT gmail DOT com]

Posted by: Rich Gibbs | September 21, 2006 5:01 PM | Report abuse

Brian,

Thanks for these updates. However, both of your regsvr commands above need trailing quotes in order to work.

Posted by: scottr | September 21, 2006 5:10 PM | Report abuse

Rich,

While I am not disagreeing, what makes you think the unregistration does not survive a reboot? When I just ran the unregister command several times in a row (to write instructions for my users), each time it gave me the same result dialog, saying the unregistration was successful. Is there a way to query the registry to find out if a DLL is registered?

Posted by: scottr | September 21, 2006 5:13 PM | Report abuse

ScottR (and everyone):

I have now checked on the "durability" of unregistering the vgx.dll, and it DOES survive a reboot. That is, once it's unregistered, it seems to stay that way unless you manually re-register it. I'm afraid I jumped to conclusions based on the same behaviour that you observed. Mea culpa.

There is a change in the registry, under this key:
HKEY_CLASSES_ROOT\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

(There's a corresponding key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID )

Fortunately, I think you can just use REGEDIT to search for 'vgx.dll'; if it's not there, the component is not registered.


Rich [richg74 AT gmail DOT com]

Posted by: Rich Gibbs | September 21, 2006 6:27 PM | Report abuse

One more way for people to protect themselves is to utilize Hardware enforced DEP.

Read about it here:
http://blogs.zdnet.com/Ou/index.php?p=324

Posted by: Big Geek Daddy | September 21, 2006 7:58 PM | Report abuse

"Incidentally, anyone willing to take bets on how long it will be until we start to see a repeat of third-party patches to fix this problem?"

I'm afraid the betting window will have to be closed. E-week now has a report of a third-party patch:

http://www.eweek.com/article2/0,1895,2019162,00.asp

Posted by: Rich Gibbs | September 22, 2006 10:52 AM | Report abuse

For the curious, that third-party patch is available here:

http://isotf.org/zert/

Disclaimer: I haven't even looked at it yet.

Posted by: Rich Gibbs | September 22, 2006 12:22 PM | Report abuse

If my computer is restarted, will this component stay unregistered, or will the boot-up process reregister it?

Posted by: Michael | September 22, 2006 12:28 PM | Report abuse

Thanks for providing the workaround fix! One question though...

The article states:

"The following workaround works on Windows XP Service Pack 1 and 2, Windows Server 2003 and Windows Server 2003 Service Pack 1"

Does this "workaround" also work for earlier Windows versions as well (i.e. Win 2000, 98, 98SE/ME, 95)?

Thanks again,
COMPUABLE

Posted by: COMPUABLE | September 22, 2006 12:39 PM | Report abuse

Michael,

As far as I can tell, the "unregistration" of the VGX.DLL does persist across reboots. (As I should have mentioned before, my tests were with Win XP + SP2 + subsequent patches.)

See comments by 'scottr' and me yesterday.

Rich

Posted by: Rich Gibbs | September 22, 2006 2:56 PM | Report abuse

Unregistering failed on my win 98 computer. The error message said "GetLastError returns 0x00000485. Have I done something wrong? is my comp already infected? Just wondering if anyone has any ideas.

Thanks

oh the first sentence of the message was something like :LoadLibrary(long expression) failed..

Posted by: Ed | October 2, 2006 4:19 AM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company