One More Mac Protocol Handler Exploit 76
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.
/Library (Score:5, Informative)
NO! this is much more serious (Score:5, Informative)
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.
and how do we do that. well execute
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 (Score:3, Interesting)
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
Re:NO! this is much more serious (Score:2)
Which is why you can use the above method to disable ssh:// (or any other URI protocol) handling completely.
RCDEFAULTAP (Score:2)
Re:RCDEFAULTAP (Score:2)
Question (Score:5, Interesting)
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.
Easy to test (Score:5, Informative)
Re:Easy to test (Score:2)
Confirmed, works in both Firefox and Safari on Jaguar.
Protocol Handlers (Score:5, Interesting)
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 (Score:3, Interesting)
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 (Score:4, Insightful)
Re:Protocol Handlers (Score:3, Insightful)
Re:Protocol Handlers (Score:5, Insightful)
There are two problems on the Mac:
- Auto-registering protocols from all mounted images, while having URLs that mount a disk image with no user interaction.
Apple need to decide where to put the security barrier - either mounting a
- Some protocol handlers are mis-implemented, like the telnet one which accepts telnet:-nfoo (or telnet://-nfoo?) as a request to telnet to the host -nfoo, but naively invokes telnet with the argument -nfoo (which doesn't do what you want).
If Mac OS X telnet used GNU-style arguments, invoking telnet -- -nfoo would be sufficient to get the desired behaviour, but since it presumably doesn't, the telnet: protocol handler should be responsible for filtering out harmful hostnames.
(I observe that a non-GNUish telnet will be unable to connect to certain hosts via command-line arguments: if you actually have a host called -nfoo, it appears that at least Debian's Netkit telnet can only connect by running with no host parameter and instead using the command "open -nfoo")
- Silly internal protocol handlers which are hopelessly non-standard and may not have been designed with security in mind (help:, disk:, afp:, and so on). These "URLs" are also nowhere near as Universal as they claim to be.
KDE isn't any better in terms of number of nonstandard URI handlers, although I hope theirs are actually secure. On my computer, the Protocols page in KDE Info Centre lists the non-standard schemes about, ar, audiocd, bzip, bzip2, camera, cgi, devices, fish, floppy, fonts, ghelp, gzip, help, info, mac, man, metainfo, nfs, print, printdb, programs, psion, rdp, settings, system, tar, thumbnail, vnc, webcal, webdav/webdavs and zip; I'm not sure about the standards status of mms, mrml, rlogin, rtsp, sftp, sieve or smtp/smtps either.
At a quick glance, cgi: doesn't look like the most secure protocol imaginable, although it appears to only allow arbitrary program execution from folders nominated by the user (a list which defaults to being empty, at least on Debian), so it might actually be OK despite appearances.
Re:Protocol Handlers (Score:2)
(Nobody expects the MacOS Security Omission! Our two exploits are confused security boundaries, sloppy implementation and silly internal
Re:Protocol Handlers (Score:2)
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
Re:Protocol Handlers (Score:3, Informative)
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 (Score:2)
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 befor
Re:Protocol Handlers (Score:1)
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 (Score:5, Informative)
Re:And another one (Score:3, Informative)
What about IPFW? (Score:4, Interesting)
Kinda sorta speaking of which, I use (and *gasp* paid for) an app called Little Snitch [obdev.com] 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 [ithyldin.org], 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? (Score:5, Informative)
In any case, it's a browser/system issue, not a network issue.
genpen me baby!
Needs to be addressed at a higher layer. (Score:3, Informative)
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. (Score:2)
Re:Needs to be addressed at a higher layer. (Score:2)
Re:Needs to be addressed at a higher layer. (Score:2)
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
Re:Needs to be addressed at a higher layer. (Score:3, Informative)
All in the mind (Score:5, Funny)
"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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:2, Informative)
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 r
Re:All in the mind (Score:5, Informative)
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: 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 (Score:2)
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 (Score:2)
Well, yes, you can put up warnings, but most people w
Re:All in the mind (Score:2)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
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 f
Re:All in the mind (Score:5, Insightful)
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 (Score:2)
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 (Score:2)
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 apar
Re:All in the mind (Score:2)
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 (Score:2)
Really? So independent researchers uncovering security flaws are now to be held up to a higher burden of proof than the corporate a
Re:All in the mind (Score:2)
I am holding them both to the same standard [wiretrip.net]. 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 n
Re:All in the mind (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:3, Insightful)
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 p
Re:All in the mind (Score:2)
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 (Score:2)
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 co
Re:All in the mind (Score:2)
The person who claimed to have reported this to Apple in Februari, lixlpixel [macnn.com], was credited by Apple [apple.com] for reporting the issue.
I fine aroma indeed... (Score:2, Insightful)
Re:I fine aroma indeed... (Score:1, Interesting)
help with what is going on (Score:2)
Re:help with what is going on (Score:4, Informative)
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
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 (Score:2)
Re:help with what is going on (Score:1)
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
Re:help with what is going on (Score:5, Insightful)
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 (Score:2, Insightful)
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 exper
Re:help with what is going on (Score:2)
That is f
Re:help with what is going on (Score:1)
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
Re:help with what is going on (Score:2)
Re:help with what is going on (Score:3, Informative)
Re:help with what is going on (Score:1)
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
yep but in case this isn't totally redundant already, this whole boogaloo can be avoided with the Little Snitch [obdev.at]. 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 repo
making all the mistakes again (Score:2, Interesting)
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 t
Re:making all the mistakes again (Score:2)
>automagically when the service is turned on.
*Yawn* (Score:2, Insightful)
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
Re:*Yawn* (Score:3, Insightful)
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 m
Re:*Yawn* (Score:1)
Re:*Yawn* (Score:1)
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
Possible reason for absence of destructive exploit (Score:1)
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, appl