Google, Adobe barricade Flash against hacker hordes – we peek inside

Google's team of computer security gurus have described the anti-hacker defenses they've helped Adobe add to Flash Player.

It's hoped that these mechanisms will thwart or frustrate miscreants' attempts to exploit programming bugs in the software, and thus hopefully prevent attackers from hijacking victims' PCs and Macs. The defenses aren't perfect, but given the number of attacks on Flash and the fact that Adobe can't find every bug in its source code, they are a welcome development.

On Tuesday, Adobe told The Register that it was working on "mitigation techniques that prevent entire classes of vulnerabilities from being exploited," and that it was rushing to get these techniques into its troubled plugin.

Late on Thursday, Google's Project Zero team revealed that the latest version of Flash, 18.0.0.209 – which was released this week to patch vulnerabilities exploited by spyware maker Hacking Team – employs three mitigations developed by Google and Adobe.

The mitigations revolve around Vector.<uint> arrays in Adobe Flash's ActionScript: these are arrays of unsigned integers, and are stored in memory as a length value and the array data. The length value defines how many elements are in the array.

Many, many Flash exploits work by using bugs in Adobe's software to increase the length value of an array without reallocating it, effectively extending it to occupy a nearby object's memory. By reading and writing unsigned integer elements in the additional space, the attacker can access and alter memory in objects he or she is not allowed to normally touch.

These arrays sit in heap memory close to each other, so it becomes easy to manipulate the contents of other heap objects. Exploiting this to gain code execution is left as an exercise to the hacker.

So Google and Adobe have come up with three defenses:

• Vector.<uint> buffer heap partitioning: Arrays are separated from other heap objects, so attempts to overflow a buffer and alter a nearby vector's length is much more difficult – their addresses are now too far apart. Going the distance will trigger a page fault or blow away too much of the environment to continue running without crashing. And a crash is better than exploitation.
• Stronger randomization for the Flash heap: Attackers need to know the memory layout of Flash at the moment of exploitation. It's like building one of those marble run machines where everything has to be placed more or less precisely for the right values to slot into position. Randomizing heap allocations wrecks the chances of reliable exploitation.
• Vector.<*> length validation: Adobe has added an extra value to an array's metadata called a secret, which is calculated using the length. If an attacker changes an array's length, the array's secret must be recalculated, but if the attacker cannot generate the correct secret for the desired length, Flash will detect this and bail out before a vulnerability is exploited. So this helps stop miscreants overwriting a vector's length, which may kill most attacks dead.

"We believe we've contributed a strong step forward in Flash security, but we're very far from finished," said Mark Brand and Chris Evans, of Project Zero.

"For every mitigation landed by defenders, attackers will attempt to devise a counter-mitigation. It's a cat-and-mouse-game, but we'll be looking out for attackers' attempts to adapt, and devising further mitigations based on what we see. Perhaps more importantly, we're also devising a next level of defenses based on what we expect we might see.

"Our partitioning mitigation is far from finished. We’ll be analyzing object types to see what else might benefit from partitioning, and moving forward incrementally.

"On top of this, we're continuing to help lock down the various browser sandboxes, and working on compiler-based mitigations. As always, we'll fully share our work when we have something interesting to show."

Last year, Adobe's chief security officer Brad Arkin said he wanted to make life much harder for attackers who try to exploit programming cockups, rather than spend all day finding and fixing bad code hidden in millions of lines of source. ®