Another “Hacking Team” zero-day surfaces – this time in IE, not Flash!

Thanks to threat-buster Andrew O’Donnell of SophosLabs for his work on this and, indeed, many other vulnerabilities.

Yet another zero-day has been dragged out of the data dump from hacked Italian security outfit Hacking Team.

This time, Adobe can breathe a sigh of relief, and so can Flash users and programmers everywhere.

This vulnerability is down to a bug in Internet Explorer 11, and looks as though it’s perfectly viable as a vehicle for Remote Code Execution (RCE) on both Windows 7 and Windows 8.1.

Generally speaking, RCEs are the most dangerous exploits, especially against a browser, because they can be used for drive-by downloads.

That’s where merely looking at a web page – even if you don’t click any buttons, download any files, fill in any forms or see any “Are you sure” popups – could infect your computer with malware.

RCE explained

An RCE against your browser usually means that a crook can trick the browser into jumping past all the protection to do with untrusted content or risky behaviour, and tell it to download a file anyway, and to run it.

You can think of it like this:

• Remote: Data that could have come from anywhere and probably did…
• Code: …that surreptitiously turns out to be a sequence of commands or program instructions…
• Execution: …and gets to run when it shouldn’t, without so much as a “by your leave.”

Typically, you won’t even notice that anything unusual happened, because the RCE happens invisibly.

Your browser might freeze up or crash, but many exploits manage to sidestep that tell-tale sign, too.

Internet Explorer at risk

According to security researchers at Vectra Networks, this latest vulnerability in Internet Explorer was patched in amongst Microsoft’s latest Update Tuesday fixes, which came out on 14 July 2015.

Vectra took a proof-of-concept (PoC) demonstration of the vulnerability found in the Hacking Team dump, and put it through the wringer.

The PoC was apparently part of a would-you-like-to-buy-my-exploit email sent to Hacking Team, so it showed only enough of the hole to get a prospective buyer interested.

Exploit-sellers generally don’t start off by giving away details of how to exploit the hole and pull off an actual RCE attack. (There’s only so much honour among exploit traders, it seems.)

Vectra got pretty far just from the PoC, concluding that the bug was a so-called use-after-free vulnerability in the JavaScript JIT compiler.

Just in time

That needs a spot of explanation: JIT stands for just-in-time, and it’s a speedup trick used by browsers on script files such as JavaScript programs.

JavaScript arrives in your browser as source code, meaning that it can run on any operating system and in any browser, and doesn’t have direct access to the operating system layer, which gives it both flexibility and safety.

But running JavaScript by processing the code over and over as you go along – what’s known as interpreting it – can be slow.

So, JIT compilers convert frequently-used parts of JavaScript programs into snippets of regular machine code, just like you’d get in .EXE files, so they can run natively under the operating system itself, at full speed.

Typically, the JITter doesn’t generated full-blown .EXEs or .DLLs and load them back in, but simply stuffs compiled code fragments into a carefully managed memory buffer from which they can execute.

You can see where this is going: if those “carefully managed” memory buffers aren’t so well-managed after all, you’re in real trouble, because a crook who could overflow or overwrite the buffer could just stick his own code in there instead.

Of coure, Data Execution Prevention (DEP) is supposed to stop buffer overflow and overwrite exploits by keeping a program’s code and data in separately-labelled compartments.

But the output produced by a JIT compiler is code as well as data, so its buffers need to be execute-enabled, leaving them unprotected by DEP.

Quickly patched

Anyway, this exploit only showed up in the past week (Vectra, for example, reported its findings to Microsoft on 09 July 2015), but Microsoft managed to get the patch out within a few days.

If so, that’s an excellent turnaround – let’s hope it’s a foretaste of the sort of speed we can expect as a matter of routine once Windows 10 is released.

Windows 10 is set to use a rolling release model, rather like many Linux distributions, where updates come out steadily, instead of once a month.

Even though a monthly update cycle doesn’t preclude emergency updates on in-between dates, it can lead to important updates being made to wait up to 30 days until the next due date comes around.

After all, if you need to have a procedure for taking care of “out of band” emergency updates anyway, why not use it for all updates?

Then you can get rid of your second procedure for monthly patch-batches – a procedure that is probably more complex and error-prone, anyway.

What to do?

The bottom line here is that, whatever update process you have, MS15-065 is one to apply right away.

The cat is out of the bag, and if recent events are anything to go by, we should assume we’ll see general access to this exploit being made available by cybercriminals very soon.

As soon as they figure out how to bundle a working version of this attack into their exploit kits, which are pay-as-you-go tools you can rent to spread your malware far and wide…

…they will.

NB. Sophos products detect and block exploits based on this PoC as Troj/JSExp-Q, if you wish to keep an eye on your logs.