Monday, October 18th, 2010

PDF RCE et al. (CVE-2010-3625, CVE-2010-0191, CVE-2010-0045)

A few weeks ago, Adobe released an advisory for a ton of Acrobat Reader bugs.  Buried in the long list of Acrobat Reader bugs was a patch for a vulnerability I reported to Adobe.  Taking a look at the entry in the advisory, we see the following description:


This update resolves a prefix protocol handler vulnerability that could lead to code execution

What’s interesting is many months ago (in April 2010), Adobe released a similar patch for a different bug I had reported to them.  The description from April’s advisory is as follows:


This update resolves a prefix protocol handler vulnerability that could lead to code execution

Going back even further, there is an Apple advisory that has a bug with a description similar to the Adobe advisories:


Description: An issue in Safari’s handling of external URL schemes may cause a local file to be opened in response to a URL encountered on a web page. Visiting a maliciously crafted website may lead to arbitrary code execution.

I’ll walk you through the latest PDF bug, but the symptoms for all the bugs are very similar.  As you know, PDF Reader supports the use of JavaScript.  One of the JavaScript APIs supported by Acobat Reader (>7.0) is app.launchURL().  app.launchURL() takes two parameters, the URL to be opened and a flag that specifies whether the URL should be opened in a new window.  Typical usage of app.launchURL() looks something like this:

app.lauchURL(“” , false);

Simple enough.  Naturally, when a string that looks like URI is encountered one of the first things that’s attempted is to point the URI value to a file:// location and observe whether the local file is opened.  In this case, access to file:// is blocked by Adobe reader.  Next up are arbitrary protocol handlers.  Tests for mailto://, foo://, bar:// all work, however JavaScript:// seems to be blocked.  This feels like a protocol handler blacklist.  I think there was a SouthPark episode about using blacklists last year…

There is a simple way to bypass most protocol handler blacklists.  This bypass was the key to CVE-2010-3625, CVE-2010-0191, and CVE-2010-0045.  The trick is to simply append a “URL:” prefix protocol handler to your URI.  You can test this by opening Internet Explorer (IE8 on Win7) and typing “url:javascript:alert(1)”.  I must give credz where credz are due.  I first learned of this prefix protocol handler when looking at the source code for HTMLer (which is a port of MangleMe).

With the prefix protocol handler in hand, we’re all set to bypass the protocol handler blacklist:

app.launchURL(“url:file://c:/windows/system32/calc.exe”, true);

There is some weird shell behavior here (which I won’t get into), but the key pieces are (as far as this bug is concerned):  the url: prefix protocol handler and setting the “New Window” flag to true.  A link to a simple PoC is provided below.  This bug worked on Win7 with no prompts.  For some users, this bug will not work if IE is already running (must be launched from a browser other than IE).  For users without Adobe’s April patch, this bug should work on all browsers in most configurations.

There you go, a simple yet effective way to bypass a protocol handler blacklist.  I hope that knowledge of this prefix protocol handler provides that missing piece you needed.  Happy hunting.

Posted by xssniper | Filed in Security

2 Responses to “PDF RCE et al. (CVE-2010-3625, CVE-2010-0191, CVE-2010-0045)”

  1. November 17th, 2010 at 7:54 pm

    Jamie MotherEffin' Miami said:

    Just wanted to say, I love the Southpark reference. I saw that episode on protocol URI handler blacklists and it was very entertaining.


  2. November 21st, 2012 at 3:33 am

    Adobe’s Flash Sandbox Not So Secure After All said:

    […] the Internet as well. A solution was quickly discovered; Adobe is blacklisting protocol handlers (via) which means that Flash Player will block some protocols (like JavaScript://) while allowing others […]

Please leave a Comment