During the recent Opcde event in Dubai, we discussed how auditing closed source software can be made easier if you look a their open source components first. Developing new features into existing software can be a costly and time-consuming process. Modern software manufacturers often reduce these costs with the inclusion of open-source components into large, closed sourced applications. However, leveraging open source for a quick functionality boost comes with security side effects that might not be understood by the vendor until it is too late. In those cases, misunderstood or poorly implemented open source software allows attackers to bypass security mechanisms that may exist elsewhere in the proprietary system.

Adobe Reader provides an interesting insight into these side effects. Adobe Reader is one of the most widely used document readers on the market today. To implement some of these capabilities, Adobe Reader integrates existing open source projects into their product. For example, Adobe currently includes a modified version of the libtiff library for Tagged Image File Formation (TIFF) image parsing along with Sablotron for Extensible Stylesheet Language Transformations (XSLT) handling. Unfortunately, the Sablotron open source program is now abandoned and as a result does not have a community behind it to implement fixes.

Vulnerabilities in the Adobe Reader XSLT engine began to emerge in 2012. Two of these vulnerabilities were reported that year and were fixed in security updates. These vulnerabilities were discussed at length during a security conference presentation, but the community has not paid much attention to this attack surface since those disclosures. Then, three years later, new vulnerability submissions targeting the Adobe Reader XSLT engine started appearing in the Zero Day Initiative’s (ZDI) queue. These vulnerabilities were discovered using a combination of fuzzing and auditing the open source Sablotron code.

Today, we’re publishing this paper to shed light on both old and new vulnerabilities found in Adobe Reader’s XSLT engine, including several that needed to be patched more than once. It focuses on techniques for auditing the source code of Sablotron to find corresponding bugs in Adobe Reader. The paper also presents a new source-to-binary matching technique to help researchers pinpoint the vulnerable conditions within Sablotron that also reside in the assembly of Reader. Real-world application of these techniques are demonstrated in the paper through a series of code execution vulnerabilities discovered in Adobe Reader’s codebase.

If you didn’t get a chance to see the presentation, take a few moments to review the paper, and follow us on Twitter to see the latest in vulnerability research.