Adobe pushes out critical Flash update – the second zero
Just to clarify the jargon above:
- RCE means “remote code execution”, and it refers to an attack that runs a program on your computer without producing pop-ups, dialogs or warnings. Just by visiting a web page, viewing a document, listening to an audio file, or similar, you might invisibly get infected with malware. Your browser, or word processor, or whatever it is, might crash in the process, but that’s an unreliable indicator that you have just been attacked. (Also, it’s usually too late by then: it is by crashing your browser that the attackers jump over the security warnings.)
- Usually, when triggering an RCE, the attackers will deliver a booby-trapped file. This is deliberately crafted so that when it is processed on your computer, for example by the Flash plugin in your browser, the program is led astray so that unauthorised and unexpected execution of remotely-supplied code takes place. The bug that permits the program to be led astray is called a vulnerability; the trick that makes use of the vulnerablity is called an exploit.
- In the wild means simply that a real-world attack is known, so this is not merely a risk that has been spotted and contained inside a security lab. If an in-the-wild attack happens before a patch is ready, it is known as a zero-day, meaning that you had zero days of advance warning about a patch, because there wasn’t one.
According to Adobe, there are three vulnerabilties patched in this update, numbered CVE-2014-0498, CVE-2014-0499 and CVE-2014-0502.
The last on the list is the one known to have been exploited in the wild, according to analysts at vulnerability research company FireEye, and it’s the reason why you should updgrade promptly.
Presumably, the other two vulnerabilities have been patched “just in case,” because Adobe’s next scheduled security update doesn’t arrive until April 2014.
The importance of patching
Note, however, that properly updated systems should be immune to this in-the-wild attack.
According to FireEye, the attack relies on overwriting function pointers (for programmers: this exploit overwrites a vtable, which is short for virtual function pointer table) inside Flash.
A function pointer is a memory location that keeps track of where a program should go to perform certain functions such as reading and writing files, or compressing and decompressing data.
Clearly, by changing a function pointer, typically only four bytes on 32-bit systems or eight bytes on 64-bit systems, you can completely change the behaviour of a program, which is why function pointers aren’t supposed to be rewritable by just anybody.
But for the attack found by FireEye to work, you have to know where to send the exploited program to next (i.e. what value to write into the “stolen” function pointer).
That’s something you can’t easily predict on a system that is using Address Space Layout Randomisation, or ASLR.
ASLR is a powerful threat mitigation technique used in all modern operating systems, and most modern software, so that attackers can’t guess where specific system components will end up in memory, making it much harder to take control of buggy software from a distance.
→ When you come home in the dark, you know exactly where the light switch is in the hallway, so you can open the door, reach round in the pitch black, and turn on the lights at once. But in a stranger’s house, you’ll probably end up fumbling around for ages, helplessly swiping at blank parts of the wall, probably knocking over an ornament or two in the process and drawing attention to yourself.
So, the in-the-wild CVE-2014-0502 exploit found by FireEye deliberately targets insecure environments where ASLR is turned off, namely:
- Windows XP. (We told you to upgrade!)
- Windows 7 with Java 6. (The Java 6 plugin allows ASLR to be bypassed. Java 7 does not, and is therefore immune.)
- Windows 7 with an unpatched Office 2007 or 2010. (Those versions of Office were patched in October 2013 to enforce ASLR.)
What to do?
- Get rid of XP from your regular office computers – especially ones used for browsing and running Microsoft Office – and lock down those on which you simply can’t find a way forward. (XP doen’t support ASLR. This makes it much less secure at heart than later Windows versions.)
- Update to Java 7, and turn off Java in your browser unless you are absolutely certain you need it.
- Don’t let more than three months go by before you apply Microsoft security patches.
- Consider whether you still need Flash, because many websites no longer require it thanks to HTML5, and then either uninstall it or apply this patch promptly.
Remember that many so-called Advanced Persistent Threats, or APTs, are only advanced if you are behind in your patching – so don’t make things easier than you have to for the crooks!
Oh, and here’s a suggestion for Adobe.
Having lined up with Microsoft for your patch regularity (i.e. always on the second Tuesday of a month), why not line up with Redmond in frequency (i.e. patch every month, not every quarter)?
Well-informed system administrators are increasingly willing to apply patches immediately, rather than waiting three months, so why make them wait three months for routine updates?
For further information
You might also like:
- Our Techknow podcast Understanding Vulnerabilities, which explains RCE and other vulnerability jargon.
- Our Techknow podcast on Patching: should you lead, follow, or get out of the way?
- Our Techknow podcast The End of XP, advising you on how to deal with the end of security updates for XP after April 2014.
- Our detailed study Anatomy of an exploit – inside the CVE-2013-3893 Internet Explorer zero-day, which incidentally uses the same Office 2007/2010 vulnerability to bypass ASLR.
To listen to the above podcasts directly:
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/geFDGSBkfas/