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.
software update (Score:2, Informative)
Parnoid Android (Score:5, Informative)
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:software update (Score:5, Informative)
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].
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...
Re:software update (Score:2, Informative)
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: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.
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 trick to prevent one from deleting their whole directory by accident.
If the attacker can't use command-line args, you're probably OK there:
If the attacker does "rm *" in your $HOME, yes, a file called "-i" could save you. None of these would be stopped, though: rm -rf
Another method is to have "alias rm rm -i" in your
Everything *you* run in an interactive csh or tcsh has that run first. If a malicious program is run through
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.
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.