U of Wisconsin's Mac OS X Security Challenge

digitalsurgeon writes "The University of Wisconsin [ed: Go Badgers] has launched a Mac OS X Security challenge, in response to a 'woefully misleading ZDnet article'. From the site: 'The challenge is as follows: simply alter the web page on this machine, test.doit.wisc.edu. The machine is a Mac mini (PowerPC) running Mac OS X 10.4.5 with Security Update 2006-001, has two local accounts, and has ssh and http open - a lot more than most Mac OS X machines will ever have open.' Are you up to the task? Can you prove ZDNet wrong, or can you show that Mac OS X can really be hacked in less then 30 minutes? More information about the challenge is at http://test.doit.wisc.edu/ The challenge ends Fri 10 March 2006 10:00 AM CST." Update: 03/07 14:32 GMT by Z : Commentary on the contest and original claim is available at VNUNet

Comments

Generic smear campaign

[catwh0re]

I've noticed a significant rise in anti-macosx articles recently. To the point where I'm beginning to believe that it is staged. Each article usually has 3 points to make: Mac OSX is not *nix, Max OSX is insecure and "easy" to hack (and not a target due to small install base.) and that Apple are slow with patches to security faults.

So far each article has been based on unique situations that lack credibility to begin with, give little detail, and take focus away from the fact that it's basically a machine running a collective of industry proven software (such as apache and openssh.)

Also of note is that Mac OSX currently has an a user base of over 10 million machines. So the argument that it's too small a target is ridiculous. In fact it's a bigger target as it's untouched territory with a bonus of headline making news.

Re:A Different Test

[daveschroeder]

I say that on the actual site itself:

Mac OS X is not invulnerable. It, like any other operating system, has security deficiencies in various aspects of the software. Some are technical in nature, and others lend themselves to social engineering trickery. However, the general architecture and design philosophy of Mac OS X, in addition to usage of open source components for most network-accessible services that receive intense peer scrutiny from the community, make Mac OS X a very secure operating system. There have been serious vulnerabilities in Mac OS X that could be taken advantage of; however, most Mac OS X "vulnerabilities" to date have relied on typical trojan social engineering tactics, not genuine vulnerabilities. The recent Safari vulnerability was promptly addressed by Apple, as are any exploits reported to Apple. Apple does a fairly good job with regard to security, and has greatly improved its reporting processes after pressure from institutional Mac OS X users: Apple is responsive to security concerns with Mac OS X, which is one of the most important pieces of the security picture.

The "Mac OS X hacked under 30 minutes" story doesn't mention that local access was granted to the system. While local privilege escalation exploits can certainly be dangerous - and used in conjunction with things like the above Safari exploit - this isn't very informative with regard to the general security of a Mac OS X machine sitting on the Internet.

Of course, I'd have no problem with this if the original article had actually talked about it meaningfully in the context of a local privilege escalation and explored the implications; instead, they just made it sound like you could throw a patched OS X box onto the internet and it'd get owned. The average reader would leave with that *distinct* impression, and most of the subsequent coverage of it talked about it exactly in that fashion.

Mac OS X has had several local privilege escalation vulnerabilities, just as other OSes have had. Apple fixes them when they become known. (Also, and this is another discussion, but what can Apple do if the "hacker's" claims are correct, i.e., that the vulnerability is unknown to Apple? It doesn't prove that Mac OS X is "insecure"; all it "proves" is that open scrutiny is difficult with closed source pieces, and that some people intentionally and knowingly refuse to give vendors a chance to fix problems.)

Much better analogy!

[mekkab]

I don't think that analogy is quite apt. It's more like locking someone in your basement and they figure out how to gain access to your whole house.

Okay- I like that analogy better. I've got deep deadbolts on my outside doors; the door between my basement and house has a cheap handle lock that can be popped with a long, thin screw driver.

Not to get lost in the analogy details, but I think you'll find most security skews the same way.


When I run a third party program I am essentially letting them inside, but as a non-priviledged user I'm confining them to a specific area. But if this ability to elevate privileges turn out to be a fact, then any program I run can have full access.

I think this ability to elevate privs should be analyzed on a case by case basis for all programs; as such if you are concerned about what applications a user can and can't run, remove the ability to run those applications from the machine.

However with most desktop machines your biggest worry isn't normally* an attack from within; its usually from without.

*)people on slashdot aren't normal and typically have needs that extended beyond normal users. Feel free to contribute some examples that counter this assertion.

Original Test Was More Interesting

[adam1101]

Actually, I think the original test was more interesting than this one. For years we've read countless +5 Insightful posts that OS X is more secure than Windows because normal users run in restricted accounts by default. That trojans can't do anything to the system unless you're "stupid enough to type in your password". If the original hack was indeed an exploit of an undisclosed buffer overflow, it means that this argument is pretty much moot. There have already been lots of posts in this and the previous article that amounted to saying "a local exploit is no big deal, everybody has them, if you have local (restricted) access you should be expected to be compromised anyway". Are these posters saying that the supposed advantages of restricted user accounts on OS X are very overrated? Are they saying it's no big deal if the next social engineering attack is combined with a buffer overflow exploit, meaning no popups asking for your password?

If the original hacker Gwerdna (Andrew G?) was right that there are many undisclosed priviledge escalation bugs, that is a case for concern, not something to be dismissed as a mere "local" vulnerability. BSD, Linux and even Windows already have patches for NX to contain buffer offerflows, where is Apple on this?

I think that, especially if you're an Apple user, it is very important to test the claim that the OS is rifle with local priviledge escalation issues. And that's why I think the first test was much better than this one. I don't expect this U of W box to be hacked anytime soon. But this proves very little. You can even setup a Windows SP2 ISS+Remote Desktop box like this, and I don't think it will be hacked anytime soon either. But if you redo something like the original box (give normal user ssh accounts to anyone) and get hacked very quickly again, it proofs a lot. Namely that the local security measures of OS X that many have come to thrust amount to very little.

Re:Our tax dollars at work

[daveschroeder]

No, my position is not funded or "rewarded" by Apple.

Also, I can't say I've *ever* gotten a "freebie" anything from Apple in 22 years other than a couple of T-shirts. Oh, and a nice pen once. I've also never heard of anyone in enterprise or education getting free flat panels and iPods from Apple (except for the free iPod promotions they've had when people buy certain laptops).

Also, since Mac OS X is used *heavily* in education, particularly at large research universities, and diversity of computing platforms is important to avail faculty, staff, and students of the best resources to do their jobs, I'm sure many are interested in the general security of a typical Mac OS X machine with a couple of typical services running on the internet, especially in the wake of such misleading press coverage of the same. The only interests I represent are those of the University of Wisconsin - Madison.

And yes, this challenge is sanctioned. I'm glad that the University of Wisconsin supports the genuine interests of its faculty, staff, and students, and encourages individual thought, research, discovery, and exploration. That's why it's a great place to be!

Re:A Different Test

[ScriptedReplay]

*sigh* are you guys hopeless? The point of the original test was not to hack the machine from outside, but from inside. All the noise about Windows getting hacked 4 minutes after it was connected to the net was due to lack of firewalling and vulnerable services - turn on firewalling and the vulnerable services are no longer accessible. What does that prove? nothing - they didn't magically become secure. OSX probably has fewer vulnerable services (active or not) but that was not the point.

The point is even with proper design of user separation, local security is hard to get right. Every OS has this problem, to various degrees. And if you want a sample of what this type of problems mean, here is one: malware will not be required to ask you for a password to elevate privileges - see? all those 'this is not a virus, it asks for your password and that should set your alarm bells going' argument goes puff! in smoke. This is the same type of issue that plagued non-administrator users in Windows for a long time now. So let me put it this way:

1. Local privilege escalation is bad - and hard to prevent (see all the attempts done by other OSes - NX, canaries against stack smashing, grsecurity, PAX, load address randomization and so on)
2. Local privilege escalation to root is really bad. There are precious few places where one should have to look for things that run as root. Most of them are in the default install. And the worst that can happen is a kernel-level exploit, as that would be likely to affect OSX Server as well, which is far more likely to be used in a multiuser setup.

So, to come back - your test is utterly irrelevant for the type of people that would be interested in the original one. What you are trying to test is the security of the OpenSSH and Apache installs + your setup (yeah, and password strength - expect to be hit by automated dictionary attacks from scripts that couldn't care less about your test). If I had an XServe machine with several users having ssh access I would really want to know whether any of those users really can get root on the machine or not (if they can, XServe has no place in such enviroment). And I would be really worried. As it stands, I still have worries, but at least I know that I have a certain amount of protections in place against such problems (this not being OSX though - no OS names since I'm not interested in 'my OS is more secure than your OS' flames) But this is a real security concern and yet you turn around and say 'but these other things are secure.' Yeah, the article could have sounded misleading for anyone not willing to check the site and see the conditions (but few people would do that anyway) but how are you any better? All this is countering journalistic sensationalism with more of the same, since your box is neither set up as a home user's nor your setting is pertinent to the original multiuser problem.

To toss in my 2c of an analogy - the original test was to check whether a bank's employees (with access to the bank building) can empty the main safe to which they do not have the combination[*] while yours is to check whether a customer can; all this on a Sunday when the bank is closed.

And now mods feel free to mod me down - although a more rational answer would be welcome.

[*] to all those saying 'by dfault root is not even enabled in OSX': bah! 'enabled' pertains to login and privilege escalation couldn't care less about login restrictions; the account is still there. And in fact, the thing that 'get root' means is 'get uid=0 access'

Re:A Different Test

[Just Some Guy]

all of the "best practice" measures were taken to harden the box

No, they weren't. If all the filesystems that customers have write access to are mounted "noexec", then self-compiled binaries don't present a lot of exposure.

I'm not saying that it's not a good idea to remove GCC, just that its presence isn't an automatic compromise.