Slashdot Mirror
Origins of Mac OS X's runscript Security Hole
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.
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.
*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...
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 which is a neat (and missing) preference pane anyway.
With the steps above taken and P.A. installed I opened the sample exploit by the P.A. author (also linked from his white paper 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.