Flash zero-day prompts emergency update from Adobe

Just two days after this month’s Adobe Patch Tuesday, the company published an emergency fix for Flash.

Dubbed APSB16-08, the update didn’t make it out on Tuesday, but it fixes 23 CVE-labelled vulnerabilities, so make sure you don’t miss it if your processes are still geared towards a calendarisable cycle of updates.

The bugs fixed in this release include holes that “could potentially allow an attacker to take control of the affected system.”

In fact, one of the vulnerabilites, denoted CVE-2016-1010, is “being used in limited, targeted attacks,” according to Adobe, and therefore qualifies as more than just a potentially exploitable hole.

We’d love to be able to tell you what sort of cyberattacks were being launched using this new exploit, and how much damage they were able to do, but we aren’t yet sure because no one’s saying.

This sort of “silent period” might seem both frustrating and dangerous – if you think that knowledge is power – but according to Ars Technica, the attacks were spotted by Kaspersky Lab and are being kept quiet for now because they have been reported to law enforcement.

Presuambly, saying too much, too soon, might jeopardise some parts of the investigation.

💡 LEARN MORE: Visit the SophosLabs vulnerability assessment page ►

Vulnerability versus exploit

There’s often a big gap to cross to go from a vulnerability, even one by which you can reliably crash an application, to an exploit, especially a Remote Code Execution exploit (RCE).

An RCE is where you crash an application in such a well-orchestrated fashion that instead of simply being killed off by the operating system, the offending process actually turns control over to you.

Modern-day protections such as DEP (data execution prevention) and ASLR (address space layout randomisation) make remote code execution tricks much harder to figure out.

DEP helps the operating system to treat data (e.g. the untrusted stuff you receive across the network, such as in a web request) differently to code (e.g. the program running locally that processes untrusted data).

In other words, even if you deliberately package up some devious program code inside the data you’re sending from outside, it ought never to be able to run, because the operating system stores it in memory that is flagged as No Execute (NX), also known as Execute Disable (XD).

Of course, DEP doesn’t stop you from deliberately crashing an app so that it tries to run code that is already loaded, such as a handy subroutine that just happens to exist in the program that you are able to crash.

ASLR helps prevent tricks like that by loading programs and their associated system libraries into different locations in memory each time they run.

That way, crooks who try to transfer control, say, to the LoadLibrary() function in the browser’s memory space, will have to guess where their needed code is going to be.

If they guess wrongly, as they almost certainly will if ASLR is in use, then the application will almost certainly crash in an uncontrolled way.

The operating system will then step in, kill the offending process, and avoid an remote code execution.

What to do?

  • Patch Flash now if you have it installed, or check that your auto-update has run if you are set up for that.
  • Configure Flash in your browser so it asks you first before running.

Better yet, consider uninstalling Flash altogether, at least for a while, and see if you can live without it.

After all, Apple iPhone users have lived without Flash since the iPhone first came out, and you don’t hear them clamouring for Flash support!