Pressing Ahead With The Mac Security Topicby
Scores of readers have chimed in on yesterday’s column in which I suggest that Apple might find it useful to appoint some kind of “security Czar,” not necessarily because I think Apple is having trouble with software security per se, but because there’s a lot of talk and confusion about security on the Mac these days, and that it might help to have an authoritative voice coming from Apple on the subject.
Still there’s an important discussion to be had. Whenever this subject comes up, I get batch of email from folks who insist that unconditionally, the Mac has absolutely zero security vulnerabilities and that even raising the subject is a ridiculous waste of time.
But then I get some very informative feedback. Consider this observation from Rick Downes who in looking at the “rm my Mac” challenge which raised so much ire among Mac enthusiasts this week, makes an important observation:
“The two things you do when you plan in intrusion on a Unix computer are 1) Get in; and 2) Get root. In this case root was hacked in 30 minutes.”
More after the jump.
Downes goes on:
“You can't get away from this. Mac users don't see this because Apple computers are so seldom used on a large scale in corporations. Yet the number one threat anywhere is still the 'inside job,” that is, someone working late at night, and someone who already has an account.”
In short a scenario in many respects similar to the “rm my Mac” challenge, the only major difference was that the attack was carried out remotely, rather than by someone with physical access to the machine.
This challenge, he says, wasn’t about testing OS X on the Web, he says, but rather about specifically testing its resistance to privilege escalation vulnerabilities, which allow someone with a normal user account to trick the system into granting them higher levels of access. Google the phrase "privilege escalation vulnerabilities" and you find a lot of them.
Based on what we know about this the "rm my Mac" case, when judged against the yardstick of how difficult it was to get root, this particular Mac didn’t do so wel. This presumes that the entire thing isn't fiction in the first place, and given that the details of the exploit used haven't been disclosed yet, we should all remain appropriately skeptical.
For some context on these privilege escalation vulnerabilities, Dominique Brezinski, a security researcher at Black Hat whose former employers include In-Q-Tel (The CIA’s venture capital arm), Amazon and Secure Computing Corp. points out that even though he “loves my Macs, I don’t for a minute believe they are secure computing environments.”
“In fact, OS X has had vulnerabilities in standard BSD Unix utilities that were fixed in Free/NetBSD five-plus years ago. … OS X has no core OS level defenses against buffer overflow exploitation (such as non-executable stacks, heap control structure integrity checking, separation of writeable and executable memory regions, etc.) nor semantic containment technologies such as AppArmor (Suse), SELinux, GrSecurity, or systrace (Net/OpenBSD). The reason there are not exploits for OS X coming out daily is not because the vulnerabilities are not there, but rather because not many people are looking.”
Additionally, he pointed me to www.osvdb.org, the Open Source Vulnerability Database, which lists many vulnerabilities in the Mac, some old, some new, some fixed with software updates, some apparently not. See for yourself.
When tell me they’ve had “zero security problems” with Mac OS X, I take them at their word, because a comment like that is based on their own anecdotal experience. But this doesn’t mean there aren’t vulnerabilities lurking that can’t be exploited now, and it doesn’t mean there isn’t the potential for trouble in the future.
Computer security isn’t a one-time event. There is no magic lock you can put on a computer that will keep the bad guys out once and for all. That said, Apple’s record here is generally very good. But as any first-grade teacher will tell a class full of six-year olds, there is always room for improvement.
This is a discussion that needs to continue, and I'd like to invite even more feedback from you.