Slashdot Mirror
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.
I watched C-beams glitter in the dark near the Tannhauser gate.
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.
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.
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.
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.
1) make up your own protocol, say, "gumbi://" .dmg files by default)
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
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.
I've got more mod points and GMail invi
The problem is really multifaceted.
.plists, or use third party software to edit the helpers are not sufficient solutions in my opinion.
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 rather trivial.
You can disable protocol helpers that automatically mount volumes -- the exploitable ones are enabled and active by default -- but Apple provides no friendly mechanism to do so, and it still doesn't resolve the problem that some browsers (i.e., Safari) "Automatically open [un]safe files" by default. So we have a situation where the defaults behaviors aren't safe (i.e., opening "safe files" automatically, such as a disk image with malware that automatically registers itself), and where it's hard for most users to make things safer by explicitly modifying the protocol helpers. The fact that you can manually edit
The protocol helpers also compound browsing security problems, because the way protocol helpers are handled allows any web site to interact with any registered program, any bug in any helper might be exploited to compromise a computer. This is significantly worse than simply having to worry about bugs in the browser itself being exploited.
I'm not willing to let Apple off the hook on this. It designed the system that is ripe, in many ways, to compromise OS X systems browsing the web. Apple has a responsibility to lock this down, somehow. Not immediately registering programs as protocol helpers that are mounted from remote volumes and disk images would be a good start...certainly an order of magnitude better than the weak response so far. It would also be helpful if Apple implemented a mechanism to explicitly modify protocol helpers in the System Preferences, and if it removed/disabled protocol helpers such as "disk" that mount volumes in such a way that programs on them can be registered. Really something involving all of these would be good.
Something better would be to carefully rethink protocol helpers, perhaps even deprecate the current system, and reimplement it in a more security conscious manner. I'm not sure, specifically, how Apple should do that, but the current system is clearly dangerous and will clearly be a very significant ongoing source of security weakness if it is not overhauled. The current "patch helpers as we notice bad ones" is the finger-in-the-dike approach, and is not as robust as a permanent structural solution. So far it hasn't even plugged all the known holes.
Finally, the fact that I don't know how Apple should precisely fix it, doesn't excuse Apple from not coming up with some kind of solution. This is a really serious problem. Apple should put a lot of energy in to coming up with a robust solution, even if it breaks a few things in the short term.
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.
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: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).
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*.
I've got more mod points and GMail invi
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.
and how do we do that. well execute
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.Some drink at the fountain of knowledge. Others just gargle.