X
Tech

Time's up: Google releases attack code for serious Adobe Reader bug

Google's Project Zero bug hunters have published details of a critical vulnerability in Adobe Reader for Windows that was patched in September.
Written by Liam Tung, Contributing Writer

Windows users who haven't updated to the latest version of Acrobat and Adobe Reader probably should do so right now, after a Google security researcher revealed details of a vulnerability affecting the pair, and how to exploit it.

As Adobe noted in its September security update for Acrobat and Reader on Windows, version 11.0.8 of the two programmes was vulnerable to a sandbox bypass that could allow an attacker to run native code with escalated privileges on Windows. US-CERT gave it a severity rating of 10.

The bug was discovered by James Forshaw, a security researcher in Google's Project Zero initiative. Forshaw has now released further details of the flaw, making it more important for Windows users to update to version 11.0.9 of Acrobat and Reader, since attackers can use the information to devise an attack for the vulnerability. Details released this week include a proof of concept exploit, source code, and pre-compiled binaries.

Project Zero is part of Google's effort to clean up widely-used third-party software with the aim of reducing the number of people potentially harmed by zero-day attacks. The program is separate to its own bug bounty program for researchers who report flaws in Google software.

Flaws discovered by the Project Zero team are housed in an external database and are kept under wraps until the vendor of the affected product issues a patch for it, or 90 days after it was reported to the vendor. In this case, Adobe has released a fix and the 90 days were up on November 26.

According to Forshaw, the sandbox escape in version 11.0.8 was possible due to a "race condition in the handling of the MoveFileEx call hook". 

"While the function resolves the location of the source and destination and ensures they are within the policy, there is a timing race once the function calls into the MoveFileEx function in the broker. This race can be won by the sandboxed process by using an OPLOCK to wait for the point where the MoveFileEx function opens the original file for the move. This allows code in the sandbox to write an arbitrary file to the file system," Forshaw wrote.

He noted that technically version 11.0.9 doesn't fix the race condition, however the update did make it "difficult if not impossible to exploit" due to additional defences Adobe made available in the update.

According to Forshaw, the update made it "no longer possible to use the broker file system hooks to create directory junctions".

Read more on security

Editorial standards