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