Sophos Cloud Optix
A remote code execution vulnerability against Internet Explorer was announced recently, and a proof-of-concept exploit has already been added to the Metasploit products.
Microsoft doesn’t have a patch out yet, but it has published a workaround which protects against this exploit, and others of a similar sort.
I urge you to familiarise yourself with the workaround, because it improves your general security posture as well as mitigating this particular problem.
The vulnerability was published earlier in the month on a full-disclosure security list. Full disclosure means that you simply tell the world about a newly-found bug, and let the world sort things out. The theory behind this is that it prevents sluggish software vendors from simply ignoring the problem and not fixing it. The disadvantage, of course, is that it alerts the Bad Guys at the same time as everyone else.
The vulnerability relies on a memory-usage bug when Internet Explorer processes a Cascading Style Sheet file. (CSS is the way you specify the look and feel of the HTML which makes up your web pages.) If the style sheet imports itself – something which would not normally be useful, since the CSS file is already loaded – then IE makes a mess of memory. This can be exploited to cause remotely-supplied code to be run without the usual security checks associated with IE downloads.
Sadly, this new exploit seems to work against all supported versions of Internet Explorer, right up to IE 8 on Windows 7, despite security improvements in Microsoft products such as Data Execution Prevention (DEP) and Address Space Layout Randomisation (ASLR).
DEP is designed to prevent you from sending data packets containing code and hoping you can run that code if you manage to crash the application which receives it. Areas of memory in which the application stores its run-time data – including the stack and the heap – are marked non-executable. So even if you do cram them full of malware and trick the computer into jumping to the offending code, the operating system will prevent it from running.
If, due to DEP, you can’t simply supply and run your own code, then your exploit needs to make use of code which is already loaded into memory and marked executable. That means you need to predict exactly where in memory it is going to be.
And ASLR is specifically intended to stop you from doing so. Loading programs and DLLs in a different, random location every time means that you can’t predict where in memory you will find useful stuff. So you to need to locate it first – but you can’t do that either, because the code you’d need to perform the search is blocked by DEP.
Unfortunately, Microsoft allows each DLL to decide whether it supports ASLR or not. And IE is implemented as a whole raft of DLLs – some of which are loaded at run-time, as needed, to render content which IE downloads. So, by sending otherwise-innocent files to IE, you can trick it into loading known DLLs. If any of those DLLs do not support ASLR, then they are loaded at a known place in memory.
Heigh, ho, Microsoft. There’s not much point in putting security guards on every door but leaving the windows open! And those unsafe DLLs mean exactly that – unsafe Windows.
Over time, we can expect to see Microsoft retire older DLLs which are unsafe, and to ensure that internet-facing applications run with full ASLR. That makes successful exploitation much harder, as explained above.
For now, a good workaround is to use Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). With this tool, you can force named applications to perform ASLR on every DLL they load, whether the DLL wants it or not.
This makes it very much less likely that a remote exploit based on hard-wired addresses will succeed.