March 15, 2013 By Mark Yason 4 min read

Hi Everyone, Mark Yason here from IBM X-Force. Last month, we saw the first in-the-wild exploit [1] capable of escaping the Adobe Reader sandbox, a security feature added in Adobe Reader in 2010 to limit the impact of successful exploitation of Reader vulnerabilities. In this post, I’ll describe the sandbox vulnerability that was leveraged by the exploit and the same vulnerability I found in the sandbox feature of the Adobe Flash Player for Firefox.

Reader Sandbox Vulnerability

The Reader sandbox configuration is composed of two processes – the sandbox process (also called the renderer process) and the broker process. The sandbox process is responsible for parsing and rendering the PDF content while the broker process, among other things, is responsible for executing privileged operations.

The broker process exposes several services which are callable from the sandbox process. These services are used for executing privileged operations on behalf of the sandbox process (provided that the operation is allowed by the sandbox policies) and for requesting the broker process to perform a particular action. These services are invoked thru an IPC connection between the sandbox process and the broker process:

The Reader sandbox vulnerability that was exploited last month is in one of the services exposed by the broker process. Specifically, it is the service that handles the execution of the GetClipboardFormatNameW() API [2]  in the context of the broker. The vulnerable code (in equivalent C version) looks similar to this:

GetClipboardFormatNameW(format, name->buffer, name->size);

Where name->buffer is a pointer to an output buffer that will receive the clipboard format name and name->size is the size of the output buffer in bytes.

At first glance, there seem to be no problem with the API call; however, carefully reading the entry of the API in MSDN [2] shows what the problem is. The issue is that the third argument should be the size of the output buffer in characters – not the size of the output buffer in bytes! In the case of the vulnerable code, the call is for a wide character version of the API, which means that a character is treated as two bytes, this in turn results to the output buffer being treated larger (double) than its actual size.

Because of the vulnerability, the exploit was able to write past the boundary of the output buffer. By carefully crafting the broker’s heap layout so that a memory block adjacent to the output buffer contains an object, the exploit was able to overwrite and control the object’s virtual function table pointer. Full control of the broker process then happened when the controlled virtual function table pointer is dereferenced for a virtual function call.

Flash Sandbox Vulnerability

While looking at the Reader sandbox vulnerability, I realized the possibility of the bug also existing in the sandbox code of the Adobe Flash Player for Firefox (Firefox Flash), and the reason is that the Firefox Flash sandbox code is based on the Reader sandbox code [3].

I also remembered that there are dispatcher classes (classes that group exposed broker services according to function) which are found in both the Reader and Firefox Flash sandbox.  Interestingly, the vulnerable service in the Reader sandbox is part of the SandboxClipboardDispatcher, a dispatcher class which is also found in the Firefox Flash sandbox! [4, 3]

So I quickly and anxiously looked at the Firefox Flash code, examined the single function that references the GetClipboardFormatNameW() API, and my heart suddenly skipped a beat when I found the same of vulnerable code (in equivalent C version):

GetClipboardFormatNameW(format, name->buffer, name->size);

After verification of the bug, I hastily wrote a proof-of-concept code (PoC) to demonstrate that a Firefox Flash sandbox escape is possible and then quickly documented my findings afterwards. We then immediately submitted our PoC and findings to Adobe; Adobe on the other hand within a matter of few days released a patch [5] that includes a fix for the sandbox escape bug we reported to them – a very quick turnaround!

Conclusion

The buffer overflow vulnerability that resulted to the two sandbox escapes was due to an incorrect buffer size argument passed to a wide character version of an API. The mishap can happen to anyone as there are APIs that receive a buffer size in bytes and there are APIs that receive a buffer size in characters and that may sometimes lead to confusion. Similar bugs can be weeded out from a codebase by looking for calls to APIs that have a corresponding ANSI and wide character versions and that receive a buffer size as an argument. Once suspect API calls are found, the passed buffer size argument can then be evaluated if they correspond to what the API expects.

Finally, if you are interested in the inner workings of the Adobe Reader and the Adobe Flash Player sandbox, please refer to the papers my colleague Paul Sabanal and I wrote and presented at Black Hat [4, 3].

References

[1] “APSB13-07 – Security updates available for Adobe Reader and Acrobat,” [Online]. Available: http://www.adobe.com/support/security/bulletins/apsb13-07.html
[2] “MSDN – GetClipboardFormatName function,” [Online]. Available: http://msdn.microsoft.com/en-us/library/windows/desktop/ms649040(v=vs.85).aspx
[3] “Black Hat USA 2012 – Digging Deep Into The Flash Sandboxes,” [Online]. Available: http://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_WP.pdf
[4] “Black Hat USA 2011 – Playing In The Reader X Sandbox,” [Online]. Available: http://media.blackhat.com/bh-us-11/Sabanal/BH_US_11_SabanalYason_Readerx_WP.pdf
[5] “APSB13-08 – Security updates available for Adobe Flash Player,” [Online]. Available: http://www.adobe.com/support/security/bulletins/apsb13-08.html

More from X-Force

Ongoing ITG05 operations leverage evolving malware arsenal in global campaigns

13 min read - As of March 2024, X-Force is tracking multiple ongoing ITG05 phishing campaigns featuring lure documents crafted to imitate authentic documents of government and non-governmental organizations (NGOs) in Europe, the South Caucasus, Central Asia, and North and South America. The uncovered lures include a mixture of internal and publicly available documents, as well as possible actor-generated documents associated with finance, critical infrastructure, executive engagements, cyber security, maritime security, healthcare, business, and defense industrial production. Beginning in November 2023, X-Force observed ITG05…

Why federal agencies need a mission-centered cyber response

4 min read - Cybersecurity continues to be a top focus for government agencies with new cybersecurity requirements. Threats in recent years have crossed from the digital world to the physical and even involved critical infrastructure, such as the cyberattack on SolarWinds and the Colonial Pipeline ransomware attack. According to the IBM Cost of a Data Breach 2023 Report, a breach in the public sector, which includes government agencies, is up to $2.6 million from $2.07 million in 2022. Government agencies need to move…

CVE-2023-20078 technical analysis: Identifying and triggering a command injection vulnerability in Cisco IP phones

7 min read - CVE-2023-20078 catalogs an unauthenticated command injection vulnerability in the web-based management interface of Cisco 6800, 7800, and 8800 Series IP Phones with Multiplatform Firmware installed; however, limited technical analysis is publicly available. This article presents my findings while researching this vulnerability. In the end, the reader should be equipped with the information necessary to understand and trigger this vulnerability.Vulnerability detailsThe following Cisco Security Advisory (Cisco IP Phone 6800, 7800, and 8800 Series Web UI Vulnerabilities - Cisco) details CVE-2023-20078 and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today