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.
Nice fallacy.
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.
Integrate Keynote and LaTeX
Why must every security hole in a non-OSS program turn into a OSS vs. non-OSS debate?
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.
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.
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.
May we never see th
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.
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.
Those who laugh at you for you having a Mac.. are the people who constantly call you to fix their PC.
> On its own, 'disk://' does nothing more than enable the remote mounting of disk images.
The problem is that it does this without user notification and there is not easy way (without third party apps) to disable this.