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