Slashdot Mirror

← Back to Stories (view on slashdot.org)

One More Mac Protocol Handler Exploit

Posted by pudge on 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.

3 of 76 comments (clear)

  1. /Library by daeley · · Score: 5, Informative
    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.
    --
    I watched C-beams glitter in the dark near the Tannhauser gate.
  2. And another one by Anonymous Coward · · Score: 5, Informative

    On Monday it was posted on the infamous MacNN thread 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.

  3. Re:What about IPFW? by genericpenguin · · Score: 5, Informative

    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!

    --
    "Why, Johnny Ringo. You look like somebody just walked over your grave." Doc Holliday, Tombstone.