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.

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

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