Sophos Cloud Optix
A critical Internet Explorer vulnerability, announced and patched by Microsoft in June’s Patch Tuesday, is being exploited in the wild.
The vulnerability is CVE-2012-1875 (don’t expect any detail – this link is just boilerplate stuff), patched in MS12-037.
SophosLabs has seen numerous attempts to exploit this vulnerability (Sophos products detect it as Exp/20121875-A).
Cunningly-crafted JavaScript code – which can be embedded in a web page to foist the exploit on unsuspecting vistors – is circulating freely on the internet.
Also, the Metasploit exploitation framework now has a plug-in module which will generate malicious JavaScript for you on-the-fly to help you automate an attack. (For authorised penetration testing and research purposes only, natch!)
The vulnerability carries the resounding name of “Same ID Property Remote Code Execution Vulnerability”, and is caused by memory mismanagement in Internet Explorer.
This is what is generally known as a use after free bug. This happens when a program returns a surplus block of memory to the operating system, so it can be allocated again later, but nevertheless carries on using it, by which time it may unexpectedly have been altered.
Two technologies in modern operating system distributions are used to make exploits of this sort harder: DEP (data execution prevention) and ASLR (address-space layout randomisation).
DEP allocates memory blocks so they can be used for data only, not for executable code, which reduces the surface area into which hackers can poke their malicious shellcode.
ASLR loads software modules such as DLLs into memory at randomised locations.
Moving system DLLs around makes it harder for hackers to guess where to find the library functions they need, such as URLDownloadToFile() and CreateProcess().
But DEP and ASLR don’t make remote code execution attacks impossible – just trickier.
In the case of Exp/20121875-A, ASLR can be bypassed by trying to force Internet Explorer to find and load an old version of the Microsoft C runtime DLL – one which was compiled before ASLR become the norm, and therefore doesn’t support it.
Whenever you load a non-ASLR DLL, even into an ASLR-enabled program, you can predict where it will end up. (According to the aforementioned Metasploit module, your Java Runtime could be a handy source of a suitably old-school DLL).
And DEP is bypassed using a technique known as ROP, or return-oriented programming.
ROP is tricky to explain in one sentence, but it relies on knowing where to find small fragments of code in already-loaded and already-executable memory – typically just one or two instructions at a time – which can be stitched together into a coherent and malicious, albeit curious and clumsy, whole.
You then execute these tiny instruction fragments (known as gadgets in the ROP community) by building a list of memory addresses which will be jumped to in sequence using the RETURN instruction – which is where the ‘R’ in ROP comes from.
(See how tricky it was to explain ROP in one sentence? Tricky enough that I used two.)
DEP prevents code from running in system-allocated memory, but it doesn’t prevent code from being jumped to via code pointers stored in execution-prevented memory. And with ASLR quashed, you can work out in advance where your ROP gadgets will be, and construct your list of code pointers accordingly.
So much for the hackers’ efforts.
Your response is easy: if you haven’t patched already, do so right away!
NB. This exploit is not the same as the one associated with news of “state-sponsored attackers” and Google. That’s CVE-2012-1889 – another exploit that SophosLabs has seen in the wild, and that we suggest you read up about!
–
I wanted to work for sophos but now I don’t, I’m not smart enough. That was a lot of jumbo jumbo.
Thanks!
What more were you expecting from one of Paul's posts? The man is a genius.
Don't do yourself down. Just because you don't know or understand something doesn't, in itself, say anything about how smart you are 🙂 Knowing – or, more accurately, admitting – that you don't know something is actually a very smart move – how else will you learn, or even decide what to learn?
IIRC this is an Albert Einstein quote: "When you reach 20 years of experience in a job, make sure you have 20 years of experience, not one year of experience 20 times."
That's especially relevant in computer security, where new experiences await you all the time as the crooks figure out new ways to make money out of nothing…
Very good read thank you paul as usual
I think that was a good, concise explanation of how this type of exploit vulnerability does
work in computers. Thanks for the info!
This language was far too techie for any average person to understand. And if there is a threat, where do we get this "patch?"
He gave links at the top, including one to the patch – MS12-037.
It's hard to explain technical stuff in a few words without making some technical assumptions.
One problem we face is that the terms DEP and ASLR are frequently used, without explanation, in non-techie or low-tech explanations, where they seem to have acquired "meaning without meaning", if you get my drift. (A bit like the tendency at trendy food takeaway joints to put signs on awash-in-fat items like ham-cheese-and-butter croissants saying, "Only 1450 kilojoules!" Or when pubs or restaurants trot out the "Under new management!" sign. These may be true statements – though how will we ever know? – but out of context, they are data, not information.)
So I was trying to add some information by suggesting why we have DEP and ASLR, in a few hundred words 🙂 Hmmm. Methinks I feel a video coming on…
As for the patch – see the MS12-037 link in the second paragraph. That covers the what, where and how of the patch itself:
https://technet.microsoft.com/en-us/security/bull…
If you run Windows Update (with or without the Microsoft Update part) and have let it update, you already have the patch. If you don't you should.
If your IT department controls patching on your machine, it's up to them (and Microsoft essentially PLEADED with them to patch this one quickly).
Moderator: my comment about Windows Update was intended to be to Robert W's post not Connie's. Sorry.
This sort of thing is why I run IE (9 or 10)–and other browsers–with JavaScript disabled until I know it's needed for a particular site. And then think about whether the site is worth having JavaScript enabled.
Does using a standard user account and EMET mitigate this? Would the use of Chrome browser mitigate the risk?
Are you seeing the javascript on legit pages (through ad syndication perhaps?) or is it pretty much confined to phishing people toward rogue sites that then use the drive-by?____Jeff