Microsoft acknowledges "in the wild" Internet Explorer zero-day

Filed Under: Featured, Malware, Microsoft, Security threats, Vulnerability

Microsoft has published a security advisory of the heart-dropping sort.

An "in the wild" exploit has been spotted that can cause RCE, or remote code execution, in Internet Explorer.

RCE means a drive-by install, where simply looking at booby-trapped content such as a web page or image file can trick IE into launching executable code sent from outside your network.

There won't be any obvious warning signs, or "Danger, Will Robinson!" dialog boxes.

So, armed with an RCE exploit, a crook may be able to sneak malware onto your computer even if you don't take any obvious risks such as opening a suspicious attachment or agreeing to download a dubious-sounding file.

That's the worst-case scenario we're looking at here.

Details of the new exploit are scarce, but Microsoft admits that all IE versions, from 6 to 11 inclusive, contain the buggy code.

What to do?

There is no patch yet [2014-04-27T21:20Z], so a simple trip to Windows Update won't help.

→ Microsoft has issued an out-of-band patch (meaning no need to wait until the next Patch Tuesday). Fixes are available for all versions of IE, from IE 6 to IE 11, on all versions of Windows, including XP. (Updated 2014-05-01T21:2Z)

But the good news is that the attacks seen in the wild so far seem to have relied on hitting IE 9, 10 and 11, using Adobe Flash as a lever.

Note that the bug isn't in Flash, so this is not something Adobe can fix, nor its it Adobe's fault.

It's just that using specially crafted Flash files can help attackers prepare the contents of the memory on your computer in order to make a successful attack possible.

That means you can turn off what Microsoft calls Active Scripting in your browser (or set IE to prompt you before Active Scripts like Flash run), and increase your resilience against this latest attack.

Here's the click-sequence to get you to the right place:

Internet Explorer
  Tools
    Internet Options
      Security (➊ below)
        Custom Level (➋ below)
          Settings - Scripting 
            Active Scripting (➌ below)

Also, according to Microsoft, you can stop this attack by telling Windows to turn off an Internet Explorer extension called VGX.DLL.

The file VGX.DLL (a DLL is just a special sort of executable file) provides support for VML (Vector Markup Language), and vector graphics rendering, in IE.

So it sounds as though this vulnerability is somewhere in the VGX code.

→ Microsoft sent an email to state that unregistering VGX.DLL inhibits the attacks seen so far, rather than preventing all possible CVE-2014-1776 exploits. The bug is not, apparently, in VGX.DLL itself. (Updated 2014-04-29T22:25Z)

If you can live without VML, and you're comfortable with a command line, Microsoft suggests that the simple hack shown below will mitigate the risk of this exploit.

You can enter the command into the Start | Run window or at a command prompt:

"%SystemRoot%\System32\regsvr32.exe" -u 
   "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"

Once a patch is out for what we'll assume will become known as "the VML bug," officially dubbed CVE-2014-1776, you can always re-enable VGX.DLL, like this:

"%SystemRoot%\System32\regsvr32.exe" 
   "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"

(You'll need to have Administrator privilege to re-register the VGX DLL with the system.)

Currently-known exploits rely on an HTML/JavaScript part and an SWF (Flash) file to go along with it. Sophos Anti-Virus on all platforms detects and blocks these components as follows:

  • Exp/20141776-A : the HTML/JavaScript part
  • Troj/SWFExp-CV : the Flash part

What if I have XP?

Unregister the VGX.DLL file as shown above.

Never re-register it.

Listen to our "End of XP" podcast.


(Audio player above not working for you? Download to listen offline, or listen on Soundcloud.)

, , , , , ,

You might like

45 Responses to Microsoft acknowledges "in the wild" Internet Explorer zero-day

  1. Scott · 176 days ago

    Or, instead of unregistering "VGX.DLL", just install emet 4.1 & a host based intrusion detection system (based on snort). My few remaining XP machines were/are safe before the exploit was even developed and the moment the host base intrusion detection systems updates, my systems will be immune at the network level.

    • Paul Ducklin · 175 days ago

      EMET is certainly an option, too (for more details visit the Microsoft link given above).

      Network intrusion detection systems may or may not be able to detect this sort of attack, since the file containing the booby-trapped data may not be easily visible at the network level (e.g. due to obfuscation that is unravelled only at the application level), so don't use an IDS instead of, but as well as, an endpoint anti-virus.

      I'll take the risk of being commercial here (this is, after all, Sophos Naked Security :-) and say, "For a free UTM including an IDS - based, in fact, on SNORT - click the ad in the right hand column that says UTM Home Edition"...

      • Wren · 175 days ago

        Just commenting on requiring prompts for Active Scripting - I followed the steps above. In order to then view the Naked Security email and this article again, I had to click Yes on *104* prompts. Hoping a more practical solution arises quickly.

      • Scott · 174 days ago

        i honestly love the idea of Sophos UTM for home use. i am just having a hard time finding the right hardware to enable the best features and still making it energy/cost efficient.

        The reason i mention EMET 4.1 is that Fireeye (who discovered the exploit) stated in their testing it is effective in stopping the exploit. Not knocking your approach, i am just saying EMET 4.1 is almost a requirement at this point inorder to make any flavor of IE safe.

  2. auscompgeek · 175 days ago

    Microsoft appears to be calling this vulnerability the "Internet Explorer Memory Corruption Vulnerability" (see acknowledgements section of the MSA).

  3. Sonja · 175 days ago

    While it's nice to get directions for turning Active Scripting to Prompt on an individual machine basis, a group policy would be even better! Anyone have that quickly so I don't have to search it out?!

    • Sonja · 174 days ago

      I'm using a GP to disable Active Scripting in IE. No prompts but some sites just don't load. I'm telling users to try another browser until there is a fix for this (and Adobe Flash for that matter!) Here's the GPO I set:

      Computer Configuration> Administrative Templates> Windows Components> Internet Explorer> Internet Control Panel> Security Page> Internet Zone> Allow Active Scripting

  4. Guy · 175 days ago

    I know that it seems outrageous to suggest that you could use another browser, but,,, couldn't you, you know, use another browser?

    If you need to use IE for an old web-based applications, so long as you you only use IE for that application and don't wander around the web too much, risk would be mitigated that way, too, no?

    Am I being naive?

    • Paul Ducklin · 175 days ago

      No, you are not being naive at all.

      In fact, with Sophos's Endpoint product you can use the Application Control feature to prevent the use of IE, or any other browser that you don't want to have to support inside your organisation.

      In short, as well as blocking known-bad stuff like viruses, the product can block legitimate apps that just happen to be in a risk category you'd prefer to avoid.

      Indeed, there are good security reasons for avoiding unwanted browsers even in the absence of known exploits - the so-called "reduce your attack surface area" argument.

      Of course, other parts of the OS, or other applications, may also end up using the buggy parts of what sounds at first like an "IE-only" vulnerability, so avoiding the IE browser alone might not be enough to immunise you to this hole. There might be other code paths that end up in VGX.DLL. (Unregistering VGX.DLL ought to minimise or readicate the likelihood that any browser-like app would ever use it.)

      But using a different browser for your main interactive browsing needs would certainly do little harm in this case...and I know it seems outrageous to suggest that you could use a different operating system, but, y'know....you could if you wanted :-)

      • MikeP · 175 days ago

        My understanding is that IE is an integral part of Windows, any version, so cannot be removed. So by using another browser you are not removing the threat entirely, just making it slightly more difficult.
        If they found a way to start IE without any GUI then they could use this vulnerability potentially without you knowing until it's too late. I'm not a coding geek but I'm sure it would be possible?
        I have preformed both of the changes in my W7 system and the old XP Pro that is due for retirement when my pension allows.

        • Paul Ducklin · 175 days ago

          You could always tide yourself over by installing the Windows 8.1 trial...and then one day before it times out, do "slmgr -rearm" to get another 60 days. (Legally, of course.)

          Give yourself a few months to get the spondulicks together...

        • dave99999 · 172 days ago

          You wouldn't be making it slightly more difficult, for most people that would make it almost impossible. The exploit depends on not just IE, but IE accessing (particular) malicious websites. Nothing else in windows is going to be coded to access any of these sites.

  5. Magyver · 175 days ago

    Great work Paul. Per my arrangement with Sophos staff I'll do a rewrite post for all my readers with a link back to this page. This one is of sufficient importance to make my NFL fans focus on security, lol...

  6. RDKilgore · 175 days ago

    This article comes up under (or is linked from) the Sophos mobile android category of news. But, is there any concern that this vulnerability has any affect on android cell phones?

    • Paul Ducklin · 175 days ago

      Not sure why it came up under "Android." But no, this is not a bug that affects Android - only Windows-based operating systems.

      • RDKilgore · 174 days ago

        Thanks Paul. I was pretty sure that was the case, but needed to make sure.

  7. George II · 174 days ago

    What is the risk of unregistering vgx.dll? Do we expect some application programs not to run if we do this?

    • Paul Ducklin · 174 days ago

      Errrrrrrr...can't say :-) I imagine that any website that needs VML or vector graphics rendered won't work 100%. Whether that means you won't be able to use it, or just that the occasional diagram won't render presumably depends on how the site is designed and structured.

      The best way is probably the approach we recommend with Java (or, for that matter, Flash). Try turning it off/removing it and see if there is anything you need (or want) to do but can't...

  8. EMG · 174 days ago

    If users are non-admins (like most corporate environments should be), this should mitigate the vulnerability as the malicious software may not have the rights to be installed.

    • Paul Ducklin · 174 days ago

      It might limit the damage the vulnerability can do, but if the exploit triggers a drive-by download, then the malware that gets downloaded *will be able to anything that the logged in user could do*. (Unless the crooks also know about an "elevation of privilege" vulnerability they can use as well, though we have no evidence of that in this case.)

      This is malware, remember? It's not going to be put off by having only user-level privileges. Users can install and run software *for their own use*. When malware pwns your browser, it becomes you, and "your own use" becomes "its own use." Lack of admin powers makes things a lot better that they could have been...but they're still pretty bad once you're infected.

  9. John Smith · 174 days ago

    To get it working again (on 64-bit systems) you need to run 2 commands:

    "%SystemRoot%\System32\regsvr32.exe" "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"

    "%SystemRoot%\System32\regsvr32.exe" "%CommonProgramFiles(x86)%\Microsoft Shared\VGX\vgx.dll"

    Just running the 1st does not seem to restore functionality!

    Hope it helps.

    • Leslie · 174 days ago

      I need some help regarding the VML bug. I followed the instructions and did the command

      "%SystemRoot%\System32\regsvr32.exe" -u
      "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"

      I then tried the other command to put it back

      "%SystemRoot%\System32\regsvr32.exe"
      "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll

      I then received this error message The module "C:\Program Files\Common Files\Microsoft Shared\VGX\vgx.dll" was loaded but the call to DllRegisterServer failed with error code 0x80020009.

      I have Administrator privilege to re-register the VGX DLL with the system. I am running Windows 7 64 bit. My main concerns are will my pc be compromised in anyway after removing VGX DLL and if a patch is released will this have any affect on my operating system as it would appear I cannot return it back to how it was. Can system restore help in this situation? Any help would be greatly appreciated. Please no tech speak as I am not so pc savvy. Many thanks

      • Paul Ducklin · 174 days ago

        Try right clicking on the command prompt icon and do a "run as administrator"...*then* running the command to re-register the DLL at that "admin" prompt.

        Exit from the prompt window once you are done, for safety.

        Worked for me.

        • Leslie · 174 days ago

          Thanks Paul, it worked for me too. The posting by John Smith said that he had to do two commands with the CommonProgramFiles(x86), however I only had to do the one command to get it back as it was. I appreciate your help in this matter and I expect others who read this will appreciate your help too. Leslie

  10. Andy Brown · 174 days ago

    To be clear then: Unregistering the vgx.dll will immunise the PC and any malware utilising this vulnerability will be unsuccessful? If true this seems like the quickest and least disruptive 'fix' until MS release the fix.

    • Paul Ducklin · 174 days ago

      That is the claim, or at least the strong suggestion, made by Microsoft in the article linked to above.

      As I wrote, "it sounds as though this vulnerability is somewhere in the VGX code." If it is, then I think you can expect to be as safe as you'd like to be after unregistering that DLL.

      As another commenter (@John Smith) has pointed out elsewhere, you may need to unregister/re-register both the 32-bit and 64-bit versions of the DLL, as suggested in his comment, if you are on 64-bit Windows.

      I have tried unregistering the DLL, and things seemed to work fine afterwards, but my tests can best be described as perfunctory, I'm afraid.

      Indeed, I don't have an exploit sample "from the wild" to test against, so I can't even say, "I tried the fix and it blocked an exploit that worked beforehand," only that "I tried the fix and nothing obviously bad happened to my browsing experience."

      Sadly, the best I can do is to say, "Microsoft implies you'll be OK if you do this. But your mileage may vary..."

      • John Smith · 173 days ago

        MS have now updated their advisory 2963983 to reference both DLLs for 64-bit systems.. unfortunately they have now got the re-register command lines wrong, still referencing "-u" ... how reassuring.

        • John Smith · 173 days ago

          Also, I did post a link to a test webpage - this was removed by the mods (understandable!) but there are plenty of examples out there if you seach for test vml - the one I was using was the w3 org link but I'm sure the others are fine too... I hope this gets patched properly soon - painful.

  11. Ian · 174 days ago

    Paul

    Thanks for this warning and proposed solution.

    Yesterday I unregistered the dll as suggested and then decided to uninstall IE as I don't normally use it anyway.

    Later that day I got an automatic Security Update from MS which I found strange as they supposedly don't support XP anymore.

    I looked at the "details" and the update included KB2510581, KB2909212, KB2936068 as well as an unsolicited install of IE 8 for XP

    I let it do its thing and have again unregistered the DLL.

    Strange days in XP world ?

  12. pickaname · 174 days ago

    Over the years, I've heared of this kinda crap at least a dozen times about someone taking over your system IF you go to some site and click here or there and do this and that..what's new about that? or this time, this is just some corporate/goverment scare tactics to make people upgrade from Windows XP? FU microsoft, the U.S. & U.K. governements...damn it since when governments has become your chief technical office.

    • Paul Ducklin · 174 days ago

      Sadly, nothing's new about the problem of being "owned" by simply browsing to a site. What's new here is the trick the attackers are using. There isn't a patch out yet. But there are some tweaks you can do to make your computer safe. If you hve XP, you'll never get a patch, so the tweaks are even more important.

      What's the problem with an article that points that out?

  13. Steven · 174 days ago

    "That means you can turn off what Microsoft calls Active Scripting in your browser (or set IE to prompt you before Active Scripts like Flash run), and increase your resilience against this latest attack."

    Be care about "set to prompt" you might be stuck in place until you bring up task manager to get unstuck, therefore disable is better.

    I never found a VGX DLL in my Computer I guess I am safe

    • Keeper99 · 172 days ago

      Not questioning your level of computer expertise but keep in mind many DLL files are system protected and simply showing hidden files in folder options does not make it visible in a search or browsing the folder. Even if you don't see it it would probably be a good idea to unregister it via the commands above just to err on the side of caution.

  14. Joshua · 173 days ago

    Will the Sophos Web Appliance block this threat?

    • Paul Ducklin · 172 days ago

      Yes...I added some detection details into the article itself, so you know what to look for in the logs :-)

  15. Andy Brown · 172 days ago

    I was expecting a patch by now...MS are obviously finding this one difficult to fix. In the meantime all my PCs here have had the vgx.dll unregistered.

  16. Simon · 172 days ago

    Just out of interest, are SophosLabs working on detection data for any of the potential exploits relating to this?

    • Paul Ducklin · 172 days ago

      Done, in fact - I'll be adding the detection names to the article in a short while.

      As far as I'm aware we had to go looking for samples, which is sort-of good news as it implies this thing isn't (yet, at any rate) widepsread. Watch this space...

  17. Andy Brown · 172 days ago

    Paul - Can you confirm if Sophos is detecting the known exploit - and if so what as? Thx

  18. Ronald Janssen · 172 days ago

    Sophos lists 2 currently known exploits:

    http://www.sophos.com/en-us/threat-center/threat-analyses/vulnerabilities/VET-000596.aspx

    ( Troj/SWFExp-CV and Exp/20141776-A )

    When you're using the Sophos UTM with IPS enabled, Snort should pick them up: http://blog.snort.org/2014/04/sourcefire-vrt-certified-snort-rules_28.html

  19. Ian · 166 days ago

    Hi Paul

    You say at the end of your post:

    "What if I have XP?

    Unregister the VGX.DLL file as shown above.

    Never re-register it."

    But now that we know that Microsoft extended their support and XP at the same time - perhaps this advice is no longer valid ?

    Can you tell us how to re-register VGX.DLL on XP now ? Please ?

    Thanks

    Ian

    • Ian · 166 days ago

      Edit: "extended their support and fixed this issue in XP at the same time"

  20. Stev · 114 days ago

    I'm not a computer geek, and my memory (brain type) is failing. I followed your instructions to deregister the VGX.DLL when this article appeared, but I don't know/remember what has transpired since then. I install Microsoft updates religiously, so has a patch been issued to fix the problem? If so, do I need to reregister the DLL or did the patch do it for me? How can I determine whether or not the DLL is or is not registered?
    Thanks, Steve

    • Paul Ducklin · 112 days ago

      We updated the article at 2014-05-01T21:2Z: "Microsoft has issued an out-of-band patch (meaning no need to wait until the next Patch Tuesday). Fixes are available for all versions of IE, from IE 6 to IE 11, on all versions of Windows, including XP." (Yes, they made a special exception for XP.)

      I am not sure if the patch re-registers the affected DLL, but if you have not had any problems (e.g. drawings that don't display properly) then...you may as well just leave things as they are. Plus the update, of course :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog