Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


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

One More Mac Protocol Handler Exploit 76

Posted by pudge from the yeesh dept.
There's another exploitable protocol handler, this time, ssh. Daring Fireball has an excellent summary of what you can do to protect yourself, using RCDefaultApp, and if you went that direction, and were wise enough to recognize ssh might be vulnerable too, you are safe. Paranoid Android attacks the problem from a different direction, and if you use that, you are also safe.
This discussion has been archived. No new comments can be posted.

One More Mac Protocol Handler Exploit More

One More Mac Protocol Handler Exploit

Comments Filter:

  • /Library (Score:5, Informative)

    by daeley ( 126313 ) * on Tuesday May 25, 2004 @05:31PM (#9253573) Homepage
    If you follow John Gruber's instructions mentioned above (as you probably should, it does the job easily and fine), be aware that you'll need to apply the changes he mentions within each user account on your system. Just install the RCDefaultApp in
    /Library/PreferencePanes
    not
    ~/Library/PreferencesPanes
    and then either have each user make the indicated changes, or just do them all yourself.

    • NO! this is much more serious (Score:5, Informative)

      by goombah99 ( 560566 ) on Wednesday May 26, 2004 @09:46AM (#9258717)
      THIS IS NOT JUST ANOTHER PROTOCOL HANDLER SECUITY HOLE.

      This expolit signifcantly more clever than the previous ones that were variation on the theme of protocol handlers that launch an app. This one has an extra layer of cleverness, exploiting a less well known feature of ssh. While this example is being triggered using a protocol handler, the actual exploit is more subtle than the previous ones that simply deposited an executable script or app on a mounted disk.

      This one deposits a non-executable plain text configuration file

      It works like this. ssh has a config file. You can direct ssh to use a non-default config file. Now you might be thinking "so what? config files dont contain executables." And thar you'd be wrong matey.

      It turns out that the ssh config file can tell ssh to run a script and allow you to supply that script. so here is the exploit. just get ssh to use the following config file.

      ProxyCommand osascript -e 'tell application "Finder" to say "Hello, you have been owned by the ssh URI exploit"' -e 'tell application "TextEdit"' -e 'activate' -e 'set text of front document to "You have been owned by the ssh URI exploit, by kang@insecure.ws - http://insecure.ws"' -e 'end tell'

      and how do we do that. well execute

      ssh -F bogus_config_file dummy_host_name
      So this exploit is triggerable using protocol handlers that recognize ssh:// and pass the args to ssh. Anyway you can get the bogus_file on the local host is fine. One way is to use the disk: protocol handler, but that is not the only way.
      • The only reason the attack needs to use the disk: protocol helper is if he cannot guess the path to your downloads folder. The only reason the disk: attack is handy is because it creates a known path to the downloaded file.

        If he can guess this then you dont need to use disk: to download a payload application or document. The attacker can just directly download it to your "downloads" folder, then execute it using any of the previously discussed protocol handler exploits.

        this suggests that renaming your

      • So this exploit is triggerable using protocol handlers that recognize ssh:// and pass the args to ssh. Anyway you can get the bogus_file on the local host is fine.

        Which is why you can use the above method to disable ssh:// (or any other URI protocol) handling completely.
    • Is there a difference between RDcefaultapp, more internet, and missfox. It appears they do thte same things. the only feature I've noticed on moreinternet that is missing is the ability to redirect a protocol handlet to --but you can of course simply send it to chess or something instead.

  • Question (Score:5, Interesting)

    by cappadocius ( 555740 ) <`cappadocius' `a ... emasquerade.com'> on Tuesday May 25, 2004 @05:55PM (#9253801)
    from link: Affected Products: MacOSX >= 10.3.3, Various Browsers, possibly others platforms/browsers

    Is this true what the link says: that these exploits only affect Panther? (also, am I reading the link text correctly)

    I am running Jaguar and I followed the link on an earlier story to a benign demonstration of the handler exploit, and to my knowledge it did not work.

    • Easy to test (Score:5, Informative)

      by Onan ( 25162 ) on Tuesday May 25, 2004 @09:03PM (#9255212)
      Just type ssh://your.favorite.host/ into your browser's location field. If you get a new terminal window which attempts to ssh there, obviously Mallory could do something similar to you. If you instead get safari complaining that it doesn't know what to do with ssh urls, it would seem that you're safe from this particular attack.
      • Just type ssh://your.favorite.host/ into your browser's location field. If you get a new terminal window which attempts to ssh there, obviously Mallory could do something similar to you.

        Confirmed, works in both Firefox and Safari on Jaguar.

  • Protocol Handlers (Score:5, Interesting)

    by 0x0d0a ( 568518 ) on Tuesday May 25, 2004 @05:56PM (#9253814) Journal
    You know, the first I remember hearing about protocol handlers was when Microsoft started pushing the combination of the browser and the desktop.

    Microsoft *very* commonly fails to draw a clear line between those data that can affect those things that can be externally-invoked (such as protocol handlers) and those things that may only be internally invoked. There is no reason for, say, a "help" protocol handler, though there is for an "ftp" protocol handler. There is clearly a need for two separate systems -- "remote" and "local" handlers, where "local" systems are only invoked by trusted software running on the system.

    If Apple took bad ideas from Microsoft, they deserve to chew on the bitter taste a bit.

    Note that GNOME (and I'll bet KDE, though I'm not familiar enough with KDE to know) also took this broken security design from Microsoft, and it's even bets that they have some of the same problems.

    I should be able to set things like the following with "local" handlers (ones that will only be passed "trusted good" data, and can poentially do destructive things like overwrite files based on the data passed them:
    * my terminal program (xterm, gnome-terminal, konsole, rxvt, aterm, etc)
    * my file manager
    * my "error" handler -- could spit out junk to the console, play an error sound, send stuff to syslog, bring up a dialog, whatever.
    * my password manager (this lets programs add entries automatically -- for example, my FTP program can tell my password manager to store my password whenever I bookmark a passworded site). This lets me keep an encrypted password collection without extensive manual effort.
    * My download manager, so that software can pass off downloads that they want *downloaded*, not just displayed.

    Then there are external protocol handlers. These are programs to handle each of the standard URL prefixes -- news, telnet, http, ftp, etc. It's fine for these to be systemwide, but they *never* should be combined with internal handlers. It's a really *bad* idea, and one of Microsoft's worse "innovations". They may not perform destructive acts based on the arguments passed them, and must be carefully examined to ensure that they robustly handle input passed to them.

    • Re:Protocol Handlers (Score:3, Interesting)

      by 0x0d0a ( 568518 )
      ...first remember hearing about protocol handlers...

      This should be "...first remember hearing about security problems with protocol handlers.... Heck if I know when I first heard about protocol handlers.

    • Re:Protocol Handlers (Score:4, Insightful)

      by Anonymous Coward on Tuesday May 25, 2004 @06:05PM (#9253901)
      Then there are external protocol handlers. These are programs to handle each of the standard URL prefixes -- news, telnet, http, ftp, etc. It's fine for these to be systemwide, but they *never* should be combined with internal handlers.
      But this does not save you from the previous LaunchServices exploit. The handler for ftp://, afp:// and disk:// is Finder and works as intended: it mounts a remote volume. The problem is LaunchServices then automatically goes to look for apps and URL handlers on mounted volumes. The problem here is more in LaunchServices than in the URL handler, IMO.

      • Re:Protocol Handlers (Score:3, Insightful)

        by 0x0d0a ( 568518 )
        But the current one *is* a protocol handler problem, and there have been attacks before against systems that mingle internal and external handlers -- it's not a problem that should just be ignored.

    • Re:Protocol Handlers (Score:5, Insightful)

      by smcv ( 529383 ) on Wednesday May 26, 2004 @05:58AM (#9257289) Homepage
      Once my exams are over, I plan to look through the KDE ioslaves (at least the common ones in kdebase, kdenetwork etc.) and check what standards they comply with, and whether they appear to be exploitable. I'm not a security expert, but hey, many eyes, right?

      There are two problems on the Mac:

      - Auto-registering protocols from all mounted images, while having URLs that mount a disk image with no user interaction.

      Apple need to decide where to put the security barrier - either mounting a .dmg is an expression of trust by the user, in which case Apple should never do it automatically (or at least have an unavoidable prompt before mounting remote .dmg files), or it's not, in which case newly mounted .dmg files should be considered to be untrusted and shouldn't be able to autorun anything. (Or both, of course.)

      - Some protocol handlers are mis-implemented, like the telnet one which accepts telnet:-nfoo (or telnet://-nfoo?) as a request to telnet to the host -nfoo, but naively invokes telnet with the argument -nfoo (which doesn't do what you want).

      If Mac OS X telnet used GNU-style arguments, invoking telnet -- -nfoo would be sufficient to get the desired behaviour, but since it presumably doesn't, the telnet: protocol handler should be responsible for filtering out harmful hostnames.

      (I observe that a non-GNUish telnet will be unable to connect to certain hosts via command-line arguments: if you actually have a host called -nfoo, it appears that at least Debian's Netkit telnet can only connect by running with no host parameter and instead using the command "open -nfoo")

      - Silly internal protocol handlers which are hopelessly non-standard and may not have been designed with security in mind (help:, disk:, afp:, and so on). These "URLs" are also nowhere near as Universal as they claim to be.

      KDE isn't any better in terms of number of nonstandard URI handlers, although I hope theirs are actually secure. On my computer, the Protocols page in KDE Info Centre lists the non-standard schemes about, ar, audiocd, bzip, bzip2, camera, cgi, devices, fish, floppy, fonts, ghelp, gzip, help, info, mac, man, metainfo, nfs, print, printdb, programs, psion, rdp, settings, system, tar, thumbnail, vnc, webcal, webdav/webdavs and zip; I'm not sure about the standards status of mms, mrml, rlogin, rtsp, sftp, sieve or smtp/smtps either.

      At a quick glance, cgi: doesn't look like the most secure protocol imaginable, although it appears to only allow arbitrary program execution from folders nominated by the user (a list which defaults to being empty, at least on Debian), so it might actually be OK despite appearances.
      • Meh, should have used preview. I of course meant to say that there are three problems on the Mac.

        (Nobody expects the MacOS Security Omission! Our two exploits are confused security boundaries, sloppy implementation and silly internal ... no. Our three exploits are confused security boundaries, sloppy implementation, silly internal protocol handlers and an almost fanatical devotion to Steve Jobs... oh, I'll start again.)
      • Once my exams are over, I plan to look through the KDE ioslaves (at least the common ones in kdebase, kdenetwork etc.) and check what standards they comply with, and whether they appear to be exploitable. I'm not a security expert, but hey, many eyes, right?

        That's very kind of you. I'm sure that many KDE users, whether they know it or not, will be very much happier not having their system being attacked.

        - Auto-registering protocols from all mounted images, while having URLs that mount a disk image with

    • Re:Protocol Handlers (Score:3, Informative)

      by killerc ( 462845 )
      Note that GNOME (and I'll bet KDE, though I'm not familiar enough with KDE to know) also took this broken security design from Microsoft, and it's even bets that they have some of the same problems.

      Yes, KDE's Konqueror suffers the same problem. Pass it a URL prefixed with ssh://your-server.com and it opens an ssh session Terminal window.
      • WTF? How is simply being able to open an connection to arbitraryserver.com a "problem"??

        A connection on port 22 is no more a security hole than one on port 80, so you'd better disable the "http:" handler too then!

        The only problem with the "exploit" this story is about is that the ssh: handler allows something other than a hostname. For example, switches. Some quick checking of the URI should fix this in two minutes. No spaces, no %20. No hyphen that doesn't have an alphanumeric character immediately befor
        • Opening a connection is not a problem in an of itself, it's when your web browser happily passes along these connection requests to the underlying system by direction of a link or meta-refresh embedded in a web page.

          I'm not suggesting we through out all protocol handlers besides http(s) in our browsers, but at the very least, there should be some sort of system alert window that tells the user what is transpiring.

  • And another one (Score:5, Informative)

    by Anonymous Coward on Tuesday May 25, 2004 @05:57PM (#9253821)
    On Monday it was posted on the infamous MacNN thread [macnn.com] where the previous exploit was discovered that there is yet another way to exploit LaunchServices. The previous one was to advertise a malicious app on a volume as a bogus protocol handler. LaunchServices would pick it up automatically when it mounts a disk://, disks://, ftp:// or afp:// volume. The new one is to advertise your app as a newer version of an already registered protocol handler. For unknown reasons, it doesn't work with some apps, but iTunes can be hijacked. In simple terms, you stick your malware on a disk image or ftp or afp server, you advertise it as a newer version of iTunes through Info.plist, and construct a webpage that mounts the volume. LaunchServices will automatically register it on mounting. You then have the webpage refresh or redirect to an itms:// url and your malware is launched.

    • Re:And another one (Score:3, Informative)

      by Anonymous Coward
      In response to this, the latest version of Paranoid Android [unsanity.com] disables ALL URL handlers except http://, https:// and mailto://.

  • What about IPFW? (Score:4, Interesting)

    by BandwidthHog ( 257320 ) <inactive.slashdo ... icallyenough.com> on Tuesday May 25, 2004 @06:12PM (#9253972) Homepage Journal
    Shouldn't it be possible to block these protocols via IPFW? Not that it would be any more effective than things like RC Default App (or whatever it's called), but it would seem more elegant to me to be able to protect against these issues without requiring third party software.

    Kinda sorta speaking of which, I use (and *gasp* paid for) an app called Little Snitch [obdev.com] which essentially makes IPFW interactive, intercepting network access to/from each app and getting my approval on a temporary/permanent and/or server/port basis. Prevents things from phoning home, and can give you some good insights as to what's talking to what.

    I also use a utility called Deny IP [ithyldin.org], which lets me bring up a translucent overlay (kinda like the volume control) showing details on all active connections. Doesn't prevent anything unexpected from happening, but lets me see what is happening and prevent it from recurring.

    Also, while I've got your attention, any of you Mac using slashbots know of a utility to automagically turn Apache and IPFW logs into an SQL database in (mostly) real time?

    • Re:What about IPFW? (Score:5, Informative)

      by genericpenguin ( 318967 ) on Tuesday May 25, 2004 @06:30PM (#9254143) Journal
      This is not a vulnerability with regards to particular TCP protocol. This vulnerability had to do with protocol handlers. That is, the interfaces that handle how the browser will react to a particular link when it is not a HTTP request. Firewalls won't work here. What is required is more sensible checking of what handlers are allowed to run and for what purpose. Personally, I don't see a good reason for having a SSH, IMHO. Others may disagree.

      In any case, it's a browser/system issue, not a network issue.

      genpen me baby!
    • Unfortunately, nothing untoward needs to happen at the network layer for these attacks to work. For example, I could stick an ssh:// uri into any web page you access, and use ssh's proxycommand to casually mention, "oh, and to connect to the outside world I need to run 'rm -rf /'."

      The only network traffic which took place was a perfectly valid http get from your machine to mine over port 80, but you're still shy a homedir.

      • I guess I was thinking about it in such a way that ports are roughly equivalent to protocols. So do things like afp:// and disk:// not map 1:1 to a given port? And if not, is there no way to selectively filter them, other than either map them to a given app or ignore them completely?
        • Did you read the story? This is exactly what RCDefaultApp does, it allows you to selectively disable those handlers.
          • Yes I did, and I'd already used it to disable them before I asked any of these inane questions. In the post you replied to I was asking if there were a more nuanced way to deal with this problem than totally disabling said protocols.

            I'm simply trying to get a better handle on how all these parts tie together since A) I'm obviously not quite sure of the nitty gritty details, and 2) I'd say that considering recent events, there's a decent chance we'll be looking at yet another variation on this problem next

  • All in the mind (Score:5, Funny)

    by skinfitz ( 564041 ) on Tuesday May 25, 2004 @06:14PM (#9253995) Journal
    Remember all of the recent exploits are theoretical vulnerabilities [bbc.co.uk] and therefore if you have tried out any of the proof of concept code and seen or heard your Mac do anything after clicking on these demonstrations, then you must be imagining things.

    "Apple takes security very seriously and works quickly to address potential threats as we learn of them, in this case, before there was any actual risk to our customers,"
    Philip Schiller, Apple's senior vice-president of worldwide marketing.

    "Users are still as vulnerable as Apple left them last week."
    Niels Henrik Rasmussen, Secunia

    • Re:All in the mind (Score:5, Insightful)

      by idontsmoke ( 651504 ) on Tuesday May 25, 2004 @06:51PM (#9254285)

      Remember all of the recent exploits are theoretical vulnerabilities and therefore if you have tried out any of the proof of concept code and seen or heard your Mac do anything after clicking on these demonstrations, then you must be imagining things.

      Also, "all of the recent exploits" are actually just a single issue, that of URL handlers going unchecked, rather than a whole plethora of exploits as the number of recent reports might have you believe.

      • Re:All in the mind (Score:5, Insightful)

        by pudge ( 3605 ) * <<slashdot> <at> <pudge.net>> on Tuesday May 25, 2004 @08:30PM (#9255013) Homepage Journal
        Well, in one sense, that's true. But considering the only fixes from Apple address the actual problems (such as fixing Terminal and Help Viewer), that clearly shows them to be distinct. Indeed, no one has come up with a way to actually fix the problem at the protocol handler level, because the exploits are far too different. Who is to say if telnet://-nFoo is dangerous? You can't tell that by looking at the URL, you can only tell by seeing what the app does with it.

        They all have a common thread, use of the protocol handler facility, but exploit that in very different ways. The only solution is to disable the facility, which ain't gonna happen, or have application authors be much more careful about what data they accept from the facility.

        It's just like in web programming: anything that comes from the web browser cannot be trusted for potentially dangerous operations. You define those operations -- such as writing files, opening applications, installing new protocol handlers -- and you don't allow those things to happen without specific user interaction or permission.

        iChat has the "aim" protocol handler, and there's been security holes in other apps because of it, for the same reasons. Does iChat have these problems too? I dunno, but if Apple is smart, every single app it has that accepts a GURL Apple event will be triple-checked to make sure nothing unsafe is allowed.

        • Re:All in the mind (Score:2, Informative)

          by Anonymous Coward
          The problem is really multifaceted.

          First there are individual exploits on many of the protocol handlers. Another is that the system automatically registers any program too soon, so if you can figure out someway to simply get a malicious program on to a computer, you can run it at your discretion by calling a URL from your web site. Getting the the program on to the computer can be accomplished by taking advantage of preexisting protocol helpers, so both steps in the process of taking over a computer seem r

          • Re:All in the mind (Score:5, Informative)

            by pudge ( 3605 ) * <<slashdot> <at> <pudge.net>> on Wednesday May 26, 2004 @09:19AM (#9258515) Homepage Journal
            You're right on for the most part, but you are flat-out wrong about "carefully rethink protocol helpers, perhaps even deprecate the current system, and reimplement it in a more security conscious manner." It is not possible. All the system does is pass arbitrary data from one app to another. Changing the system would be like making it so a web browser can't pass arbitrary data to a web server through a form interface or URL.

            The only solution is the finger-in-the-dike approach, except more proactive than you describe: to audit every single application that receives the data, and make sure that it doesn't allow any dangerous operation with the data it receives. This is what web programmers around the world have to do (often failing miserably). Is this a robust permanent solution? No, but there is no robust permanent solution.

            I've been dealing with this for years in the Slash code. If one of our programmers wanted to, we could allow this:
            http://slashdot.org/index.pl?runscript=$url
            Then index.pl would download the script at $url and execute it. Perl can't solve that problem, and neither can the underlying Slash code. If index.pl allows that, there's nothing that can be done except to fix index.pl, or disable it. Oh, sure, we could disable the "runscript" parameter at a lower level, but that really is the intolerable finger-in-the-dike approach, because index.pl could just use some other parameter name.

            Look at iChat. Part of the aim handler suite are getfile and sendfile commands. iChat does not have those implemented, probably in part out of security concerns. Terminal should not allow arbitrary command-line options to be passed to it from a URL: if it allows commands to be run at all, it should filter any option out that might lead to writing a file, reading a file and sending its data over the connection, opening an additional possibly unsafe process, etc. Help Viewer should not allow running arbitrary scripts or opening arbitrary applications. The OS should not automatically modify system settings based on the mounting of a volume.

            There's no way to deal with these except to make sure the target applications deal with all the incoming data safely, or shut down the protocol handler altogether (as we must temporarily do until Apple fixes the applications).
            • finger-in-the-dike

              I have to say, the hypens drew my eyes to this part of the post, and I enjoyed it so much, I didn't read the rest of it.

    • Re:All in the mind (Score:5, Insightful)

      by pudge ( 3605 ) * <<slashdot> <at> <pudge.net>> on Tuesday May 25, 2004 @08:13PM (#9254901) Homepage Journal
      The problem is that Secunia is entirely wrong. The removal of runscript left users less vulnerable. The exploit was much worse than any of the others, and even if it weren't, it is different, so the users are not just as vulnerable, because that exploit is removed (for those who updated).

      And Apple has been failry responsive, as far as we know. If it is true -- which is unverified -- that Apple was told about the runscript hole in February, then fine, Apple dropped the ball. But we don't know that and can't assume it.

      Of course, when it comes right down to it, both companies are spinning to make themselves money. But Secunia is doing it with FUD, which makes it far more distasteful.

      • Re:All in the mind (Score:3, Insightful)

        by skinfitz ( 564041 )
        "The problem is that Secunia is entirely wrong. The removal of runscript left users less vulnerable. The exploit was much worse than any of the others, and even if it weren't, it is different, so the users are not just as vulnerable, because that exploit is removed (for those who updated)."

        No, they are not "entirely wrong" they are absolutely right. The "fix" from Apple simply removed the Help Viewer ability to launch AppleScripts remotely, but did absolutely nothing to fix the parent exploit being the f

        • Re:All in the mind (Score:5, Insightful)

          by pudge ( 3605 ) * <<slashdot> <at> <pudge.net>> on Wednesday May 26, 2004 @09:01AM (#9258395) Homepage Journal
          No, you're wrong too. It is simple math. You have a pile of exploits. You remove one, and now you have fewer possible exploits. You are therefore less vulnerable.

          As for Apple being "fairly responsive" I see absolutely no evidence that they were not notified on 23rd February as the original researcher wrote.

          And I see no evidence they were informed; further, how were they informed, if it did happen? Was it a "dude, your browser sucks! I can totally 0wnZ j00!" email sent to steve@apple.com? Or was it a well-written report sent through the proper channels? Or was it somewhere in between? I won't assume Apple was notified, or that it was done properly, just because someone says so.
          • No, you're wrong too. It is simple math. You have a pile of exploits. You remove one, and now you have fewer possible exploits. You are therefore less vulnerable.

            Normally I'd agree with you, HOWEVER when the Help Viewer exploit was known, the infinitely more serious custom protocol handler and SSH exploits were not known, and so therefore we went from one exploit to many overnight. The real problem is the parent protocol handler exploit - fixing the Help Viewer was irrelevant and didn't fix anything apar
            • As far as you know, it was not known. And even if it was not known. it was still an existing vulnerability. There's no doubt on this.

              And no, that is not evidence, that is assertion. It doesn't say how Apple was notified, it merely says "i told Apple on 23rd of February". The lack of good form in this posting makes me extremely skeptical that Apple was notified properly, if at all.
          • And I see no evidence they were informed; further, how were they informed, if it did happen? Was it a "dude, your browser sucks! I can totally 0wnZ j00!" email sent to steve@apple.com? Or was it a well-written report sent through the proper channels? Or was it somewhere in between? I won't assume Apple was notified, or that it was done properly, just because someone says so.

            Really? So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate a

            • So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate authors of those flaws?

              I am holding them both to the same standard [wiretrip.net]. Whichever group did not follow such a reasonable procedure is to blame. I don't know which is to blame, so I blame neither.

              Ultimately, you have to believe one or the other.

              A more ridiculous statement I've not seen all week. Congratulations!

              it's odd to heap skepticism verging on contempt upon the former

              I am n
              • Ultimately, you have to believe one or the other.
                A more ridiculous statement I've not seen all week. Congratulations!

                But unhappily for you it is a binary operation, my dear Pudge. Either the researcher notified Apple in February, or he did not. You may believe the researcher, or you may believe that Apple has not been notified. Choose wisely. :-)

                • Either the researcher notified Apple in February, or he did not.

                  You mean either he notified Apple *properly*, or he did not. True. But so what? Why should I have to pick one or the other to believe? What kind of depraved existence do you live that you feel you must decide on everything, despite lack of sufficient evidence?
          • No, you're wrong too. It is simple math. You have a pile of exploits. You remove one, and now you have fewer possible exploits. You are therefore less vulnerable.

            So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable? The math doesn't seem quite so simple to me. I have a nagging suspicion that locking the last door makes a much greater contribution to my security than does locking the first door.

            • Re:All in the mind (Score:3, Insightful)

              by pudge ( 3605 ) *
              So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable?

              Yes, if:

              1. Each door provides access to only certain parts of the home, and
              2. Each door is not able to be accessed via the same methods

              Let's compare the two big exploits so far, Help Viewer's runscript command, and the one where Apple adds new protocol handlers upon volume mounting.

              The latter exploit is much more difficult; it requires a significant ability to program, and to prepare a volume for mounting, and a place to p
              • 1. Each door provides access to only certain parts of the home, and
                2. Each door is not able to be accessed via the same methods

                Well, in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files. And the "method" that I have in mind is the "script kiddie" method: Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.
                • in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files

                  It is not merely about location. Clearly, the telnet exploit, which can overwrite only one known file, is not nearly as serious as an exploit which can run arbitrary code.

                  Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.

                  Yes, which is significantly more co

          • And I see no evidence they were informed; further, how were they informed, if it did happen? Was it a "dude, your browser sucks! I can totally 0wnZ j00!" email sent to steve@apple.com? Or was it a well-written report sent through the proper channels? Or was it somewhere in between? I won't assume Apple was notified, or that it was done properly, just because someone says so.

            The person who claimed to have reported this to Apple in Februari, lixlpixel [macnn.com], was credited by Apple [apple.com] for reporting the issue.

  • I fine aroma indeed... (Score:2, Insightful)

    by Anonymous Coward
    Does anyone else smell the fine aroma of sensationalism, or is it just me?

    • Re:I fine aroma indeed... (Score:1, Interesting)

      by Anonymous Coward
      There may be some sensationalism, but that doesn't diminish the undeniable seriousness of the problem, nor Apple's ongoing failure to meaningfully address it.
  • Sorry, but can someone please explain the exploit? How is ssh involved? Part of the problem is that the workaround site won't resolve on my computer...

    • Re:help with what is going on (Score:4, Informative)

      by System.out.println() ( 755533 ) on Tuesday May 25, 2004 @09:30PM (#9255372) Journal
      1) make up your own protocol, say, "gumbi://"
      2) before you link to this protocol, make the user download "http://your.ip.address/eraseharddrive.dmg". The user downloads this and mounts it (because most browsers automatically open .dmg files by default)
      3) set eraseharddrive.dmg up with a program that erases the user's hard drive. Set this app to be the default handler for the gumbi:// protocol.
      4) NOW link to a gumbi:// address. Your malware has been executed.

      I do have one question: this doesn't gain root access or anything, does it? at worst, it could erase your Home directory.
      • What is worse than having your home directory deleted? I don't give two shakes about /System, all my important stuff is in ~/.
        • "all my important stuff is in ~/."

          Agree to some extent.

          The bad thing is that all your precious docs can disappear or be sent away to a nasty exploiter.

          The good thing is that you don't have to reinstall the system afterwards. It is enough to restore your properly made backup. That's some consolation at least.

          The worst (?) potential consequence I can think of with the present situation is the malware grabbing a text file, where I have written down all the passwords to my Swiss bank accounts, and sending

          • Re:help with what is going on (Score:5, Insightful)

            by geoffspear ( 692508 ) * on Wednesday May 26, 2004 @08:08AM (#9257916) Homepage
            Reinstalling an OS X system is completely trivial. Making backups of all of your data every time you make a change to any document isn't. The average mac user probably doens't make regular backups at all, and I'd wager that 90% of those who do make backups do it weekly at best.

            Of course, the real problem with malware running with root privileges isn't that it can delete /; it can install pretty much whatever backdoors and spyware it wants on your system and cover its tracks pretty effectively.

            • "Reinstalling an OS X system is completely trivial. Making backups of all of your data every time you make a change to any document isn't. "

              Logically reinstalling the system is trivial. However, it will take time with all the applications.

              Logically restoring a backup that does not exist is impossible. However, if it is there, it is a matter of a few minutes work.

              Last time I lost my harddisk (last month or so) the by far most annoying bit was the system restore. That was admittedly just my personal exper

          • I suppose you don't do real work on your computer. For many people their home directories store thousands of man-hours worth of work. Whether its uncommited code, customer databases, important e-mail, Photoshop files, iTunes music, or a master's thesis it is all stuff you're not getting back if it goes away. Someone doesn't have to get ahold of your bank account numbers to cause you financial harm either. If they can snag an e-mail with your Paypal information they can do all sorts of nasty stuff.

            That is f
            • "For many people their home directories store thousands of man-hours worth of work."

              To me we do not say different things, we just stress different aspects. With the sentence above, you surely don't literally mean that there would be many users with thousands of man-hours without one single backup. (If I found such a user I would give him a type-writer.) What you mean is that many users do not make back-ups frequently enough to avoid annoying or even catastrophic losses, and that is certainly true.

              I know

      • so to implement this you need a trojan as well (the .dmg). and how did ssh get involved?
        • The SSH exploit wasn't a particularly bad one. basically, on a ssh:// link, you could specify a filename for it to use as a log (in the Home folder) and it would overwrite that one file. But it couldn't be a directory, and you had to know the exact name of the file, so there's not a lot it could actually *do*.
      • 1) make up your own protocol, say, "gumbi://"
        2) before you link to this protocol, make the user download "http://your.ip.address/eraseharddrive.dmg". The user downloads this and mounts it (because most browsers automatically open .dmg files by default)

        yep but in case this isn't totally redundant already, this whole boogaloo can be avoided with the Little Snitch [obdev.at]. When the diskimage-loader tries to access the net, you WILL be prompted by the SNitch. simply deny the connection and watch as "gumbi" is repo
  • This is really annoying. Apple seems to have forgotten everything that the personal computer industry has learned over the past 20 years. They seem to be starting the learning curve from day 0.

    This may in an attempt to compete with MS. MS has committed some very stupid security mistakes and in the process have gotten users used to the perks that are side effects of those secutity mistakes. The most prominent perk is that the user can just hit a button and make this happen. Users do not want to have t

    • > althogh I discount points for them turning off the firewall
      >automagically when the service is turned on. ...because, of course, most people who turn on printer or file sharing want to only share it with localhost.

  • *Yawn* (Score:2, Insightful)

    by shrapnull ( 780217 )
    Okay, okay, you found another protocol exception in a preexisting bug. You can bet the handler's will be readdressed shortly, but in the mean time (and I'm sure I speak for most OS X users here) SO WHAT!!!!
    I still haven't had any problems and the sites I browse online either aren't the kind of sites that have those links or Paranoid Android will warn me about anything suspicious. I still have yet to see any harm done by these. It seems to be talked about a lot, but nobody's exploiting it!
    The bugs will

    • Re:*Yawn* (Score:3, Insightful)

      by Anonymous Coward
      Okay, okay, you found another protocol exception in a preexisting bug. You can bet the handler's will be readdressed shortly, but in the mean time (and I'm sure I speak for most OS X users here) SO WHAT!!!!

      The bugs will be fixed in the next couple of weeks so quit crying about something that could be exploited , but hasn't.
      Surely, the system is broken, but not for long.

      Sigh. This is *exactly* the same behavior as Microsoft has been showcasing the last couple of years. Fix on bug at a time, and when one m
      • A valid point about Windows and how Apple has a good rep for doing better from the get-go, but my point is that it's pretty much the same bug that's being addressed already...protocol handlers. Paranoid Android does well for this problem already, and if you had read the previous two posts about this exploit and took appropriate action, you are already protected.
    • "It seems to be talked about a lot, but nobody's exploiting it!"

      I hope you are right, but you have not convinced me.

      This morning I suddenly realised that I accessed a lot of "unknown" web pages through Google. I made a search for images of "lanterns" (no, you do not want to know why), and to compare the images I quickly clicked on 10 different pages in 10 tabs, and got to 10 different servers that were new to me.

      Out of the thousands and thousands of programmers who could use the exploit, I'm sure that

  • A destructive exploit of this vulnerability doesn't seem to have materialized yet, which is a "good thing".
    I believe that the reason for this stems from the fact that one cannot remain truly anonymous while delivering the "package".
    If an individual were to post a tainted link to a destructive exploit, the source of that link would act as a very large "finger" pointing back to the perp. Simply contact the web server administrator and follow the bread crumb trail. If the admin refuses to cooperate, appl

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close