Internet Explorer 0-day (take 2 of the last few days…)
The last zero day (activeX) seems to be less interesting than this NEW zero-day that really made a news splash in the last day. It looks as though this NEW 0-day affects VML… Incidents.org has good coverage here. Microsoft has an advisory up and they expect to release a patch on the next scheduled patch day (earlier if needed…. ahem….) Sunbelt is blogging about the “epic loads of adware” being pushed into systems via this vulnerability. Now, some workarounds….
ALTERNATIVE BROWSER is the first suggestion.
Unregister the dll responsible for vml….
“regsvr32 -u “%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll”
(from incidents.org – re-register after patch is out by the same command without the -u)
One of the lingering questions is IF the IE7 release candidate is vulnerable…. I haven’t tested, but my reading of the advisory suggests that the problem is the underlying WINDOWS dll, it doesn’t appear that it would make a difference which version of IE was installed. If possible, I may put that to the test soon.
–update 5 minutes after post–
I just noticed that incidents.org has a list of antivirus vendor detection (only MS at the moment catches the exploit). Also, they’ve removed the 0day label for this vml vulnerability instead, choosing to call it an “actively exploited unpatched vulnerability” in vml…. From what I read, this may have been known as early as June/July – I’m not clear yet on that angle.
insorg.org is reported as a carrier domain.
Also, The SecurityFix has coverage, he also notes that disabling javascript is enough to mitigate the risk. I’m not sure on this, it may just be that it blunts the exploit in some circumstances. Personally I’d feel a lot better using another browers at the moment….
I know that there are some saying that firefox is more of a security risk than internet explorer, which in some ways is mystifying as we don’t seem to see the massive unknown exploits attacking firefox and there seem to be fewer outstanding unpatched issues for firefox than ie…. Anyway, my personal preference is to have more than one browser installed on the system so you can adapt as the situation needs.
Sunbelt updates the unregister dll workaround with a more “international version friendly” variation…
“regsvr32 -u “%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll ”
javascript is just being used to cloak the exploit in some cases, so disabling javascript will prevent SOME of the current approaches to delivering the exploit, but not all.
–update 9/21/06–
It does seem that now the javascript disabling is fairly useless as javascript was just a cloaking method. Other methods have been spotted that disabling javascript does not blunt.
It DOES sound as though hardware enforced DEP can block it (George Ou) and he notes that even software enforced dep is claimed to stop the exploit as well (initially the wmf exploit was claimed to be stopped by software dep (Microsoft claimed this in an initial bulletin), a statement which was later proven false.) It’s too bad that SOME people still make software that’s incompatible with hardware DEP. (HP printer driver for the deskjet 5550 for instance.) I’m sure there are many software vendors that could help out the world by making sure their software is DEP compatible.
Code for the exploit is now publicly available and you might expect uptake to continue on the “usual suspect” type of sites.