Adobe Looks To Google To Help Them With Disaster
Any news lately regarding the Adobe Flash Player has been something of a fiasco. The security behind it has been an abject failure, leaving an unfathomable amount of data vulnerable. And with vulnerable data comes hackers exploiting it, which has inevitably been occurring. In an age where everything is kept online and must be as safe as possible, Adobe has started looking like an old dog that can’t learn a new trick. They couldn’t buy good press. So they’ve partnered up with Google, a company that not only always has good press, but has a whole section of their site that literally distributes press. Google’s computer security team went to work on the Flash Player to amp up security for the commonly used player, an alliance that could well keep the Adobe Flash Player alive.
Google Noticed Security Problems Adobe Could Not
In the past month, Adobe has had to make quite a number of patches to the Flash Player to prevent CVEs, aka Common Vulnerabilities and Exploitations. Specifically, that number is 38, three of which had been successfully exploited by Hacking Team, an Italian spyware maker with a bizarrely on-the-nose name. According to Adobe, Google discovered 20 of the 38 CVEs they’ve worked to patch up in the Flash Player. Instead of simply reporting these to the Adobe team, the Google team also worked with them to fix these issues and potentially prevent further attacks to the Flash Player.
Three Helpful Defenses Put Into Place
The key to helping protect the Flash Player was knowing what bugs in Adobe were used to exploit it. Ultimately, a lot of the exploitations of the Flash Player came down to extending the length value of an array without relocating it. Doing this allowed you to access memory that you previously couldn’t. Knowing this was a primary source of trouble, Google helped put some defenses in. One defense is known as buffer heap partitioning, which makes changing the length of an array almost impossible to do without crashing it. There’s also a better randomization of the Flash heap. This makes it much more difficult for a hacker to know the memory layout at the moment they intend to exploit it. Lastly, there’s length validation. This adds something to the metadata of an array called a secret. Changing the length of the array changes the secret, and if the hacker can’t find the correct secret for the new length, the Flash Player bails out.
