One More Mac Protocol Handler Exploit

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.

Comments

/Library

[daeley]

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.

Question

[cappadocius]

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.

Protocol Handlers

[0x0d0a]

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

[Anonymous Coward]

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

[smcv]

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.

And another one

[Anonymous Coward]

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.

All in the mind

[skinfitz]

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.

"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

[idontsmoke]

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

[pudge]

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

[pudge]

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

[pudge]

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.

Re:All in the mind

[pudge]

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

Re:What about IPFW?

[genericpenguin]

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!

Easy to test

[Onan]

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.

Re:help with what is going on

[geoffspear]

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.

NO! this is much more serious

[goombah99]

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.