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

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

[0x0d0a]

...first remember hearing about protocol handlers...

This should be "...first remember hearing about security problems with protocol handlers.... Heck if I know when I first heard about protocol handlers.

What about IPFW?

[BandwidthHog]

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?

making all the mistakes again

[fermion]

This is really annoying. Apple seems to have forgotten everything that the personal computer industry has learned over the past 20 years. They seem to be starting the learning curve from day 0.

This may in an attempt to compete with MS. MS has committed some very stupid security mistakes and in the process have gotten users used to the perks that are side effects of those secutity mistakes. The most prominent perk is that the user can just hit a button and make this happen. Users do not want to have to save a file, manually unpack the file, and then install the file. They want to happen all at once. From a security point of view it is stupid, but it is waht people want. Apple should have resisted the pressure to do the same stupid thing. They did not.

OS X has just been a continuous stream of these stupid things. Putting non-security patches in security updates. Not implemeting a secure update facility. Putting in a point click control panel for non-common network services without fully educating the user on the risks of those services. I at least give them credit for turning off all services by default and including a soft firewall, althogh I discount points for them turning off the firewall automagically when the service is turned on.

Re:I fine aroma indeed...

[Anonymous Coward]

There may be some sensationalism, but that doesn't diminish the undeniable seriousness of the problem, nor Apple's ongoing failure to meaningfully address it.

Rename your downloads folder

[goombah99]

The only reason the attack needs to use the disk: protocol helper is if he cannot guess the path to your downloads folder. The only reason the disk: attack is handy is because it creates a known path to the downloaded file.

If he can guess this then you dont need to use disk: to download a payload application or document. The attacker can just directly download it to your "downloads" folder, then execute it using any of the previously discussed protocol handler exploits.

this suggests that renaming your downloads folder to some non-guessable name would be a good idea. (e.g. dont put a foloder nmaed downloads on your dekstop, home, or documents folder! )

It also suggests a possible but perhaps bad kludge workaround on this problem till Apple fixes it. Create an OSX folder-action for your /Volumes folder. this folder action can either rename anything placed in the folder or move the item to another location. That way anying mounted will not have a known path.