Slashdot Mirror
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
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.
"But how often do you allow someone into your machine? For A desktop, not often, perhaps never."
But for a server, all the time. If you're considering a timesharing system, there may be thousands of users. The central ITS computers at every university I've been to (the ones you SSH to, and run Pine to check your email) have thousands of user accounts. Everyone at the school has one. (An older book, but still a good read about the important of priviledge escalation bugs - look for "The Cukoo's Egg")
Now you can argue that you're only giving accounts to people at the university, and they're trustworthy (or at least you can punish them if they try to crack the server). But out of ten thousand accounts, someone's going to have a guessable password. Or they'll answer a phishing scheme. Or (if you let people put CGI/php scrips on their webpages) someone will write a buggy script. Or your SSH/web/ftp daemons will be found to have a bug (don't know what Apple's using, but OpenSSH/wsftpd/apache all have bugs in the past and are likely to still have some bugs).
Now, I run linux at home because I need something which plays well with the network. I can log in remotely, run programs, upload and retrieve files, etc. I tend to find the distinction between "desktop" and "server" blurs, because I want to be able to access my computer from anywhere.
win2k was a completely different story. i did this test with that and people were in by the end of the day.
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.)
The server appears to be Apache 1.3.3.3, one version behind the current release. The 1.3.3.4 release has a fix for this item, which would be my favorite vector, but I doubt that this server has an application that uses chunked encoding (often used for file uploads).
*) SECURITY: core: If a request contains both Transfer-Encoding and
Content-Length headers, remove the Content-Length, mitigating some
HTTP Request Splitting/Spoofing attacks. This has no impact on
mod_proxy_http, yet affects any module which supports chunked
encoding yet fails to prefer T-E: chunked over the Content-Length
purported value. [Paul Querna, Joe Orton]
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.
In the future, I would want to not be isolated from my friends in the Space Station.
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.
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!
It seems to me that tests like "remote break-in using ssh" are not as good of a fit to today's common home computing environment. For something like OS X, most home machines probably are not running any services, so it is rather pointless to try to break into them using standard ssh/http attacks.
I would prefer to see test break-in attempts set up like this:
an unprivileged "test account" is created on OS X and set up with email, web browser, and other common desktop programs
the "test account" is set up with several common methods of communicating with the outside world: email, IM, commonly-browsed web sites, webmail, banking sites, etc
the test account's email address and IM account are made public to the would-be attackers
someone regularly checks the test account's email and acts like a "gullible user" would, eg click on spam and phishing links, go to hostile web sites, follow dubious instructions received via IM from supposed friends
the challenge: attacker must be able to do something "bad": control box resources (think spyware), steal critical system information (think remote root), get bank account information (think phishing), whatever
A few years ago, this was trivial on Windows. I hear they've cleaned up their act to some extent. How well would OS X hold up? How about a standard desktop version of Linux?
Then IBM bought Data General and that was the last we heard of DG/UX B2 Secure. Pity really. They should have ditched AIX instead. But I digress...
OSX is pretty damn secure right out of the box, but Apple could do more to make it tighter by default. They've already managed the security versus usability balance far better than Microsoft has managed so far. I think Apple could push a little more over to the security side of the thing without noticably affecting usability. I also think that Apple users would accept slightly less user friendly systems in order to continue to walk around with that air of I-can't-get-spyware-or-virusses smugness that no Windows user will ever understand until they've seriously used an Apple machine for a few days. Apple's selling more than a machine. They're selling the ability to not have to live in fear every time you connect that machine to the Internet. They're selling the ability to not have to run so many third party security applications that the shiny new machine runs like a shiny new machine from 5 years ago. I think that is worth any percieved price premium.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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:
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'
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.
Dewey, what part of this looks like authorities should be involved?
- Former Badger, glad I ordered one of those new MacBooks
EOT
The test is now closed and there were no sucsessful security breaches. This proves what most of us already knew about Mac OS X .This is take directly from the site http://test.doit.wisc.edu/
Mac OS X Security Test
Tue 7 March 2006 11:59 PM CST (8 March 2006 0559 GMT)
The testing period is now closed.
The response has been very strong, and the test has illustrated its point.
Traffic to the host spiked at over 30 Mbps.
Most of the traffic, aside from casual web visitors, was web exploit scripts, ssh dictionary attacks, and scanning tools such as Nessus.
The machine was under intermittent DoS attack. During the two brief periods of denial of service, the host remained up.
The test machine was a Mac mini (PowerPC) running Mac OS X 10.4.5 with Security Update 2006-001, had two local accounts, and had ssh and http open with their default configurations.
There were no successful access attempts of any kind, including during the 38 hour duration of the test period, nor have their been any claims of success. The host is still the same host and configuration used for the test.
Some snippets from 7 March 2006:
The site received almost a half a million requests via the web.
There were over 4000 login attempts via ssh.
The ipfw log grew at 40MB/hour and contains 6 million events logged.
Several social engineering attempts were received, including one purporting to be from the government of Sweden, which apparently uses GMail. ;-)
More test results and information will be published here at a future date.