(Collaborative post by Mateusz “j00ru” Jurczyk and Gynvael Coldwind)
Several months ago, we started an internal Google Security Team effort to improve the general security posture of the Chrome embedded PDF reader, in an approach similar to the Flash fuzzing performed several months ago by Tavis Ormandy. During the course of a few weeks, we built a solid corpus of PDF documents that we feel gets significant coverage of the Chrome PDF Reader’s code base and used it to shake out more than 50 low-to-high severity bugs. All of the high and critical severity bugs we discovered have been fixed in the stable channel [1, 2, 3] as of this posting; see examples:
   High CVE-2012-2851: Integer overflows in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.
 High CVE-2012-2855: Use-after-free in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.
  High CVE-2012-2856: Out-of-bounds writes in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.
   High CVE-2012-2862: Use-after-free in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.
  High CVE-2012-2863: Out-of-bounds writes in PDF viewer. Credit to Mateusz Jurczyk of Google Security Team, with contributions by Gynvael Coldwind of Google Security Team.
Given the success of our corpus against Chrome’s PDF Reader, we decided to use it to test another widely-used PDF viewing application – Adobe Reader 9.5.1 for GNU/Linux (latest version available for the platform). Over 1,500 cores have been continuously feeding the application with malformed data for a few weeks, which ultimately resulted in a total of 46 reproducible crashes with unique stack traces. This initial batch of files was sent directly to Adobe on 21st of June. A few days later, we came up with a slightly different mutation method with the potential of exposing additional software vulnerabilities and re-ran the fuzzer. As a direct outcome, 14 new unique crashes were identified and sent to Adobe for further evaluation on the 27th of June. In addition to sending information to the vendor, we also performed a cursory investigation of the crash logs and determined that 31 (roughly 50%) seemed to represent trivially exploitable problems, which we assess as critical bugs, and 9 test-cases as potentially exploitable for remote code execution.
Since our original disclosure, we have been in regular contact with the Adobe PSIRT team. They were immediately responsive to our report and have provided us with regular updates about their progress addressing these bugs and update plans. We appreciate the progress they’ve made on the multiple crashes reported.
Today, on 14th of August 2012, Adobe has released a new version of Reader for Windows and Mac OS X platforms, addressing around 25 of the reported critical crashes, see the APSB12-16 security bulletin. The issues were assigned twelve CVE’s in total (CVE-2012-4149 through CVE-2012-4160), indicating how many unique code changes it took to fix the problems. Fixing those and numerous other lower-severity bugs not mentioned here in less than two months is a great step forward in raising the bar for bug hunters and improving users’ safety worldwide.
Unfortunately, sixteen more crashes affecting Windows, OS X, or both systems remain unpatched. Considering that fixing the first twenty four crashes took twelve unique code fixes, it is expected that the remaining crashes might represent around eight more unique problems. Adobe plans to fix these remaining bugs and issue an update for the Linux version of Reader in an upcoming release. Though we have no evidence these bugs are being exploited today, we are concerned that functional exploits can be built without much effort based on knowledge derived from binary diffing of the old and newly patched Windows builds.
Given this, we consider users of Adobe Reader to be exposed to serious risk. Using our thoughts on reasonable disclosure as a guide, we notified Adobe of our plans to publicly disclose information about any critical vulnerabilities which would remain unfixed 60 days beyond our initial contact. (Note: Adobe has confirmed they have no plans to issue additional out of band updates before August 27, which is 60 days after we disclosed all bugs. Since the Linux Reader version remains unpatched and the Windows / OS X patches are now available for diffing and reverse engineering, we have decided that it’s in the best interest of users to be aware of these security issues without additional delay.)
It is important to note that all discussed vulnerabilities were found using publicly available PDF documents, altered using conceptually trivial mutation algorithms such as bitflipping. Given that, we believe it is very possible that third-parties specializing in bug hunting and vulnerability research may already know of and/or be targeting many of our reported issues.
We plan to continue working with Adobe to verify additional fixes and test new releases to further improve the security of Reader.
Adobe Reader for Linux users are exposed to all critical vulnerabilities discussed here, until the patched Linux version is released.
Adobe Reader for Windows are currently vulnerable to up to 6 unpatched issues.
Adobe Reader for Mac OS X are currently vulnerable to up to 10 unpatched issues.
We have decided to publish the stack traces of all sixteen crashes affecting Windows and OS X, with the intention of demonstrating the existence and severity of the issues. The call stacks are, however, obfuscated in such a way that the 20 least-significant address bits are masked out together with function symbols and any other meaningful information that might be used by third parties to directly locate the vulnerable code path.
Workarounds and mitigation
Two of the discussed vulnerabilities affecting Reader for Linux have been confirmed to reside in the Annots.api and PPKLite.api plugins, respectively. Since no documented ways of disabling specific plugins are available, users are advised to remove these two files from their /path/to/Adobe/Reader9/Reader/intellinux/plug_ins directory as a workaround for the issues.
There are currently no known workarounds available against any of the remaining unpatched vulnerabilities. If you believe you may be affected, you may wish to do one of the following until the patches have been released:
- Limit the use of Adobe Reader software.
- Or at least, do not open any externally received PDF documents.
- Disable the Adobe Reader browser extension for the time being.
Users of Adobe Reader 9.x for Windows who are aware of the risk are advised to upgrade to Adobe Reader X, which provides a sandbox feature, making it more difficult (although not impossible) to exploit these vulnerabilities. Unfortunately, the sandbox feature is not available for the newest versions of Adobe Reader for OS X or Linux.
- June 2012: discovery of the first set of crashes.
- 21st of June 2012: first set of crashes reported to vendor.
- 26th of June 2012: we notify Adobe that all critical crashes would be subject to the 60-day policy.
- 27th of June 2012: second set of crashes reported to vendor.
- July 2012: e-mails back and forth, we are notified not every critical issue would be fixed.
- 14th of August 2012: new version for Windows and OS X released, we publish this post.
40 thoughts on “PDF fuzzing and Adobe Reader 9.5.1 and 10.1.3 multiple critical vulnerabilities”
Have you tried the same fuzzing samples on poppler? It’d be interesting how it performs compared to other implementations.
+1 on running it on evince/poppler
@Hanno, @Fernando: We had the same idea and found a large stack of memory errors a few months ago. Unfortunately, the poppler developers don’t seem to rush to fix them: http://cgit.freedesktop.org/poppler/poppler/log/?qt=grep&q=j00ru.
What kind of fuzzer did you use to discover adobe reader vulnerability?
Comments are closed.