eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
So, MacDefender.
To hear some people go on about it, you’d think it was the end of the world. Not hardly; but it does raise some interesting questions.
The first has to do with the way it seems to spread. Search poisoning isn’t exactly a new tactic, but it’s shaping up to be an effective way of spreading malware. So much of the anti-malware effort has gone into e-mail-based delivery that we’ve forgotten about user conditioning; people assume that because it showed up in a Google image search that it must be safe.
How MacDefender and its offspring including MacGuard do their voodoo is pretty simple; here’s a video clip from ZDnet’s Ed Bott that shows what the user sees.
On a more technical level, there’s the question of why Mac OS X allows this sort of thing in the first place. Jason Brooks and I have been bouncing this topic off of each other for the last couple of days, and even though we come at the problem from different perspectives – just as my platform of choice is Mac, his is Linux – we agree that Apple’s placing too much trust in the good intentions of the developer.
In short, Apple allows developers to select one of three kinds of authentication when they create an installation container. (I use “container” in this discussion because “bundle” and “package” have very specific meanings in Mac OS X installation procedures.) As the documentation says, they range from “moot to root.”
The simplest level of authentication is “none at all” and doesn’t require any authentication from the user. The second – or “administrator” – only prompts for an admin password if the user running the installer isn’t a member of the Administrators group (501). The third – “root” – requires a password no matter what the user’s privilege may be.
The problem with the way these authentication levels are used is that Mac OS X has been designed by Apple to place the selection method for installer privileges in the hands of the developer. This is fine when all of your developers have pure intentions, but as MacDefender shows us, that’s simply not the case. If anything, this scheme flies in the face of the concept of “least privilege” and ignores the hard-learned lessons of computer security that have emerged over the last 30 years.
The only case I can see for justifying the “no authentication needed” option would be for a security update that is signed by Apple and is distributed through Software Update or Apple Remote Desktop. Nothing else out there – be it an update to iTunes, Mac OS X or any other piece of software – should be running without a basic level of user authentication.
As for the so-called “administrator” authentication – better thought of as “admins are trusted” authentication – that should be restricted to a limited assortment of whitelisted applications and vendors. Applications that are sold through the Mac App Store would certainly qualify, as would anything signed by Apple, Adobe, Microsoft, and other big-time players in the Mac ecosystem.
There should be no way for a Joe Developer to create an install container that requires anything less than what Apple calls “root” authentication. That would solve the problem of MacDefender and similar attempts to subvert the security model.
Apple has a golden opportunity to clean up its approach to installation security with Mac OS X “Lion,” which is due out later this summer, and which will be previewed next week at Apple’s Worldwide Developer Conference here in San Francisco. It may be too late to make a change this drastic in Snow Leopard 10.6.8, which was slated to be the last update to the 10.6 release train; but this improvement in the security model would justify a 10.6.9, if only for the sake of users who won’t be jumping on the Lion bandwagon right away.
There is one behavioral fix for this problem: until Apple addresses this situation proactively – beyond the reactive patch it served up yesterday, that is – one could always try using a limited-privilege account for day-to-day purposes. That’s a recommended best practice on any operating system, but one that’s not terribly common in Mac OS X or Windows, where the first user created on a system is by default the administrator. That said, to be honest, most people aren’t going to do so, and I’m at the front of that list. Call it stubbornness, call it insanity, call it what you will; it’s going to take a lot more than one genus of malware to get me to change my ways.