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

/Library

[daeley]

If you follow John Gruber's instructions mentioned above (as you probably should, it does the job easily and fine), be aware that you'll need to apply the changes he mentions within each user account on your system. Just install the RCDefaultApp in

/Library/PreferencePanes

not

~/Library/PreferencesPanes

and then either have each user make the indicated changes, or just do them all yourself.

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.

Re:Protocol Handlers

[Anonymous Coward]

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.

But this does not save you from the previous LaunchServices exploit. The handler for ftp://, afp:// and disk:// is Finder and works as intended: it mounts a remote volume. The problem is LaunchServices then automatically goes to look for apps and URL handlers on mounted volumes. The problem here is more in LaunchServices than in the URL handler, IMO.

Re:Protocol Handlers

[0x0d0a]

But the current one *is* a protocol handler problem, and there have been attacks before against systems that mingle internal and external handlers -- it's not a problem that should just be ignored.

Re:Protocol Handlers

[smcv]

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?

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

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

Re:Protocol Handlers

[killerc]

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.

And another one

[Anonymous Coward]

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.

Re:And another one

[Anonymous Coward]

In response to this, the latest version of Paranoid Android disables ALL URL handlers except http://, https:// and mailto://.

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?

Re:What about IPFW?

[genericpenguin]

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!

All in the mind

[skinfitz]

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

Re:All in the mind

[idontsmoke]

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.

Re:All in the mind

[pudge]

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.

Re:All in the mind

[pudge]

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.

Re:All in the mind

[Anonymous Coward]

The problem is really multifaceted.

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 .plists, or use third party software to edit the helpers are not sufficient solutions in my opinion.

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.

Re:All in the mind

[skinfitz]

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

No, they are not "entirely wrong" they are absolutely right. The "fix" from Apple simply removed the Help Viewer ability to launch AppleScripts remotely, but did absolutely nothing to fix the parent exploit being the fact that any disk image can be mounted with the disk:// protocol, and that any application contained within automatically gets its custom protocol handlers assigned to it - silently. It just got worse with the ssh:// remote exploit able to execute proxy commands locally. Combine this with a recently discovered but as yet undisclosed email HTML handling vulnerability and it starts to get even worse.

As for Apple being "fairly responsive" I see absolutely no evidence that they were not notified on 23rd February as the original researcher wrote.

Re:All in the mind

[pudge]

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.

Re:All in the mind

[pudge]

You're right on for the most part, but you are flat-out wrong about "carefully rethink protocol helpers, perhaps even deprecate the current system, and reimplement it in a more security conscious manner." It is not possible. All the system does is pass arbitrary data from one app to another. Changing the system would be like making it so a web browser can't pass arbitrary data to a web server through a form interface or URL.

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:

http://slashdot.org/index.pl?runscript=$url

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

Re:All in the mind

[pudge]

So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable?

Yes, if:

1. Each door provides access to only certain parts of the home, and
2. Each door is not able to be accessed via the same methods

Let's compare the two big exploits so far, Help Viewer's runscript command, and the one where Apple adds new protocol handlers upon volume mounting.

The latter exploit is much more difficult; it requires a significant ability to program, and to prepare a volume for mounting, and a place to put that volume online, for either downloading (which won't affect the many people who turn off "open files," even thought it is the default) or online mounting (which has even greater requirements for the attacker). For exploting Help Viewer, you don't need a server, you don't need programming ability, you just need to be able to construct a URL or two cleverly, and a place to post it.

If both exploits were just as easily executed, and both allowed the same access to the system, then you're right, users would be just as vulnerable. But even granting they probably both allow the same approximate access, one is significantly more difficult to exploit.

I fine aroma indeed...

[Anonymous Coward]

Does anyone else smell the fine aroma of sensationalism, or is it just me?

Easy to test

[Onan]

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.

Needs to be addressed at a higher layer.

[Onan]

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.

Re:Needs to be addressed at a higher layer.

[pudge]

I see ... if you want a more sweeping solution that is more paranoid and catches every possible exploit in this regard, Paranoid Android is for you.

Re:help with what is going on

[System.out.println()]

1) make up your own protocol, say, "gumbi://"
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 .dmg files by default)
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.

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:help with what is going on

[geoffspear]

Reinstalling an OS X system is completely trivial. Making backups of all of your data every time you make a change to any document isn't. The average mac user probably doens't make regular backups at all, and I'd wager that 90% of those who do make backups do it weekly at best.

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.

*Yawn*

[shrapnull]

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!!!!
I still haven't had any problems and the sites I browse online either aren't the kind of sites that have those links or Paranoid Android will warn me about anything suspicious. I still have yet to see any harm done by these. It seems to be talked about a lot, but nobody's exploiting it!
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.

Re:*Yawn*

[Anonymous Coward]

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.

Re:help with what is going on

[System.out.println()]

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

NO! this is much more serious

[goombah99]

THIS IS NOT JUST ANOTHER PROTOCOL HANDLER SECUITY HOLE.

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.

ProxyCommand osascript -e 'tell application "Finder" to say "Hello, you have been owned by the ssh URI exploit"' -e 'tell application "TextEdit"' -e 'activate' -e 'set text of front document to "You have been owned by the ssh URI exploit, by kang@insecure.ws - http://insecure.ws"' -e 'end tell'

and how do we do that. well execute

ssh -F bogus_config_file dummy_host_name

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.

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.

Re:help with what is going on

[bw5353]

"Reinstalling an OS X system is completely trivial. Making backups of all of your data every time you make a change to any document isn't. "

Logically reinstalling the system is trivial. However, it will take time with all the applications.

Logically restoring a backup that does not exist is impossible. However, if it is there, it is a matter of a few minutes work.

Last time I lost my harddisk (last month or so) the by far most annoying bit was the system restore. That was admittedly just my personal experience, but I doubt I would be the only one, who makes frequent enough backups.