Archive for the 'Security' Category

Wednesday, December 22nd, 2010

Expanding the Attack Surface

Imagine there is an un-patched Internet Explorer vuln in the wild.  While the vendor scrambles to dev/test/QA and prime the release for hundreds of millions of users (I’ve been there… it takes time), some organizations may choose to adjust their defensive posture by suggesting things like, “Use an alternate browser until a patch is made available”.

So, your users happily use FireFox for browsing the Internet, thinking they are safe from any IE 0dayz… after all IE vulnerabilities only affect IE right?  Unfortunately, the situation isn’t that simple.  In some cases, it is possible to control seemingly unrelated applications on the user’s machine through the browser.  As an example (I hesitate to call this a bug, although I did report the behavior to various vendors) we can use various browser plugins to jump from FireFox to Internet Explorer and have Internet Explorer open an arbitrary webpage.

  1. Requirements:  Firefox, Internet Explorer, and Adobe PDF Reader (v9 or X)
  2. Set the default browser to Internet Explorer (common in many enterprises)
  3. Open Firefox and browse to the following PDF in Firefox:

Firefox will call Adobe Reader to render the PDF, Adobe Reader will then call the default browser and pass it a URL, the default browser (IE) will render the webpage passed by the PDF.

The example I provide simply jumps from Firefox to IE and loads, however I’m free to load any webpage in IE.  To be fair, we can substitute Firefox for Safari or Opera and it will still work.

Achieving this is simple.  We use a built-in Adobe Reader API called app.launchURL().  Looking at the documentation for the launchURL() API, we see that launchURL() takes two parameters: cURL (required) and bNewFrame (optional).  cURL is a string that specifies the URL to be launched and bNewFrame provides an indication as to whether cURL should be launched in a “new window of the browser application”.  In this case, “new window of the browser application” really means the default browser.

A simple one liner in Adobe Reader JavaScript gets it done:


Happy hunting…

Posted by xssniper | Filed in Security | 2 Comments »


Friday, December 17th, 2010

Will it Blend?

I had the honor of presenting at RuxCon and BayThreat this year.  Both were great conferences with great people.  I’m always humbled when I learn of what others are doing in the security community and even more humbled when asked to present.  I gave a presentation called Will It Blend.  The title of the talk is based on a series of videos from Blendtec (I could watch these videos all day).  The content of the talk however is about “blended threats”.  During the talk I presented a set of bugs I discovered in various browser plug-ins.  Independently, these bugs are pretty lame.  However, if we chain the bugs together, we get something that’s actually pretty interesting.  If you’re interested in taking a look at the slides, you can find them here (PPTPLEX format) or on the RuxCon/Baythreat websites.  The vuln chaining is a little difficult to visualize by looking at the slides, so at the end of my talk I gave a live demo of the bugs being chained together.  For those who were unable to attend my talk live, I’ve created a video to help understand how the exploit would be pulled off (  It will help to go over the slides first, then watch the video.

Most of the relevant code is available in the slide deck (its really simple).  There are around 5 different bugs in play here, involving a variety of vendors.  All the vendors involved have been contacted.  The oldest bug here is over a year old, the youngest is about five months old.  Kudos to Adobe.  Adobe X has changed its caching behavior, so this specific attack cannot be used against Adobe X users. 

I’m not sure where the blame lies for fixing these issues.  On one hand, if a single vendor addresses their portion of the attack, the entire chain of vulnerabilities is broken.  On the other hand, if only one vendor addresses their issue, all we have to do is find some other software/plugin that buys us the same capability and its game on again.

I hope someone finds the presentation useful.  Happy hunting.

Posted by xssniper | Filed in Security | 5 Comments »


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 Comments »