X
Business

Adobe admits to 80 'code changes' in Flash Player patch

Adobe explains why it decided not to publicly document about "80 code changes" that were made to fix security vulnerabilities found and reported by Google's security team.
Written by Ryan Naraine, Contributor

Adobe is fessing up to fixing much, much more than the 13 documented vulnerabilities in the latest critical Flash Player update.

Following an accusation from Google security researcher Tavis Ormandy that the company buried the fact that it patched a whopping 400 Flash Player vulnerabilities, Adobe security chief Brad Arkin (right) admitted the patch "contains about 80 code changes" for fix flaws identified by Ormandy's team.

Did Adobe hide 400 vulnerability fixes in latest Flash Player patch? ]

Arkin explains:

We didn’t allocate any CVEs because we viewed this testing as part of the SPLC that spans the joint engineering efforts with the Google Chrome team. This led to some confusion since the Google security team has a different approach to CVE allocation.

The initial run of the ongoing effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following the initial triage. As these bugs were resolved, many were identified as duplicates that weren’t caught during the initial triage. In the final analysis, the Flash Player update we shipped earlier this week contains about 80 code changes to fix these bugs.

Adobe has since updated the security advisory to document "multiple memory corruption vulnerabilities" that were reported by Tavis Ormandy and the Google Security Team.

Ormandy, a high-profile researcher who has a history of controversial vulnerability disclosures, originally claimed his team sent 400 unique Flash Player vulnerabilities to Adobe as part of an ongoing security audit but there’s no documentation on these fixes in the new update.

“Apparently that number was embarrassingly high, and they’re trying to bury the results, so I’ll publish my own advisory later today,” Ormandy said on his Twitter feed after he realized Adobe did not document any of those fixes.

On the Google security blog, Ormandy and his team explained that the flaws were found during a massive fuzz testing routine.

Turns out we have a large index of the web, so we cranked through 20 terabytes of SWF file downloads followed by 1 week of run time on 2,000 CPU cores to calculate the minimal set of about 20,000 files. Finally, those same 2,000 cores plus 3 more weeks of runtime were put to good work mutating the files in the minimal set (bitflipping, etc.) and generating crash cases. These crash cases included an interesting range of vulnerability categories, including buffer overflows, integer overflows, use-after-frees and object type confusions.

The Google security team said the initial run of the audit resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following Adobe's initial triage.

As these bugs were resolved, many were identified as duplicates that weren't caught during the initial triage. A unique crash signature does not always indicate a unique bug. Since Adobe has access to symbols and sources, they were able to group similar crashes to perform root cause analysis reducing the actual number of changes to the code. No analysis was performed to determine how many of the identified crashes were actually exploitable. However, each crash was treated as though it were potentially exploitable and addressed by Adobe. In the final analysis, the Flash Player update Adobe shipped earlier this week contained about 80 code changes to fix these bugs.

Editorial standards