Yet another zero-day has been dragged out of the data dump from hacked Italian security outfit Hacking Team.
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.
An RCE against your browser usually means that a crook can trick your 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: …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
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.)
Just in time
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.
Anyway, this exploit only showed up in the past week (Vectra only reported its findings to Microsoft on 09 July 2015), but Microsoft managed to get the patch out with 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 Window 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 “out of band” emergency updates anyway, why not use it for all updates?
Then you can 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-0654 is one to apply right away.
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…
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.