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.
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.
omnia tua castra sunt nobis
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.
May we never see th
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.
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 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, 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?
Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
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
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.
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
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.
Don't blame me; I'm never given mod points.
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 more appears they fix that one too in a couple of weeks/months.
This is not about mocking Apple, on the contrary. We should all put 10 times more pressure on Apple to make them realize the have to make security their top priority, and never ever design ANYTHING without thinking hard about security.
This is how it started for MS windows, a decade ago. The important questions is: in 2015, do you want OS X to experience the problems windows is having now, or do you want to do something to prevent it? A good security architecture (like BSD under OS X) can help you create a more secure operating system, but it won't help squat if the programmers don't think hard about security.
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.