Origins of Mac OS X's runscript Security Hole 63
ahknight writes "codepoetry has an informative article about why there was a runscript command to begin with, where it came from, and how it's still used. A good read for people wondering why the command existed at all. Also, Daring Fireball has possibly the best solution so far with instructions on how to turn off the help and disk protocols entirely (much better than deleting random system components)." Update: 05/21 22:27 GMT by P :Daring Fireball also mentions an abuse of the telnet: handler that can overwrite any file you have write permissions to, and doesn't need a known path. There's also an applescript: handler, which I'd disable just for the heck of it, at this point ... Update: 05/21 22:36 GMT by P : Several readers note that Apple has just released Security Update 2004-05-24, which address the runscript problem, though apparently not the others.
Re:HA (Score:5, Interesting)
Image a virus that infects Word documents at a large organization that goes unnoticed for a year because it doesn't actually do anything but replicate itself quietly and subtly, and infects any document it can over the course of the year. Slowly, all the backups of files will be infected as well. It doesn't have to do anything malicious, just prevent a document from being viewed or opened easily.
Every place I have seen Office being used, there are huge volumes of files which everyone can share and update. Boom! Nobody can do anything with the information they have because Office won't work....
errrrm.... wait. I see the flaw in my argument. Office does that all on it's own already.
Re:HA (Score:5, Insightful)
I know of a small pharmaceutical company whose product database is kept, and updated to frequently, in a MS Word file of all things. No CVS, no MySQL. A Word file!
The potential disaster there is terrifying, to say the least.
Opensource Linux vs. OS X security (Score:1, Troll)
If the Help Script vulnerability was within closed source code, does it imply that OS X, with it's use of Apple closed source on top of FreeBSD, is less secure than other 100% open source OSes? Has a definative security comparison between Linux and OS X been done? (How about one for XP vs. OS X vs. Linux for that matter?)
Re:Opensource Linux vs. OS X security (Score:5, Insightful)
In short, no it doesn't.
Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.
There have been security holes from boneheaded design decisions made in various components of Linux before, a single security hole changes nothing nor tells us anything about the relative security of the two systems.
Re:Opensource Linux vs. OS X security (Score:5, Insightful)
While you are technically correct, I believe that you are being misleading. I have the *potential* to be safer running in front of cars than staying on the sidewalk as well -- the issue that most people would be concerned about is what your chances are.
I think that there are few cryptographers that would trust an unpublished algorithm -- many of us do not trust unpublished code.
That doesn't mean that published code is automatically safe -- just that there are more grounds to trust it.
I agree with you that this hole is not an open-source vs closed-source issue (the problem was in design, and enough of the design was available that someone who wanted to identify this could have done so), though I do think that decision decisions like this remind me more of desktop than traditional *IX developers.
Re:Opensource Linux vs. OS X security (Score:3, Insightful)
The fact of the matter is that security holes can happen anywhere. It doesn't matter if the code in question is OSS or non-OSS. All that matters is that the problem gets fixed.
And don't even start the "if it was OSS, we would have caught it earlier" argument. There have been plenty of holes in OSS that were not noticed for a long time.
Re:Opensource Linux vs. OS X security (Score:3, Funny)
Re:Opensource Linux vs. OS X security (Score:2)
I think that if "a definative security comparison" were possible, OS distributors would run them and then fix all the holes found. There's no way at this point to perform such thorough testing on systems so complex. Meaning no way to list all the things to test for, and no way to test them all before the technology is obsolete.
If you disagree, you have found a very good career. (If only disagreeing with
software update (Score:2, Informative)
Re:software update (Score:5, Informative)
Re:software update (Score:2, Informative)
Re:software update (Score:1)
I also ran the Security Update from Apple, and then tried Unscanity's example. For me, it DID work. I've got a text file in my home directory to prove it...
Are you sure the disk image downloaded quickly enough for the refresh to execute it?
Re:software update (Score:1)
Re:software update (Score:2)
The issue is fixed by disabling Open Safe Files and the disk:// protocol, not by Apple's SU. There are rumors that other volume-mounting protocols are also succeptible to the attack (ftp://, afp://, smb://, webdav://, others?)
Re:software update (Score:1)
Parnoid Android (Score:5, Informative)
Re:Parnoid Android (Score:2, Informative)
I tried their demo page after Apple's update and sure enough, a nasty text file was written to my home directory.
Paranoid Android not good for my mom (Score:5, Informative)
Paranoid Android does not "protect" against anything, it just lets the user decide which URL schemes he wants to allow and which he doesn't, on a case by case basis. But not everyone is an IT professional and knows by heart which protocols are good and which are evil. My mom doesn't. So, is there a workaround that doesn't involve P.A.? I think so.
I can see three different (but related) issues here:
- The "new and unknown URL scheme" issue exploited by malicious applications in downloaded and mounted disk images. Avoid this by not allowing disk images to be mounted automatically. You have to disable "Open Safe Files" (to avoid mounting disk images downloaded over http) and the disk: and disks: protocols. Having to mount all disk images by hand requires a decision from your side and gives you time to think about what you are doing.
- The "help://runscript" issue caused by the Help Viewer accepting arbitrary commands. Disable the help: protocol, who needs it anyway?
- The "telnet://-nfoo" issue caused by telnet's ability to overwrite existing files. Disable telnet:, ssh exists.
Correct me if I'm wrong, but with those protocols disabled I can see no way for the malware to get its stinky little bits on my harddrive.To disable the protocols I used RCDefaultApp [rubicode.com] which is a neat (and missing) preference pane anyway.
With the steps above taken and P.A. installed I opened the sample exploit [geekspiff.com] by the P.A. author (also linked from his white paper [unsanity.com] if you're paranoid which would seem normal under this circumstances). P.A. nicely asked me for permission, first for disk: and then for malware:. I granted both permissions, but since I had disabled the disk: protocol the image was never mounted and nothing happened.
Now, installing an additional prefPane and disabling individual protocols is not exactly an easy one-click workaround for my mom, but it would be possible to guide her through the process on the phone, and after that she would leave me alone
But then again, I still have some hope in Apple releasing a Security Update which is more convincing than the one they just released. With flaws that serious, I expect a bit more than just the replacement of one application which is obviously only part of the problem.
Re:Apple posted Security update for this (Score:2)
-B
Re:Apple posted Security update for this (Score:2)
Yep. no such problems here. The install went smoothly and it now says I'm up to date.
Re:Apple posted Security update for this (Score:1)
NOW? (Score:2)
URL handling still has "remote code" exploits! (Score:5, Informative)
yikes! Make sure you turn off "open safe files" in Safari (or the equivalent in your browser), and also disable the disk:// protocol, until this is resolved!
Re:URL handling still has "remote code" exploits! (Score:4, Interesting)
Re: URL handling still has "remote code" exploits! (Score:1)
Disks can be automatically mounted through the 'disk://' URI handler. You should download RCDefaultApp and disable the handlers for 'disk', as well as 'ftp' and 'afp'. Oh, and 'telnet' as well, since that one is not safe too.
At least until Apple comes up with a proper security patch.
Jaguar Update (Score:1)
Some notes (Score:5, Informative)
Some reports describe this as also a vulnerability with the 'disk' URI handler. This is incorrect. There is no vulnerability in the 'disk' URI handler; however, it could be used in conjunction with the 'help' vulnerability to deliver malicious content. On its own, 'disk://' does nothing more than enable the remote mounting of disk images. It was this capability combined with the 'help' vulnerability's ability to run arbitrary code at a known location that made it dangerous.
Also, reports have also described this as a vulnerability in Safari, Internet Explorer, or other browsers. This is also incorrect. It was a vulnerability in the way Help Viewer handles 'help' URI requests passed to it by the OS.
Last, there seems to be a misunderstanding that this vulnerability requires the OpnApp.scpt helper script within Help Viewer somehow. It does not. However, OpnApp.scpt, combined with the help URI handler vulnerability, could be used to execute some arbitrary commands. But "exploiting" it actually just comes back to general help URI handler vulnerability, now fixed.
That said, this was a very serious exploit...probably the first major (potentially) easily exploitable vulnerability for Mac OS X.
Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...
Last, the telnet:// "vulnerability" isn't really a dangerous one, since it can only overwrite files (not directories) with a known name and path that you have permission to, and only one file at that. Yes, yes, plenty of preferences and maybe even some really irritating things like your iTunes Music Library database file. In any event, this definitely should also be fixed.
Re:Some notes (Score:5, Informative)
It's not clear from your writing if you realize that there is another similar exploit that has not been fixed yet. Malware writers can invent their own URL protocols and LaunchServices will automatically register them on mounted volumes (e.g. through disk://, and maybe also ftp:// and afp://). In other words, the same kind of exploit is possible without HelpViewer, for details, see this link [unsanity.com].
Re:Some notes (Score:2)
Is having the URL type in an info.plist enough?
You can disable the disk: and disks: url handlers with the Default Apps prefs pane. I don't want to post a link to slashdot though. Use Google.
I don't want Apple to disable the ability for apps to create their own protocols just because some malware some stupid user downloads might make use of it.
Re:Some notes (Score:1)
Re:Some notes (Score:1)
In other words, a classic Convenience versus Security issue.
Re:Some notes (Score:2)
There is no way to exploit this if you disable auto-mounting of disk images on download and the disk:/disks: protocols by with the default apps prefs pane.
If Apple does release a patch to deal with this, I hope it only performs a check to see if the disk/disks protocols are called from the internet and provides a warning/confirmation dialog as the user if
Re:Some notes (Score:2)
Re:Some notes (Score:1, Insightful)
The problem is that it does this without user notification and there is not easy way (without third party apps) to disable this.
Re:Some notes (Score:1)
If you did the chmod fix, the download from software update will install -- but SU won't recognize that it has done so. That's what happened to me. Disk Utility's "Repair Permissions" fixed the changed permissions, and then all was back to normal.
Apple Download Page (Score:2, Informative)
The safety of many URI protocols may be in doubt (Score:4, Informative)
I posted this late to the earlier discussion about this hole, but chances are not many people saw it. Looks like I'm not the only one thinking this now though, so why not post it twice...
It occurs to me that the help:// URI protocol problem could be broader than is generally being portrayed so far.
Consider: the fundamental issue here is that an OSX web browser -- Safari in the original reports, but apparently also Mozilla etc -- is acting as a broker for any URI that the user may come across, delegating the request out to external handler programs. Whether those external programs handle their URIs safely may be an open question.
The problem isn't really that Safari or Help is broken, but that the interaction between them, arising from the URI handling mechanism on OSX, is leading to Unintended Consequences.
OSX can handle many different URI namespaces, some of which seem to be used nowhere other than OSX. I'm having a hard time finding an exhaustive list of the URI protocols that OSX supports, but a partial list [macosxhints.com] includes, in no particular order:
So far, I can think of published vulnerabilities in the telnet:// and now help:// protocols [and this article expands on those points], but is that the end of it, or is the whole framework vulnerable to these sorts of attacks?
I have a hunch that we're just seeing the thin edge of the wedge. If that's the case, then a real fix is going to hit a lot of the system, which in turn will mean that Apple is going to have a hell of a time doing proper bug testing on whatever fix they come up with. And if that is the case, then the patches we see for this through Software Update seem likely to be partial, possibly unreliable or ineffective, and may lead to system instability. (I'd hope that isn't the case, but if the fix has to be at some fundamental level of the UI then it can't be ruled out.)
It may be that we don't see a true correction to this situation until at least the next 10.3 point release, if not 10.4...
telnet bug was fixed as well (Score:5, Informative)
*snip* *snip*
There was no disk:// hole (though it was used in conjunction with help://) and telnet:// is fixed as well... nothing else to see here... move along...
Apple Patch 2004-05-24 ? (Score:2)
KDE (Score:3, Interesting)
As much as love to mock OS X (Score:5, Informative)
Like OS X, Windows allows applications to create their own protocols. You can make an "irc://" protocol (and many applications do) or an "outlook:" protocol (as Outlook does) or many other protocols.
The risk with OS X (and Windows) is that one of these protocols is registered to an application with a security flaw.
Windows has had this technology since 1995; I don't know how long the functionality has been in Mac OS but from the looks of things it seems to be relatively new (perhaps it was introduced with OS X?). Apple has to get the bugs shaken out of the built-in applications. 3rd party applications also present a danger, but it is less (it is more difficult for an attack to work when it relies on a specific non-standard application).
Internet Explorer (on the PC) has one of the most unique security models of any browser. IE has multiple security "zones"; it is possible to set the security settings for files on your intranet to be different from the security settings on the general internet (similar to having different users for different pages). Unfortunately, this also carries a risk: flaws in IE have lead to "cross zone" scripting which allows privelage elevation. IE SP2 a completely new zone system which is supposed to prevent this, but only time will tell if it is truly effective.
Re:As much as love to mock OS X (Score:1)
Re:As much as love to mock OS X (Score:2, Funny)
Apple Computer on Friday issued an update to Mac OS X to address flaws
that security firms said could allow malicious code to be run on a Macintosh.
From the sounds of this NEWS.COM release, it sounded as if Apple blocked the ability to execute future Windows emulators...
Modest security threat (Score:3, Informative)
http://bronosky.com/pub/AppleScript.htm [bronosky.com] Only runs "du" command.
1) To have the maximum potential you need to be running as admin user, not standard user. I encourage everyone to be standard user when they run their computer. I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident. Another method is to have "alias rm rm -i" in your .cshrc or .tchrc environment configuration.
2) A malicious website would have to be catered specifically for Mac users and have them navigate to this website by clicking on the link. Most serious threats on the Windows side comes from you having your computer simply being plugged into the network. i.e. worms. I would classify this more under the realm of a Trojan Horse, which requires some trust on the users part.
3) One can kill the unix terminal with in seconds of it launching. The script doesn't and can't surreptitiously launch in the background. You can actually see the script and terminal run in front of you.
Re:Modest security threat (Score:3, Informative)
That aside, further nitpicking:
I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix tr
Switch (Score:2, Funny)
Re:Switch (Score:1)
I'd also like to point out... (Score:5, Informative)
http://www.obdev.at/products/littlesnitch/
when i tried to run the example hack on the Paranoid Android site, Little Snitch warned me that I was trying to mount a remote disk image which i was able to cancel.
apple patch servers DOS? (Score:1)
Also, their main web site is pretty slow/hurtin.