« ARD is not Citrix | Main | Microsoft Office 2004: The MacBU Strikes back »

By the way, this one really is a debacle. No, really. I've yet to see where it's been overblown at all. This is a "Perfect Storm" - ish situation, where you have separate problems come together in a way that makes them just...amazingly worse than they would otherwise be. There are a number of good articles on this, so I'm not going into the exploit itself. My personal favorite at the moment is John Gruber's two articles on this at Daring Fireball.net. You can read them here and here. John does a solid job, so I don't see a point in repeating what he said. If you subscribe to the MDJ, they have a fantastic article on it as well. (Disclaimer: I do help out at the MDJ on many things, so I'm biased).

But what i do find fascinating is the process behind this, especially because preventing this is pretty simple. [Speculation Alert! From here on out, I'm hypothesizing, and could very well be wrong, but I don't think I'm too off the mark.] This situation really strikes me as what happens when you:

Have a lot of teams working without really talking to each other
People creating network applications that aren't being vetted by a team of security - conscious assholes

Now, by "assholes" I mean a group that lives in fear of no one and whose reason for existing is to take really good ideas that involve networks and like a pack of wild monkeys, throw crap at those ideas. If any of the crap sticks, the idea needs to be redone until it's more teflon than Reagan. Because none of the contributing factors are bad ideas, they're just ideas that missed the right kind of eyes.

For example, the disk: URI concept. Okay, at first glance, it's really cool. It allows for the remote mounting of a disk image transparently. Wow, that's pretty cool. I mean, it can make things like backup and restore pretty sweet. The problem is, it's too transparent. It allows you to mount remote disk images without any warning that this is about to happen. No "You are about to mount a disk image that resides on a remote machine, this could be a security hazard, do you still wish to do this?". No "The web site "H@xx0rz& 'R' U$ wants to mount a disk image named "PWN3D!!!LOLOLOL", do you want to allow this to happen?". It's automatic, transparent, convenient, and a great enabler of evil.

One of the problems with trying to remotely hack a machine is location. Oh sure, with Mac OS X, /Library/StartupItems/ is not only in a consistent place, but allows you to create startup items that run as root without any sort of need for root access, since it's writable by any administrator on the box. And you can assume with POSIX paths that "/" is always the startup disk. But still, sometime you need to be able to assume where you're starting from. Well, thanks to being able to mount an image remotely, you know where you are: /Volumes/Imagename. So if you are running a script that needs to copy files, it now has a source and a destination, always good to have.

Now, there are times when you need password-less remote image mounts. Like when you're booting from an OS install CD to use this function. Still, you can manage having two levels of operation in that case. Just simply requiring a modal dialog in those cases would have done much to mitigate this. You'd still have the convenience, it just wouldn't be as transparent. If you went to a (supposed) game cheat site, and all of a sudden you get dialogs about an attempt to mount a disk image, that would indeed raise an eyebrow, and prevent things from happening before you could stop them.

The other major case here is that the Help Viewer can run any AppleScript anywhere regardless of context. So I can hack say, ecto's help files to run AppleScripts that have nothing to do with ecto. If I'm running as an administrator, my reach gets a LOT longer.

There's a couple of ways to deal with this without killing the help system's ability to do its job. The first is that Application - Specific help can ONLY run scripts that are local to the help system. That is, if script is located outside of the help file's directory, it cannot be run by the help for that application. Yes, that may be a bit of a pain for developers, but not hideously so. As well, why would say, Preview's help need to run a script in /System/Library/whereever/ anyway?

To quote Johnnie Cochran, It Does not make Sense.

Secondly, if the help URI is being invoked from a non - local source, pop a friggin' dialog. Why does a remote web site need to run my help viewer? It does not make sense In fact, just disallow this completely. I can't see any bloody reason for a remote site to run my help viewer. If it's just HTML anyway, you could just oh, USE A WEB BROWSER! I hear they're kinda good at that. Those two steps right there would make the help viewer useless for remote attacks.

Oh yeah...hey guys, John's new rule of the Internet: There are NO safe files. This idea that there are somehow, some kind of magical safe file formats that can't be used for evil is stupid, and needs to be expunged. Just remove that entire concept from Safari. Download yes. Auto-open without manual initiation?

Hell.no.

But if you look at the problems here, none of them are inherently bad ideas. They just aren't anything that an IT asshole would allow. But then, programmers aren't IT assholes. They aren't even close. They're programmers. They're very good at it. IT assholes are very good at what we do. We aren't programmers. You can't expect anyone to be perfect at anything. I mean, even IT assholes specialize. There has to be a group that looks at stuff as a cracker would. From the point of view, "How can I do evil with this?" That's the only way.

Obviously neither disk: nor help: are supposed to be evil, but they are able to easily be used that way. What I would hope is that Apple doesn't get all ego-y about this and hires an internal "Goon Squad" to go around and fling evil crap everywhere until the teflon coatings are in place. For everything. That will prevent this kind of shit from happening again, and it's the only way to prevent it.

I would also add my voice to the chorus asking Apple to be far more open where security issues are concerned. If someone reports it, communicate for Pete's sake. Ask them to work with you on it. Don't just say "Okay, we'll take it from here", and expect the person who reported it to go away. The Big Daddy Apple attitude won't cut it in the world of security. It may with the MacMacs, but as a rule, security people aren't MacMacs. They're pros, they want to see things done right. But if you won't talk to them, they'll happily go public, and they won't give a rat's ass if you ban them from the WWDC, MacWorld, or your granny's birthday party.

Apple needs to communicate better here, it's a major problem. Don't be making Microsoft's mistakes here. I imagine the fix for this will be out soon, if not soon enough for some. There's a number of ways you can protect yourself in the meantime, I urge you to avail yourself of them. (except for the one where you try and change or delete 349 script files. that one's real dumb, and doesn't really fix much.) Hopefully, Apple learned a lesson from this, because they got really lucky this time. I would hope that's not a strategy.

Comments