mikeymikec
Lifer
- May 19, 2011
- 18,417
- 11,032
- 136
You're most welcome. It is truly a Security matter. Thank you for initiating it.
Btw, there's a zero-day knocking around for Flash as well.
Have I been asleep? Where did this Security category come from? Not saying I don't like it, just surprised I missed it.
regsvr32 -u "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"
The fix is pretty easy:
Unregisters the never-used VML renderer, which stops this particular exploit.Code:regsvr32 -u "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"
Matter of fact, you can paste that into a text file on a flash drive and name it whatever.bat, and then you can fix all your machines with just a double click.
TBH it's been a while since IE has had a major exploit. They're doing pretty good. But question is, why are people still using that archaic browser?
Because it's to easy and expedient, and it disables one of their precious but useless inventions.If it's that easy, how come MS has yet to issue a patch?
Because it's to easy and expedient, and it disables one of their precious but useless inventions.
Why did the security firm that discovered it not quietly disclose it to MS?
TBH it's been a while since IE has had a major exploit. They're doing pretty good. But question is, why are people still using that archaic browser?
Erm, their "precious invention" predated SVG. Back when VML first came out, that was what you had to use if you wanted vector graphics. Hell, SVG hadn't even become a W3C rec when XP went RTM. Yes, in the time since, SVG was finalized and it took off, and Microsoft even deprecated VML in favor of SVG. That doesn't change the fact that over the course of VML's life, there have been uses for VML (even by Google!), and although most have now migrated to SVG, killing VML outright will break things and elicit cries of, "Stupid Windows updates, breaking compatibility all the time!" from some people.
It has been the standard browser at every company I've worked at, and that's because of app compatibility. SharePoint, for example, works best with IE.
If the above command breaks any functionality, re-run it without the -u with elevated (admin) privileges and everything will be back the way it was. It's easy and free, no hand-wringing required.
If the above command breaks any functionality, re-run it without the -u with elevated (admin) privileges and everything will be back the way it was. It's easy and free, no hand-wringing required.
I'm just sorry if my flippant attitude has caused anyone to reject and distrust a transparently harmless and easy mitigation method. I will now withdraw my participation.
I'm just sorry if my flippant attitude has caused anyone to reject and distrust a transparently harmless and easy mitigation method. I will now withdraw my participation.
Good info, thank you.(n.b.: On 64-bit Windows, the command posted in this thread only unregisters the 64-bit version of the COM object, which isn't the one used by 32-bit IE, and 32-bit IE is the default browser. The commands to unregister both the 32- and 64-bit copies can be found in the security advisory linked above, which also lists a number of other workarounds.)
I'm just sorry if my flippant attitude has caused anyone to reject and distrust a transparently harmless and easy mitigation method. I will now withdraw my participation.
I appreciated your posting the info. Thank you.
regsvr32 -u "%CommonProgramFiles(x86)%\Microsoft Shared\VGX\vgx.dll"
