Apple: Inside the cult

Mac Bots Attack!

There's news today that "the world's first Mac botnet" is in the wild. It's been followed by the predictable "see, I told you so" and "yeah, well it's only the one," with a side of "it's not a virus, it's a trojan" pedantry. As Brian Krebs (yes, that Brian Krebs) pointed out in the Washington Post, this isn't really a new issue. It's a flare-up of the low-risk iServices trojan that rode along with some BitTorrented versions of iWork and Photoshop back in January. The botnet is apparently attacking a site called Dollar Card Marketing, which sells business cards that look like money. Really.

Now, it's true that this isn't a virus. You don't get it by merely running a vulnerable system on the net. You have to download it, give it elevated permissions, and run it. It is, in short, a piece of user-installable software. And so long as you can install software on your computer, whether it's a Mac or a PC, problems like this will exist. It's important (in a bad way) that people are now targeting this stuff for Macs, but it's always been a possibility.

What interests me are the steps Apple might take to limit these threats without totally compromising ease of use. Mac OS already asks you if you want to open a port in your firewall when a program requests it, and that's a start. But how many people, especially the relatively untrained users who are the target of these attacks, can accurately evaluate whether iWork (for instance) should be allowed to accept network connections or to access the network at all? Seems suspicious, sure, but a lot of programs (and more every day) have networked components.

Here's one idea. Signed binaries already exist, and they'll be a bigger deal in Snow Leopard. What if Apple shipped a list of known-good applications with information about the network access or other special rights they might require. So long as they ask for that and nothing more, the user doesn't see anything at all. If the app asks for more than the baseline, or if it isn't signed in the first place, the user sees a confirmation prompt the first time (or maybe the first few times) the app runs. Not perfect by any means, but it would cut down on extraneous prompts and focus more suspicion on the ones it does generate.

What say you?

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world