Critical Internet Explorer exploit code released in the wild

Attack code that exploits a critical vulnerability in all supported versions of Microsoft's Internet Explorer browser has been publicly released.

Monday's release of a module for the Metasploit exploit framework used by security professionals and hackers could broaden the base of attackers who are capable of targeting the flaw. Until now, the bug has been known to be exploited in only a handful of highly targeted attacks aimed mostly at workers in Japanese government agencies and manufacturers. While the attack code has been available to anyone who knows where to find it, its inclusion in the open-source Metasploit could make it easier for some people to use.

Microsoft issued a temporary fix for the browser two weeks ago. The company, which is scheduled to release its next batch of security updates on October 8, hasn't said when it will issue a permanent patch.

One of the groups carrying out the attacks is the same one that installed malware on computers belonging to security firm Bit9. The group has planted exploits on compromised websites known to be frequented by government and manufacturing employees. The exploits are used to remotely execute code that installs rootkit-style malware that's used to download sensitive data from the infected machines. While the exploits target versions 8 and 9 of IE running on Windows XP and Windows 7 respectively, the "use after free" vulnerability is present in IE versions 10 and 11 as well, Microsoft has said.

Out of an abundance of caution, Windows users should be sure to install the temporary fix regardless of the browser they regularly use.

The exploit was attacking a Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) and was implemented entirely in Javascript (no dependencies on Java, Flash etc), but did depend on a Microsoft Office DLL which was not compiled with ASLR (Address Space Layout Randomization) enabled. This DLL (hxds.dll) is loaded into IE by the HTML href attribute shown below:

try { location.href = 'ms-help://' } catch (e) { }

Does this mean only machines with MS Office installed are vulnerable?

If so, just recompile hxds.dll with mandatory ASLR and push it out as an Office hotfix. Then push out a Windows hotfix that just runs an update check for Office. (Admins would be able to handle this more gracefully, but my solution would work for any home users out there.)

Out of an abundance of caution, Windows users should be sure to install the temporary fix it regardless of the browser they regularly use.

Say what?

Is there any evidence that this exploit works in FF or Chrome?

I think the author meant even people who only seldomly use IE should also install the temporary fix, My take is that it is possible some program uses IE as the rendering engine of their built in browser.

Thanks for your comments. I'm a UNIX guy (mostly Solaris, legacy TRU64 and Linux), so I don't spend a lot of time in the Wintel realm except for work. I stand corrected.

This was the case even on UNIX systems for quite a while, as there were many plugins -- Flash, Java, etc. -- that were only available in 32-bit versions, even after the default OS install on many systems was x86_64. This problem still persists on Windows today as there were/are exponentially more browser plugins there.

Thanks for your comments. I'm a UNIX guy (mostly Solaris, legacy TRU64 and Linux), so I don't spend a lot of time in the Wintel realm except for work. I stand corrected.

This was the case even on UNIX systems for quite a while, as there were many plugins -- Flash, Java, etc. -- that were only available in 32-bit versions, even after the default OS install on many systems was x86_64. This problem still persists on Windows today as there were/are exponentially more browser plugins there.

So how does the exploit work in that arena? If UNIX admins typically use lynx, elinks or Firefox in CDE or gnome, what is the risk? I don't know anyone in my profession that use IE in that environment.

So how does the exploit work in that arena? If UNIX admins typically use lynx, elinks or Firefox in CDE or gnome, what is the risk? I don't know anyone in my profession that use IE in that environment.

It doesn't, I was just trying to expound on why a bug that affects only 32-bit IE is affecting 64-bit Windows instances.

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

Well, using something other than IE might be a solution, like Duh!

So which other browser do you suggest, bearing in mind that it needs to be updatable behind the scenes on machines where the users do not have admin rights and without using an expensive solution like Altiris or SCCM (for small companies who don't have that kind of cash).

I'm no fan of IE and run other browsers on my own machines, but for small to medium sized businesses IE with updates managed by WSUS is the only practical option that I can see.

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

The FixIT is an MSI. It is/was quite easy to deploy via SCCM/Altiris. It's silent, IE can be running, it throws correct MSI exit codes, and everything is lovely.

I won't deny we need a patch for it, but the FixIt, frankly, was stupid simple to deploy.

The FixIt is risky and difficult to back out of safely hence why we won't implement. Also worth noting we have enough protection behind the browser to take the hit and continue with service as usual, I think we'll wait for the patch.

The Fix it solution that is described in this section applies only 32-bit versions of Internet Explorer.

On 64-bit machines, IE still runs 32-bit by default. You can switch it to 64 bit but you'll lose all plugins (which is why 32-bit is default).

It's just like how Chrome and Firefox builds for Windows default to 32-bit as well despite running on a 64-bit machine.

They've changed that with IE10 and Windows 8. If your machine is 64-bit, it runs the 64-bit version of IE by default. The reason it ran the 32-bit by default with IE9 and Windows 7 was because the JIT compiler was only usable under the 32-bit build. That is no longer the case.

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

Well, using something other than IE might be a solution, like Duh!

So which other browser do you suggest, bearing in mind that it needs to be updatable behind the scenes on machines where the users do not have admin rights and without using an expensive solution like Altiris or SCCM (for small companies who don't have that kind of cash).

I'm no fan of IE and run other browsers on my own machines, but for small to medium sized businesses IE with updates managed by WSUS is the only practical option that I can see.

You are actually capable of installing Firefox and having it update - all without admin rights. You still can't control it by Group Policy so I'm not saying I recommend it; just that it can be done.

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

The FixIT is an MSI. It is/was quite easy to deploy via SCCM/Altiris. It's silent, IE can be running, it throws correct MSI exit codes, and everything is lovely.

I won't deny we need a patch for it, but the FixIt, frankly, was stupid simple to deploy.

The FixIt is risky and difficult to back out of safely hence why we won't implement. Also worth noting we have enough protection behind the browser to take the hit and continue with service as usual, I think we'll wait for the patch.

I guess I don't view it any more difficult to back out than ANY Microsoft patch, really. And honestly, from a "removing a patch" perspective, the FixIt is actually easier, IMHO: They already have a pre-packaged FixIT "remover", that can be packaged and re-deployed just like the initial FixIT was.

I'll agree that deploying FixITs Enterprise wide is ugly, awkward, and not a good long term solution (and nor does it cover any of the other browsers; only IE8 x32), but it's "something".

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

Well, using something other than IE might be a solution, like Duh!

So which other browser do you suggest, bearing in mind that it needs to be updatable behind the scenes on machines where the users do not have admin rights and without using an expensive solution like Altiris or SCCM (for small companies who don't have that kind of cash).

I'm no fan of IE and run other browsers on my own machines, but for small to medium sized businesses IE with updates managed by WSUS is the only practical option that I can see.

You are actually capable of installing Firefox and having it update - all without admin rights. You still can't control it by Group Policy so I'm not saying I recommend it; just that it can be done.

There are GPO-controllable Firefox and Chromes out there; we have Google Chrome deployed in our Enterprise to a subset of users who desired it, while still maintaining control. It obviously took leg-work on our end to make it work, but if the options were:

1) People are going to find a way to run itor2) Deploy it and control it

we choose option 2.

The GPO-controllable Firefox, last time I looked, were all ugly kludges that should burn in a fire, and had no "official" support. Chrome at least pretends to.

Thanks for your comments. I'm a UNIX guy (mostly Solaris, legacy TRU64 and Linux), so I don't spend a lot of time in the Wintel realm except for work. I stand corrected.

This was the case even on UNIX systems for quite a while, as there were many plugins -- Flash, Java, etc. -- that were only available in 32-bit versions, even after the default OS install on many systems was x86_64. This problem still persists on Windows today as there were/are exponentially more browser plugins there.

Its the same problem that Office and Visual Studio faces.

Both of these programs have or could be 64-bit processes but the decades of extensions that add additional features do not.

iCloud for instance ( came to mind because it cannot add intergrate with Outlook if both Office 2010 and Office 2013 are installed ) wouldn't be supported in a 64-bit installation of Outlook.

The good news is the world is slowly changing and supplying both x86 and x64 assemblies with their products. The whole problem is that the 3 decades of legacy support code has to be updated to support both. The same problem exists on Linux just research the problems people are having with some of the assemblies on cryptocurrent miners but thats more of a ARM x86-x64 support problem.

So how do I deploy a Fixit to 1000 desktops? Who's going to stay late tonight manually changing 1000 desktops? (No we can't ask users to do it themselves. They don't care.)

Never mind. It's a rhetorical question if you haven't figured it out. We need a hotfix to push out to all the workstations asap.

Well, using something other than IE might be a solution, like Duh!

So which other browser do you suggest, bearing in mind that it needs to be updatable behind the scenes on machines where the users do not have admin rights and without using an expensive solution like Altiris or SCCM (for small companies who don't have that kind of cash).

I'm no fan of IE and run other browsers on my own machines, but for small to medium sized businesses IE with updates managed by WSUS is the only practical option that I can see.

You are actually capable of installing Firefox and having it update - all without admin rights. You still can't control it by Group Policy so I'm not saying I recommend it; just that it can be done.

There are GPO-controllable Firefox and Chromes out there; we have Google Chrome deployed in our Enterprise to a subset of users who desired it, while still maintaining control. It obviously took leg-work on our end to make it work, but if the options were:

1) People are going to find a way to run itor2) Deploy it and control it

we choose option 2.

The GPO-controllable Firefox, last time I looked, were all ugly kludges that should burn in a fire, and had no "official" support. Chrome at least pretends to.

For us there is no real option 1 - people cannot install it even with the non-admin install option and even if they did somehow sneak past those restrictions the auditing software would pick it up straight away.

Also, because of the way that we control internet access, the automatic update does not work - it cannot connect to Google. Though tbh, I would want to control updates anyway, as we do with WSUS, by trying out on a test group before rolling out to the whole company later. Automatic updates I have no control over make me nervous - I've been burned by some before (like the Sophos one a year or so back).

That leaves updating by msi via Group Policy - something that is unreliable at the best of times as I've found trying to do Flash and Java updates this way. Not to mention how many times Chrome updates.

The exploit was attacking a Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) and was implemented entirely in Javascript (no dependencies on Java, Flash etc), but did depend on a Microsoft Office DLL which was not compiled with ASLR (Address Space Layout Randomization) enabled. This DLL (hxds.dll) is loaded into IE by the HTML href attribute shown below:

Those instructions are to force enable ASLR on all processes. By default, the most you can set system-wide ASLR to is "Opt-in" if IIRC. You should just be able to add the IE executable to the app list in EMET 4.0 and make sure Mandatory ASLR is enabled for that specific application without having to go through the trouble of enabling Mandatory system-wide ASLR via the Registry key.

Edit: Actually, upon closer inspection, it looks to just enable the Mandatory ASLR for all IE-related processes and not system-wide. Mea culpa.

The exploit was attacking a Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) and was implemented entirely in Javascript (no dependencies on Java, Flash etc), but did depend on a Microsoft Office DLL which was not compiled with ASLR (Address Space Layout Randomization) enabled. This DLL (hxds.dll) is loaded into IE by the HTML href attribute shown below:

try { location.href = 'ms-help://' } catch (e) { }

Does this mean only machines with MS Office installed are vulnerable?

If so, just recompile hxds.dll with mandatory ASLR and push it out as an Office hotfix. Then push out a Windows hotfix that just runs an update check for Office. (Admins would be able to handle this more gracefully, but my solution would work for any home users out there.)