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

Prove it!

[Bromskloss]

Can you prove ZDNet wrong, or can you show that Mac OS X can really be hacked in less then 30 minutes?

So guys, what do you say? Should we all mabye prove ZDNet wrong by not breaking into that computer?

Re:Prove it!

[CheeseburgerBlue]

The poster then promptly disappeared in a puff of logic.

Re:Prove it!

[Ford Prefect]

I was appalled that someone might have hacked into this machine and thus given the impression that MacOS X was somehow ... insecure, so I hacked into it myself and patched it up with some new security features.

So to anyone wanting to compete in this challenge: sorry. :-(

Re:Prove it!

[mblase]

So guys, what do you say? Should we all mabye prove ZDNet wrong by not breaking into that computer?

Why don't we just do what Slashdot does best, and DDoS the thing instead? The way I see it, that's the best way to protect it from being hacked in the first place.

Re:Prove it!

[Golias]

i think that after posting this story on slashdot, there's really little chance to do anything on the machine for today

The new RTFA: Before complaining of a site being slashdotted, check to see if it's actually... you know... slashdotted.

'cause it's not. It's chugging away nicely.

Go OS X, Apache, and hogging your university's network resources!

A Different Test

[Paradise Pete]

While I appreciate this test, and expect it to not be breached, it is simply not the same test. The original test was to see if a regular local user could elevate its privileges to admin. The fact that the "proof" was to be done by changing a web page is a red herring. The real story was that someone was (apparently) able to do that.

This test is of the web server, and of remote cracking without local access. Also, the explanation page says that the original article did not mention that local access was given. Well, perhaps they've updated the article, but it certainly says so now:

"Participants were given local client access to the target computer and invited to try their luck."

As I said, I appreciate this test, but I am also concerned about the apparent ability of an ordinary local user to gain admin status.

Re:A Different Test

[Yahweh Doesn't Exist]

the point of the original test was supposedly to test OS X in 'server' mode rather than 'home desktop' mode, hence the ridiculous number of open doors. yet even that does not justify a local user account on ssh.

Re:A Different Test

[mekkab]

I think you can't "see the forest for the trees."

The original test was equivalent to saying "I'll let a thief into my house. Let's see if he can steal anything!" Most houses don't have everything bolted down to the floor.

But how often do you allow someone into your machine? For A desktop, not often, perhaps never.

The biggest risk to most computers is a network based attack; this is the real meat and potatoes and a better test of the security of a machine.

Re:A Different Test

[daveschroeder]

Yes, they updated the article.

And the whole point isn't that the test "isn't the same". This is how most Mac OS X machines will appear to outside entities on the internet. The original article - and definitely before it was updated - left people with the impression that a Mac OS X machine could be owned in 30 minutes just by being connected to the internet, without the user "doing" anything, and the subsequent coverage of this in most press proves it. None speak to the fact that a local account was given, or even explore the implications. What could have been a useful article was useless, vague sensationalism. I updated the bottom of the page this morning:

Update

The ZDnet article has been updated to include the sentence, "Participants were given local client access to the target computer and invited to try their luck." But might it not have been interesting to explore:

- What are the implications of local account access, and under what conditions might a computer be used in that way?

- How can such access normally be obtained? Do home users behind firewalls and with no ports open need to worry?
How can a vendor fix the claimed local privilege escalation vulnerabilities when they are not informed of the issue?

- What are the moral and ethical implications of knowing about allegedly severe vulnerabilities in products, like the "hacker" they interviewed, and actively choosing to NOT give the vendor an opportunity to fix the problem(s)?

- How might a Linux or BSD distribution, other commercial UNIXes, or Windows stand up to a similar challenge, where anyone who wishes is given local account access?

- A discussion about how since much of OS X is closed, this might make it more difficult for the community to discover - and report and fix - potential vulnerabilities in the closed pieces

...and things of that nature, instead of leaving people with the impression that any Mac OS X machine connected to the Internet can be taken over in 30 minutes?

Re:A Different Test

[Tim C]

Lots of hosting companies offer ssh access, not to mention that if an account exists on the machine with ssh access, it may be only a matter of time before someone manages to gain access to it.

Re:A Different Test

[Fahrvergnuugen]

The problem is that the media presents the original test as though Mac OSX is insecure out of the box. It's very misleading.

An acquaintance of mine runs a small web hosting company. His original service plan offered SSH accounts to every hosting account. Despite his best efforts to secure the box, it was still rooted by a script kiddie.

His customer's PC was compromised and the ssh password for his account on the linux server was found by the script kiddie. The shell account had access to GCC. The script kiddie logged in as the non privileged user and used gcc to compile a rootkit. The rest was a walk in the park.

The OS was Slackware linux. All of the accounts were jailed, and all of the "best practice" measures were taken to harden the box (I can't comment on every detail as I am not a linux system admin).

My point is that when a malicious user gains shell access to any *nix system, you're in deep trouble.

My friend has since stopped offering SSH access to his customers.

Re:A Different Test

[Paradise Pete]

The original test was equivalent to saying "I'll let a thief into my house. Let's see if he can steal anything!"

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.

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.

Right now we have only this one supposed demonstration of it. What I'd really appreciate seeing is that *original* test repeated. If we can look at this as if it were an experiment, then when someone publishes a result others try to repeat it under the same conditions. They don't conduct a different test with different conditions in order to disprove the original.

Re:A Different Test

[jav1231]

Exactly. If you wanted to truly compare OS X to Windows in this scenerio, put a PC on the Net with TS opened and give out the user account information.

Re:A Different Test

[Anonymous Coward]

"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.

Re:A Different Test

[walt-sjc]

This is quite true. I had a hosting account that did NOT provide SSH access, so I installed cgi-shell and was able to chsh my account to get ssh. Mainly I wanted it to use scp / rsync instead of ftp. Ftp blows.

Re:A Different Test

[Perl-Pusher]

Until you posted this tidbit on slashdot.

Re:A Different Test

[utlemming]

Well it is a "different test" the results could be remoteley generated. But you would have to have a web browser on their end running to get it to work. You simply write a Java program that runs locally on the client machine. When the client machine connects, they download your Java program. This java program then launches SSH (which, BTW, Java can do), compromises the root account, and then downloads a native Mac OS X malware/spyware program. Sure this is a different test, but it does demonstrate that the root account could, theoretically be compromised remotely. The program could even act as a trojan and phone home.

The other thought that passed my mind is that since it is a University what is the likely hood that this Mac is really a Honeypot of some sort? Sure it may be hardened, but they may be trying to figure out how secure Mac OS X is and just trying to get at the ego of hackers.

Re:A Different Test

[Total_Wimp]

How can such access normally be obtained? Do home users behind firewalls and with no ports open need to worry?
How can a vendor fix the claimed local privilege escalation vulnerabilities when they are not informed of the issue?

The answer to the first question is pretty easy. Local access can be gained by the cleaning crew in most buildings, by students in others, and don't forget your friendly neighborhood coworkders. The answer to the second question is just as easy. Spouse, kids, kids friends.

I don't have an answer to the third one, but I know how similar questions get answered when Microsoft is the vendor. The answer is: they have the vulnerability. The vulnerability is bad. They should make a "more secure" operating system.

I think you're attacking the article justifiably, but I think you're also defending the vendor without justification. If they can really be owned by a local user exploit, then that is a serious problem.

TW

Re:A Different Test

[Fnord666]

This is how most Mac OS X machines will appear to outside entities on the internet.

By default web sharing and SSH are not enabled in OSX. You would have to turn these options on explicitly after a normal OSX install.

Re:A Different Test

[tpgp]

For the curious, you can read the article as it originally appeared here

Whilst I agree with you that the original article was a typical zdnet troll attempting to stir the angry mac masses into page views, your statement: left people with the impression that a Mac OS X machine could be owned in 30 minutes just by being connected to the internet, without the user "doing" anything, is not really true if you read the whole article.

For instance, the original article contained the line:

Mac acting as a server -- with various remote services running and local access to users...[emphasis mine]

You also say:- How might a Linux or BSD distribution, other commercial UNIXes, or Windows stand up to a similar challenge, where anyone who wishes is given local account access?

I don't know about Windows / Commerical Unix, but under linux you have the option of using grsecurity to harden against unkown vulnerabilities. Nothing like this exists for the Mac that I'm aware of.

I understand the point of your test - that a mac can sit on a hostile network & not get hacked. But you seem to completely miss the concludion I drew from the outcome of the original test - do not underestimate the seriousness of local privilege escalation.

For instance (as I've written before), an unpatched local privilege escalation, used in conjuction with the vulnerability discussed in this article could result in a rooted machine - simply from visiting a hostile website (or even a website you visit regularly, that runs IIS and has been hacked itself)

Re:A Different Test

[mekkab]

The two things are different. Very different. Quit trying to make analogies with them. Some attempts at home security/compute security analogies are better than others (and this one wasn't one of them), but they're almost always flawed in one way or another.

Thanks for making an assertion without even providing any evidence to support it! ;)

I this case, I think the analogy holds VERY well. Its much easier to defend a single point of entry (or a limited number of entry points) than it is to defend each and every thing that is precious and valuable. In this case, the TCP/IP stack and the the network services that ride on top of them are your "limited entry points"; vs. tying down absolutely every application.

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.)

Re:A Different Test

[Stalyn]

If we can look at this as if it were an experiment, then when someone publishes a result others try to repeat it under the same conditions. They don't conduct a different test with different conditions in order to disprove the original.

Science never enters the picture here, this is a religious debate.

Re:A Different Test

[AKAImBatman]

This is how most Mac OS X machines will appear to outside entities on the internet.

Let me just say, thank you. All these trolls seem to think it's perfectly natural that you'd let hundreds of anonymous users into your system, who's only purpose in life is to compromise one of the hundreds of software packages installed in an attempt to gain higher priviledges. That's just ridiculous. Mac OS X is a desktop system. It is configured as such, and is bound to have problems that could be exploited by a sharp human. (Trojans, worms, and viruses tend to need an exploit that's guaranteed across a large number of systems. This may not be the case.)

If the guy had wanted to test Mac OS X server, he should have run Mac OS X server. Yet even then, there's absolutely no admin worth his salt that would allow shell access to a Unix machine before first performing a full lockdown of the machine. The defaults are never good enough, because the system is still evolving for its intended use. When you're configuring all the services you need, it's always important to set the security to match the level of trust you give the users. In some cases that may mean that you've exposed yourself to potential compromises, but you trust the user (or users) with that responsibility. In other cases, you don't trust the users at all, so you revoke just about every right you can think of.

Or in other words, security is based on trust. Thinking that a system that's intended to trust its users (a Desktop) is going to stand up against untrustworthy users is silly. So again, thank you for trying to set the record straight here. When you're done, we can get the Onion to sydicate the ZDNet article. ;-)

Re:A Different Test

[shippo]

The original machine had had various extra bits of software installed via the Fink project, such as MySQL. The Fink project is very lax at getting updates in place, and there appears to be no specific security policy, particularly if installed from the so-called 'stable' release.

It is entirely possible that one of the pieces of software installed by fink had a root exploit, perhaps using SETUID.

Fink should not be installed on production systems.

Re:A Different Test

[dougmc]

I this case, I think the analogy holds VERY well.

Ok, let's look analogy given :

The original test was equivalent to saying "I'll let a thief into my house. Let's see if he can steal anything!" Most houses don't have everything bolted down to the floor.

And as a reminder, the test allowed users into the box, and they then had to escalate their priviledges in order to alter the contents of the web site.

Specific problems with the analogy?

• The attacker wasn't supposed to `steal' anything. He was supposed to change something that he did not originally have the needed priviledges to do.
• He wasn't even a thief, or even a criminal, as he was invited to come in and do this.
• The attacker wasn't challenged to alter (or steal) `anything' -- he was challenged to alter a specific thing, something that was believed to be well secured. The analogy could be improved by mentioning `stealing a paper in the locked safe in the house', but even that has many of the same flaws of the original analogy.
• Unlike your typical house, properly secured *nix systems DO have everything `bolted down' (yes, it's an analogy, I know.) You should not be able to alter files that you do not own (unless they have permissive permissions, or there's some other mechanism to allow you to alter the file, of course), period.
• The security model of a house is basically `crunchy on the outside, chewy on the inside' -- once you get past the outside security, there is no further security on the inside and you can do whatever you want. While many computer systems do have a somwhat similar security philosophy, *nix does allow you to give users shell access to your box and still keep them from doing certain things, and that is what the test was testing.
• ... and a house isn't even very `crunchy' on the outside. Most houses have windows, and a burgler can get into any house with a window using no special tools in a minute or two -- just break it. The reason that they don't do this more often is that it's likely to be noticed and bring a quick response, either from the police or a homeowner with a shotgun. Adding bars to your windows makes it more difficult to get in, but a few minutes with a socket set would get them removed.

  Compare this to a computer, where an attacker may try to get access many *millions* of times (depends on how he's trying to get in) and unless there is some sort of intrusion detection system running, it's unlikely that anyobdy will notice, and even more unlikely that they'll notice quickly enough to do anything about it. He may also be able to attempt to break into thousands of computer systems simultaneously.

• Generally breaking into a house (or a safe in the house, if you want to use a further analogy) involves doing damage to the house. Breaking into a computer system usually does no damage -- often it doesn't even leave any clues, beyond some possible log messages.
• And then there's the danger to the attacker himself. In order to break into a house, your thief generally has to be physically present at the house, leaving himself open to arrest or getting shot. In contrast, a networked computer is almost always broken into from afar, with the attacker being safe in his house or cyber cafe. If he's extra paranoid, he's even bounced his connection through a few other machines in order to make himself hard to track down.

But yeah, other than that, the analogy holds VERY well. Uh-huh.

If you must make an analogy, don't even use a house. It's a public train station, with no police, and the attacker is challenged to write his name on a piece of paper. But the challenge is that the piece of paper is in a locked viewing cabinet behind bullet proof glass.

... and even this analogy has serious flaws. Here, the attacker has physical access and given enough time could do any number of things

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

[mekkab]

I appreciate your analysis, thanks.

f you must make an analogy, don't even use a house. It's a public train station, with no police, and the attacker is challenged to write his name on a piece of paper. But the challenge is that the piece of paper is in a locked viewing cabinet behind bullet proof glass.

Analogies are indeed a MUST. and M-U-S-T must must must. Sorry, but sometimes you do need to reduce things down to a simplified set.

I liked the "there's a guy you let in your basement, and he's getting into the main part of your house" as an analogy for priv-elevation, but the train station is a nice one, too.

Re:A Different Test

[99BottlesOfBeerInMyF]

The point of the original test was not to hack the machine from outside, but from inside.

True and it confirmed what most everyone already knew, a mediocre cracker can find a local escalation. There is no problem with the original test. There is a problem with the way the media misleadingly depicted the original test. This second test is designed to help debunk some of the FUD generated by the poor media coverage, by replicating the situation they misleading led readers to believe were the conditions of the first test.

Re:A Different Test

[hvatum]

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.

No, the point of the orignal test was to provide fodder for a pointless, sensationalist and outright misleading article. Given the original wording of the article the argument that "your test is utterly irrelevant for the type of people that would be interested in the original one" is patently false. People who were interested in the "original test" would not have even known the original article concerned such a test. The original article never mentioned what was being tested.

This new test has in fact forced ZDnet to change the wording of the article to make clear what was even being tested in the first place. So instead of one useless ambigious article we have two informative tests. The desinger of the second test has done us all a large favor - unlike antagonistic pedants like you.

Re:A Different Test

[asdfghjklqwertyuiop]

The OS was Slackware linux. All of the accounts were jailed, and all of the "best practice" measures were taken to harden the box (I can't comment on every detail as I am not a linux system admin).

Well no, obviously he missed something. It was a walk in the park because he left some well-known vulnerability on his system, possibly in the kernel. I don't think Slackware blows off local vulnerabilities and doesn't bother releasing fixes.

My point is that when a malicious user gains shell access to any *nix system, you're in deep trouble.

No you aren't. There are plenty of companies out there that will grant shell accounts. I grant shells to friends and friends of friends on my own server. There are even places places out there that will give them to the public for free. The key is the system administrator has to know what they're doing and you have to be running an operating system whose designers and maintainers take local security seriously.

It IS doable.

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.

Re:A Different Test

[TheNetAvenger]

Exactly. If you wanted to truly compare OS X to Windows in this scenerio, put a PC on the Net with TS opened and give out the user account information

Not to be an ass, but there are 100s of open accounts all of the internet with TS enabled and client and guest logins allowed for companies to showcase their software.

This is one of the things people actually do with TS is use it for software demonstration purposes, and people are 'encouraged' and 'allowed' to sign into Windows 2003 servers to test software or concepts the companies are selling or demonstrating.

If you think that there are no Windows Servers on the Internet that meet the exact same setup criteria as the MacOSX orginal test had, you really need to get your head out of Steve Job's butt and see what the real world is doing and not just what he wants you to see.

And BTW the same is true for many different OSes and *nix variations, there are 'guest' and local account access for public use, this has been around a LONG time, I don't understand how Mac Users think this is unfair or even unique? What do you freaking think XWindows was designed for? Do you realize that it is used for 'guest' accounts and distributed applications all the time?

As for SSH not 'usually' being open, you would be surprised of the number of people that DO run with either SSH, an XServer or even MS's RDP type of technologies on and enabled, like for example 99% of the Web with headless servers.

If it weren't common or safe, you wouldn't see different OSes have remote 'guest' accounts for customers all over the place.

Here just to demonstrate I'm not making up the remote access account senerio and how predominate it is, do a search on on like Web Hosting, SSH, XServer, RDP(Remote Desktop/Terminal Services) access...

I know of several examples of companies that use Remote Desktop type of technologies (not just SSH) to allow ANY customer to have full login access via (TS/RDP) to Windows Servers to testdrive their software. Do a search on these for yourself to see they exist, I won't post links to watch these companies get /.ed or become a target for attempted hacking.

Re:A Different Test

[TheNetAvenger]

First, my head isn't up anyone's ass. You should really calm down. I responded in spirit in which it was given. Your entire rant mentioned only server OS's. I realize that it's UNIX base makes OSX more like a server but that's really beside the point. How many XP boxen are on the Net with TS opened? AND of all of those TS servers you mentioned, how many are in a DMZ scenerio? How many were hardened?
This test was spun in such a way to make it appear that someone could merely put their machine on the Net and have it hacked. The truth was, there was a remote login opened for the hacker. Was there still an exploit? Absolutely! Should Apple address it? Definitely. But was it a fair and open test? Wait, was the COVERAGE fair and clear? No.


Ok, I actually apologize, as my initial response was to be directed at your comments, but went more into a general rant directed at all the people that don't realize this is more common than they realize and not a biased test of OSX.

So I do apologize for it seemingly be directed at you, when it wasn't after I was done writing.

As for the Unix/OSX debate, this is something you have to give and take on. Mac OSX is not Unix, but a Unix type OS. However, it common in the 'new' Mac world to see OSX in the same class as other standard classic and new Unix OSes. Mac users can't have it both ways, and use this as an excuse when OSX fails to live up to hype that Apple actually generated.

But with that said, WindowsXP (non-server) does not allow a non-administrative level user to use RDP(Remote Desktop), so there is no way to compare WindowsXP in the same scenario, the only commonality here is Windows 2003 server is the 'same code base' as WindowsXP, but does allow guest (TS/RDP) logins, and is something used quite a bit. In the Windows world SSH and Telnet type of technologies are not predominate, so there is not a good comparison here, even though a WindowsXP or Windows Server can be fully administrated using this type of technology.

Oddly, Windows has actually surpassed the 'non-command line' model, and 99% of all remote access and administration is done using a GUI and GUI based tools. (Which is strange as the ease of administration has passed XWindows technologies and even the inherent Mac world technologies for use and management.) - For example, in Windows you don't ever have to drop to a *nix type terminal (or Command Prompt) to change settings or do things locally or remotely, which we are now finding advanced Mac OSX users doing, and are still common in most of the other *nix OSes. XWindows was originally the poster child of a GUI protocol to leave command line usage and administration in the past, and 20 years later, it has been fragmented by its openness to still not deliver this. (Not that openness is a bad thing, but when some standards are left a bit loose, they don't ever get tightened by any leaders.)

You are right about the ZD article being jaded, and I do get it. However, what is being missed here is the article is basically demonstrating OSX is not any better than any other OS, which a lot of Mac and OSX users are finding a slap in the face. Even with OSX abstracting the root from the basic level of user operations, it is not 100%, even though it 'appears' to be, and Apple would love for people to believe it is. Other *nixes do a better job of abstracting User Login levels from root than OSX does.

OSX does well, but it is not perfect, not better than other OSes in this regard and certainly NOT 100% safe, even if permissions have been reduced to nothing. Policy management on Windows can do the same, but it still isn't 100% either.

(And no I am not arguing Windows is one of the OSes that does the root abstraction right, in fact they are the poster child of being the opposite, and this is also the evil double edge sword for MS. Their OS is built upon years of 3rd party application compatibility that allows programs to run unfettered on NT without regard to the NT security system. If Microsoft would have forgone t

Hackorama Windows

[CDMA_Demo]

I wish someone running windows 2003 professional could start a competition like this.

Re:Hackorama Windows

[racebit]

"I wish someone running windows 2003 professional could start a competition like this."

A competition to crack a win 2k3pro server isn't a competition, that's a free-for-all.

Re:Hackorama Windows

[rabbit994]

I'm sure Microsoft has held competion to do so as well. Windows 2003 is pretty secure out of the box as well considering almost no services are in the ON state and it comes with a GUI firewall in SP1. Microsoft has a long way to go but you can't fault them for not trying.

Re:Hackorama Windows

[IflyRC]

Windows 2003 Professional doesn't exist.

1) Windows XP Home

2) Windows XP Professional

3) Windows Server 2003

Re:Hackorama Windows

[evil_tandem]

i actually saw one. and i've tested it myself. i just installed win2k3 on a machine, hooked it up to a t1 and left it for a week (monitoring the traffic). lots of people found it but no one i saw ever got in.

win2k was a completely different story. i did this test with that and people were in by the end of the day.

Logs

[Bromskloss]

Mabye logs could be published (in real-time) so that we all can see some of what possible challengers are up to. That would be interesting.

Re:Logs

[tolan-b]

The logs could be served from another box.

Or perhaps just published after the challenge.

Re:Logs

[kminchau]

Here is a sample log:
2006-03-07 08:21:24 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:25 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:26 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:27 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:27 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:27 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - 72.33.255.254 pawn yo!
2006-03-07 08:21:28 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:29 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:30 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
2006-03-07 08:21:31 66.35.250.150 - 72.33.255.254 80 GET /Default.htm - 200 Mozilla/4.0+(compatible) Referrer - slashdot.org
....

* yawn *

[Noryungi]

I am sorry, but what exactly does this prove? That ZDNet is wrong? That Mac OS X is secure?

It proves neither: every operating system on the face of this earth has been hacked, cracked, and 0wned. Numerous times. Get over it.

Instead of inane, immature competitions such as this one, I'd rather have a nice manual (RTNM -- Read The Nice Manual) on how to improve/lock down an OS X machine. Even better, make that two manuals: one for the average joe, with nice color screenshots for every step that has to be taken, and another for people like me, who manage systems for a living. THAT would be a valuable contribution to the field of computer security, instead of this stupid challenge.

Re:* yawn *

[plate_o_shrimp]

[quote]I'd rather have a nice manual ... on how to improve/lock down an OS X machine.[/quote] There's this..... http://www.nsa.gov/snac/downloads_macX.cfm

Possible Danger

[zaguar]

Email das@doit.wisc.edu if you feel you have met the requirements, along with the mechanism used. The mechanism will then be reported to Apple and/or the entities responsible for the component(s).

With virus/spyware becoming a multimillion dollar business, do you really think that the real hackers (sorry for the use of the term) will stay away from this, due to the this very condition. Do you think that the dangerous exploits and cracks that are, for the moment, unknown by Apple, and are hence, very valuable. They will not be willingly sent to Apple for some minor publicity and no material, no, they will be auctioned off in some sleazy IRC channel in Russia.

the original post

[rayde]

here is the original comment posted by Dave Schroeder about this challenge pretty much posted right after the 30-minute hack article was posted here. I'm actually quite curious whether the University of Wisconsin has approved this whole thing, as I'm not so sure they really wish to have a machine on their networks in the crosshairs.

Re:the original post

[daveschroeder]

Yes, this is approved. But it's getting moved to its own /29 today...unfortunately, that didn't happen before slashdot got to it. ;-)

There is an identical clone of that Mac mini waiting to go on the new network, and our DNS TTL is currently set to 5 minutes, so when the cutover happens, it should be pretty transparent.

Does /. win...

[CupBeEmpty]

...if the little Mac Mini melts from a good /.'ing?

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:Generic smear campaign

[SoulRider]

Um, MS is releasing a new OS this year, arent they?

Hacked Pixel #F0F8FF

[digitaldc]

I hacked in, and in 22 minutes changed one of the pixels from #FFFFFF to #F0F8FF, but it is very hard to tell.
In fact, nobody even noticed.

over 15 posts!

[ikejam]

and noone calls dupe?

http://apple.slashdot.org/article.pl?sid=06/03/06/ 1446207

That.. must be a record.

incidentally the original post seems to reflect a more updated view :-s

The IP

[zaguar]

The IP of the server under the test. Saves you a ping of the site.

128.104.16.150

Re:The IP

[flutkatastrophe]

No No No... it's 127.0.0.1
Hack away...

/obligatory

Hint

[spike2131]

One of the user names is "das".... as in http://test.doit.wisc.edu/~das/

So run that against a dictionary and see if you can get in....

Re:Hint

[artemis67]

DAS is dead!

Long live Vindows!

Re:Hint

[amliebsch]

No, no, no. The password is "boot".

Your wish has been granted:

[daveschroeder]

Corsaire - Securing Mac OS X Tiger

NSA - Mac OS X Security Configuration Guide (not yet updated for Mac OS X 10.4)

Apple - Common Criteria configuration guide

And for the "average joe"?

- Keep your machine patched
- Don't randomly open ports for services you don't use
- Have a personal firewall/router
- Don't run software you don't trust

And this doesn't "prove" anything, except that the initial ZDnet article was totally vague and sensationalistic, making it seem to an average person reading that article that a Mac OS X box could just be "hacked" by being on the internet. That is wrong, and I'm showing that. Simple. It's all explained on http://test.doit.wisc.edu/

Re:Your wish has been granted:

[SolitaryMan]

• Keep your machine patched
• Don't randomly open ports for services you don't use
• Have a personal firewall/router
• Don't run software you don't trust

Excuse me, but an "average Joe" doesn't have to know what any of these words means. Until then, we're bad engeneers.

Re:Your wish has been granted:

[sqlrob]

1) Automatic update is on by default
2) Everything is closed by default
3) Not as important with (2) true
4) This is the big one you'll never get around. People are stupid

Contest closes March 10?

[TheSkepticalOptimist]

So Mac OSX security only works for 3 days, while someone is closely monitoring all web traffic?

If this was a legit challenge, then don't close the challenge. Leave it open, so that when you least suspect it, someone has hacked your site.

But is this challenge stating the security of OSX? Defacing a website is the same as having a Trojan virus installed that wipes out your applications or formats your system? Why not offer a challenge to find out if someone can write a virus that will adversely affect OSX. The delivery is unimportant, as long as there are people happily downloading apps from P2P, opening email attachments, and downloading security updates from email warnings. No OS is truly secure from human ignorance.

I guarantee that some hacker will deface the website, but I question the legitimacy of imposing a time limit on the challenge. Certainly hackers don't have a time limit when they corrupt Linux or Windows based website servers, so why impose one for Mac. I think someone is closely monitoring the challenge website, ready to counter any possibility of it being hacked in order to solidify the OSX security myth.

Re:I'm not sure what the value of this is.....

[emerrill]

The point of this is to see how secure the OS is w/o hardening, and in a more typical networked situation. For that matter they are softening it to attack compared to the stock configuration.

The ZDnet article simply was not reported correctly, and gave the wrong implications. Even with the added sentence, the article tries to make it sound like its vulnerable to remote exploits and you have to be worried about having your machine on the internet.

Easy, To Do

[LifesABeach]

The process is pretty simple, "It's too expensive to compromise the Hardware, but the Humanware; That's cheap, and easy. First your dog/pet/loved is shoot, dead, in front of you. The next comes easier. The gun is pointed at you, and you are given 2 minutes to change the web page to some off topic theme. If you are given an extra 5 minutes, you'll learn Photoshop so that you can put an image of you doing it to a male Shetland pony in front of the members of the supreme court, all looking down on you and smiling in that knowing fashion." The D.O.D. Security Instructor that said this to me didn't even bat an eye; That's the chilling part.

Re:Easy, To Do

[SEWilco]

"...dog/pet/loved is shoot, dead"

• We're talking about a nerd. In Wisconsin.
• You can't hack your own web page in 2 minutes after your computer has been shot dead.

No, you're still wrong about the REAL problem

[xiphoris]

The real problem is that tests like this are garbage in the first place.

In fact, Bruce Schneier (a respected cryptographer, responsible for Blowfish) addressed the topic thoroughly almost 8 years ago in his column Crypto-Gram. Here's a relevant snippet:

You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.

You can read the original here.

Re:No, you're still wrong about the REAL problem

[mattsucks]

Hmmm, just had this thought. If you really knew how to break into the system that was the focus of the $1,000,000 challenge, your best bet would be:

1) Confirm that your hack/exploit really works, but DON'T CHANGE ANYTHING
2) Wait until the contest ends and the system is declared "uhackable"
3) Wait a bit longer until the "unhackable" sytem is adopted by a bunch of big businesses
4) Make a lot more than the original prize fee by pillaging the "unhackable" systems.

oh.... I suppose it should have read

4) Profit!

How unfair!

[Linux_ho]

They've removed the biggest security hole in an OS X system: The Mac User. The Mac User will set "fluffy" as their password, and attempt to install any interesting-looking screensaver that gets e-mailed to them. Not that any other OS would do much better in the face of such adversity. But it's funny that they would use a test like this to "demonstrate the security" of a desktop OS.

Busted?

[jrmcferren]

I think it's done, It now says "Welcome Slashdot" with a link to this page.

Fink could have contributed to the original "hack"

[Been on TV]

One of the unusual things about the "hacked" machine was that Fink was installed. This most likely means that the Apple developer tools were installed (although Fink can install precompiled binaries), making it possible for the hacker to bring his own code and compile on the system. Although Apple ships the developer tools on the OS X client install DVD, it is not installed by default, nor is X11.

Fink lists a catalog of 6359 open source projectsthat can be installed, many of which are tools that could help a hacker exploit a machine or that are exploitable in themselves. Fink is a Debian style package manager for Mac OS X.

Server Version - What would be my favorite vector

[xxxJonBoyxxx]

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]

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.

Doubtful...

[TCQuad]

While you're right on the "das", it's doubtful that a dictionary crack would fix it. Since "das" is also his U of Wisc NetID (ref. the e-mail address at the bottom of the page), it's more likely that the password is the same as his U of Wisc password.

So... Anyone up for breaking into the U of Wisc password database?

Re:Doubtful...

[daveschroeder]

For the record, no, the passwords are not the same.

(And for those wondering, the NetID/username is the non-private part of our NetID credential.)

Also, I'd hope that one would also understand that going after other machines in that way is bad form, and doesn't speak to Mac OS X's security (or insecurity), but rather to the practice of having strong/different passwords across multiple secure systems.

Re:Doubtful...

[MirrororriM]

So... Anyone up for breaking into the U of Wisc password database?

Why try brute force when you can pull a social engineering attempt:

Daer DAvid Schroeoedir,

I am A NIGERIAN PRINCE WHO HACE RECENTLY MOVED TO WISCONCIIN And AM Vary INTERISTED IN OBtaining AN ACCOUINT ON TEST.DOIT.WISC.EDU...i CUULD WIRE YUO 1 MILLION DOLLARS...

Re:Sad.

[99BottlesOfBeerInMyF]

Why is it that the world only considers remote vulnerabilities to be of consequence? Somehow local vuls are now irrelavent[sic].

You're missing the point. This test is not trying to imply that local vulnerabilities are inconsequential, it is trying to undo some of the misinformation that has been spread by the press. The previous test was fine, but the representation of it in the press was that a regular OS X machine put on the internet can be hacked in 30 minutes. This is wrong in many, many ways. Thus, someone made angry by these misleading articles set up a test that is closer to the condition those articles presented and hopefully the press will also report on how misleading their previous reports were. Most of them have retractions or updates up now, but since the damage is already done, this seems like a reasonable solution to me.

Please note, neither of these tests is gathering much in the way of useful information for security people, they are just providing yet more evidence of what most security people already know. A medium competent cracker can find a local exploit for OS X. A really good cracker can find a remote exploit for OS X. If you are going to be giving shell accounts to random people or are likely to be attacked by experts, you should be running one of the secure OS's that uses jails or virtual machines. None of this is news.

This is not about security people though, this is about giving the average person an accurate view of how secure OS X is, without the FUD.

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:Original Test Was More Interesting

[LionMage]

BSD, Linux and even Windows already have patches for NX to contain buffer offerflows, where is Apple on this?

According to what I've been able to glean from Apple's developer resources (available at developer.apple.com), and from various articles about the new Intel-based Macs, the Macs with x86 processors all have chips that support the NX bit, and the NX bit is turned on by default. There is supposedly a work-around to allow you to compile a specific application without the NX bit set, so that the app can execute code on the stack (something that apparently some badly-written apps do). The "work-around" is a compiler flag. Certainly, few or no apps that you download or buy pre-packaged are going to have this bit turned off... unless you manage to download a trojan.

I don't recall whether or not the PowerPC ABI allows so-called stack trampolining (executing code on the stack). I know some compilers took advantage of the ability to execute code on the stack to implement certain language-level constructs, though at the moment I'm drawing a blank on the specific ones; regardless, you can implement such features without resorting to executing code on the stack.

I do recall, however, that the PowerPC ABI gives preference to argument passing through registers, whereas the x86 ABI requires passing arguments to functions on the stack (because the x86 has far fewer registers). This is one reason why PowerPC Macs are less vulnerable to buffer overflow / stack based exploits.

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!

Don't play this down

[kestasjk]

Don't play this down, this is a serious flaw. UNIX security is all about user accounts; if a UNIX based system can't enforce user accounts its entire security model is useless.

Just because a vulnerability is 'local' doesn't mean you have to be sitting at the computer. Take the U of Wisconsin's honey pot box running Apache and ssh. Both Apache and ssh run in a lower privileged user account whenever they can, so that if there's a flaw in code which runs in the lower user account it can only do damage within that lower user account.
Right now if you found a hole in low privilege context code you could use it to get admin access in OS X; this is a serious problem and it makes the UNIX security model, which Apple gives as the reason for OS X's great security, useless.

This doesn't mean OS X is insecure and everything else is, but it is a very serious flaw (especially being unreleased) and I don't understand why everyone is downplaying it.

Re:Don't play this down

[mythz]

How can we take this seriously. No one know how the exploit was achieved, what services was left open and what was installed on the target machine.

The target machine as far as we know does not represent any typical OSX installation. So this exploit has not made a OSX user's typical desktop installation any less secure or a typical Internet any less secure webserver, as it would not have had the same settings.

The fact that the result of the exploit has been published without any information relating to how the exploit was done and what tools were used renders this article a bad PR Stunt.

Re:Don't play this down

[Anthony]

I can't believe this comment is at -1. Apple have been slack with responding to local vulnerabilities. A former colleague spent a day and found 5 in OS X. reported them all to Apple and never heard from the company again.

A more "real-world" test?

[redmoss]

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?

Data General used to Boast

[Greyfox]

That their B2 secure version of UNIX was so secure that you could safely post the root password on the Internet. I always thought that was rather disingenuous seeing as how pretty much every UNIX I've worked with required additional configuration to enable remote root logins, but root never had much power on those systems even if someone did find a third party server (or telnetd *cough*) with a possible exploit.

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.

And yet companies do it

[Sycraft-fu]

I host on a company called Pair (www.pair.com), as do many others including major sites like Tom's Hardware. It's all UNIX hosting, FreeBSD specificly, and you get SSH with all but their most basic accounts. Somehow, they are able to do that, and not get their shit rooted all the time, or indeed ever that I'm aware of.

Still no comparison

[massysett]

Lots of hosting companies offer ssh access, not to mention that if an account exists on the machine with ssh access, it may be only a matter of time before someone manages to gain access to it.

True, but this test still does not compare to what hosting companies are doing. Web hosting companies are (hopefully) run by professionals who secure the boxes. Web hosting companies run operating systems like RHEL that were designed for server use--Mac OS X on a Mac Mini was designed for home use.

Most importantly though, hosting companies are not giving ssh to any anonymous joe off the street, which is exactly what happened in this contest. At a minimum, web hosting companies have your credit card number before they offer you ssh. Some will demand additional information, such as a faxed copy of a driver's license. Of course a crook can get a drivers' license and a stolen credit card, but these are additional hoops to jump through that make the process of cracking the machine that much more trouble. Plus, if someone does crack the machine despite his lack of anonymity, the hosting company might be able to track him down.

This contest as reported on ZDNet was a joke. The guy gave ssh accounts to anyone who asked for them, without demanding any proof of identification. He ran it on an OS that was not designed to be run with untrusted users logged in. Furthermore, the crack was done by an anonymous person using an "undocumented" security hole, which to me calls the credibility of the whole episode into question. In what real-world situtation does anyone allow ssh login to any random, anonymous Joe?

Re:Still no comparison

[kaffiene]

The reality is that a user was able to elevate their permissions to root - that's a security concern and ought to be pointed out as a weakness. It would be a weakness if it happened on Windows or Linux, it doesn't become a non-issue because fan boys think that only web security is important.

The fact is *all* security gaps are important. If there's a network hack that can only get you a non-priviledged account, but you can then jack that up to root access using this local hole, then that hole was mighty significant. This whole "Mac has no security faults" meme is dangerously delusional. It's significantly more secure than Win32, but at least own up to faults (small as they may be) and get them fixed, don't bury your heads in the sand.

Re:Still no comparison

[guet]

The fact is *all* security gaps are important. If there's a network hack that can only get you a non-priviledged account, but you can then jack that up to root access using this local hole, then that hole was mighty significant. This whole "Mac has no security faults" meme is dangerously delusional. It's significantly more secure than Win32, but at least own up to faults (small as they may be) and get them fixed, don't bury your heads in the sand.

Have you read the page at http://test.doit.wisc.edu/ ?

He doesn't say it's invulnerable, and he doesn't say the local hole is unimportant, just that it's unimportant to desktop users (which it is), and applicable only to servers giving out ssh accounts. At present there is no network hack that can get you a local account, and most desktops wouldn't even have the services he has turned on enabled. Once something has a local account, you can only try to contain it, and for most desktop users it's game over, as it has access to all their files, address book etc. The worst hole so far has been due to Apple's stupidity in adding a feature to open downloaded files automatically to Safari, allowing trojans an easier route to trick users.

I haven't heard anyone say 'The Mac has no security faults', almost everyone here will readily admit that it has faults, and the stream of security updates from Apple attest to that. What people do say is that it's fairly secure, and more secure than Windows, by design.

I find it interesting he took the test down so quickly though, it's almost as if he was worried : )

Re:This whole thing is bogus.

[aurum42]

You are incorrect--the release version of OS X for Intel does support the "NX" (no execute page protection mode, and by implication, PAE) feature, and has stack pages marked NX by default. Get your facts right before bloviating, troll. I believe, but am not sure, that the G5 equivalent is supported as well, but given the architecture+ABI differences, it's somewhat less vulnerable than x86 to stack smash style vulnerabilities.

CNet

[aclarke]

I think much of the fault lies at the feet of ZDNet/CNet. They'll write anything to get page views. It doesn't matter if a piece on their site is entirely non- or anti-factual as long as it inflames enough people to read it out of pure disgust.

I'm still subscribed to some of their newsletters, where they email me about what this or that person has "blogged" on their site recently. I guess if you call it blogging then you don't have to do any journalism, but they'll have two people playing off both sides of an argument so so we'll keep clicking and ringing their page count up.

I think the best solution is to ignore them so they'll go away, or otherwise to make sure you make judicious use of Adblock.

Mac Mini Survives Slashdotting

[Anonymous Coward]

I love how the mac mini is surviving the slashdotting no probs. Sure its mostly text, but I've seen similar sites crumble in no time.

http://test.doit.wisc.edu/

Chris

Re:This whole thing is bogus.

[aurum42]

Try again troll. See Apple's documentation

Intel processors include a bit that prevents code from being executed on the stack. On Intel-based Macintosh computers, this bit is always set to On.

You must work for that Eweek rag, you appear to follow the same brand of FUD-spreading methodology, involving outright lies...

Rereading the original ZDNet Article...

[podperson]

It appears that the original article has been changed since originally posted. It currently reads:

"On February 22, a Sweden-based Mac enthusiast set his Mac Mini as a server and invited hackers to break through the computer's security and gain root control, which would allow the attacker to take charge of the computer and delete files and folders or install applications.

"Participants were given local client access to the target computer and invited to try their luck."

Other related blog entries have noted the update.

Even so, the article fails to mention that this vulnerability relies on extra work on the part of the system administrator to create the accounts and open ssh.

Yes, Sponsored by University of Wisconsin

[TubeSteak]

http://apple.slashdot.org/comments.pl?sid=179501&c id=14866581

by daveschroeder (516195) on Tuesday March 07, @10:44AM (#14866581)

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!

No +1 Informative for you.

try it for Windows or Linux...Re:A Different Test

[javaxman]

Right now we have only this one supposed demonstration of it. What I'd really appreciate seeing is that *original* test repeated. If we can look at this as if it were an experiment, then when someone publishes a result others try to repeat it under the same conditions. They don't conduct a different test with different conditions in order to disprove the original.

What I'd like to see is that same test repeated for Windows, and maybe even Linux and Solaris... and OpenBSD. Now *that* would be interesting.

Guess what? I'm going to wager that all of those systems are prone to some sort of privilege escalation attack. ( actually, I don't have to guess, just check out CERT on this one. )

Are you trying to say WindowsXP or Linux is more secure when it comes to privilege escalation attacks than OS X ? Somehow, I'm tempted to think all of these systems have issues in that area. I'm not saying it's good, and I definitely won't defend Apple's somewhat lax approach in this area ( especially regarding the holes they've put in their security via LaunchServices and SystemStartup ), but uh... you should be fair, I think. It's not like a WindowsXP box, or even a Linux box, would last much longer if you just *gave* everyone user accounts on them, or ran software of questionable origin. That's just not something safe to do, regardless of what system you're on.

Now, if your intention is simply to point out that Apple's systems aren't any more secure than anyone else's in terms of this kind of attack, then you have a good point, one that Apple and their users both need to listen to and act upon.

Re:Why encourage hacking?

[Cid Highwind]

"This is almost like someone wants to destroy the smug "unhackable" world that Mac users live in."

Exactly. Antivirus and firewall vendors want Apple users to pay for their "solutions" to problems that don't yet exist, Windows and Linux fanboys want Mac zealots to feel the pain of spyware infestations, insecure default configurations and constant brute-force attacks on open ports, and the tech press likes negative reporting. We're seeing the collision of many interests creating a huge storm of hype around some minor flaws in OSX security.

Re:try it for Windows or Linux...Re:A Different Te

[Paradise Pete]

Are you trying to say WindowsXP or Linux is more secure when it comes to privilege escalation attacks than OS X ?

How could you infer that from what I wrote? I never once mentioned any other OS. I have little doubt that XP is less secure, but that's not the issue. Up until a few days ago, no one was claiming to be able to escalate user privileges under OS X. Now someone is claiming that. And if it's true, it's a problem not to be taken lightly. And if it can be done programatically, then it's a very serious issue.

For what it's worth, I don't run XP. I don't run Linux. I run OS X, and I've done so since it first came out. And I ran Mac OS 9, and 8, and 7, and 6, and even had a original Mac with only a floppy drive. So I'm not looking to bash Macs. In fact, my friends who I drive nuts with my "Mac talk" would laugh at the idea.

But that still doesn't mean this is a trivial issue. And it doesn't really matter that's it's "less bad" than XP. I take that to be a given.

Why Dave Schroeder is wrong (and MSFT is right!)

[ichin4]

It's certainly true that the original ZDNet article was sensationalist and overly alarmist about the implications for Mac security. But by implying that the original contest is irrelevent for a typical Mac user and that his test will prove that Macs are secure, Dave Schroeder is being equally, if not more, misleading.

The original test showed that Macs are vulnernable to local privlege escalation. It is true that most Mac desktops users are not offering accounts to external users. But a great many of the attacks out in the real world today are luring attacks, where a local user is tricked into running an executable with his local user permissions. The original test shows that such a executable can successfully elevate its privliges and own the machine. This is very relevent to the typical Mac desktop user.

Dave's new test doesn't have a user on the machine randomly surfing the internet and clicking on any link that says "get yer naked pics here"! Instead, as he freely admits, he is really just testing apache and ssh security, which are rarely turned on a typical Mac desktop configuration. Of course, were a hacker to exploit a vulnerability in one of those services, he could presumably use the same privledge escalation attack that was used in the original test to own the machine.

One of the more interesting ideas about how to deal with luring attacks has actually come out of the Microsoft .NET Framework. In its security model, the permissons of on application don't depend just on the user that's running it, but also on the origin of the application, as defined by a signed certificate. This system has the potential to greatly improve security, but sadly most Windows applications are not yet managed, and most Windows machines are not yet configured to strictly limit which managed applications are allowed to do what.

Re:try it for Windows or Linux...Re:A Different Te

[javaxman]

javaxman: Are you trying to say WindowsXP or Linux is more secure when it comes to privilege escalation attacks than OS X ?

Paradise Pete: How could you infer that from what I wrote? I never once mentioned any other OS.

Precisely, you never mentioned any other OS with regards to privilege escalation attacks... and you'll notice I was really just _asking_ if you were trying to imply something about another OS, so actually, I didn't infer it as much as I wondered if you meant to infer it.

I have little doubt that XP is less secure, but that's not the issue. Up until a few days ago, no one was claiming to be able to escalate user privileges under OS X. Now someone is claiming that. And if it's true, it's a problem not to be taken lightly. And if it can be done programatically, then it's a very serious issue.

Um. Ok. Here's the thing: just about every form of *nix under the sun has had a history of problems with privilege escalation. Go to this CERT document and search for "elevated privileges"... as just one example of how widespread and ( fairly ) well-known this type of problem is. While you're there, note that OpenSSH is what OS X uses. I'm sorry that you ( and apparently a lot of other people ) weren't aware of this as a problem, and usually such attacks are fairly difficult and too obscure for most people to do, but... they are a real problem, and always have been.

For what it's worth, I don't run XP. I don't run Linux. I run OS X, and I've done so since it first came out. And I ran Mac OS 9, and 8, and 7, and 6, and even had a original Mac with only a floppy drive. So I'm not looking to bash Macs. In fact, my friends who I drive nuts with my "Mac talk" would laugh at the idea.

Well, consider for a minute then that OS 9 has pretty much *no* such concept as privileged and unprivileged users... it does have some user restrictions, but they never worked terribly well in part because they weren't implemented by much more than the Finder and system services. Would you have given someone an account on your OS 9 machine if you didn't know who they were? I doubt it.

But that still doesn't mean this is a trivial issue. And it doesn't really matter that's it's "less bad" than XP. I take that to be a given.

Yup... definitely not a trivial issue. Definitely an issue that Apple ( and, clearly, developers and system designers in general ) would like to ignore... because it's complicated and restricts what you can do. Apple needs to step up and treat privilege escalation as a more serious threat than it seems they have in the past. Hackers need to step up and do the right thing by reporting these problems when they find them. But most importantly, users like you and I need to remember that there is no such thing as giving someone "safe" access to your machine... if you're going to open up SSH or any other avenue that could be used for attack, do it carefully, check out OpenSSH CERT reports, and remember that you're not invulnerable, no matter what operating system you're using. They have not built an unsinkable ship, nor have they built an operating system that you can give someone "some" ability to directly execute arbitrary code on. You might think OS 9 did that, but it didn't- it made it really, really hard to execute arbitrary code from anything but the console, but once you were a user, it was easy to do whatever you wanted. OS X is an improvement on that, really... even *if* you give anyone who wants one a login account and ask them to own your machine. And it's definitely an improvement on WindowsXP, though I do wonder if OpenBSD or something might be more safe.

It really is like locking somone in the garage or basement and daring them to get into the rest of the house. If you actually *want* to be safe, you'll lock them out at the gate outside your house, and not let them in where they can start to attack through the drywall.

MiniSlashdotting

[EigenHombre]

Am I the only one who is impressed that a single PowerPC (not multi-core Intel) Mac Mini can survive a slashdotting? (Not to mention the additional DoS attacks -- and with rather zippy response time to boot.)

- Former Badger, glad I ordered one of those new MacBooks

Test Now Closed

[themadplasterer]

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.

Contest Over! Winner Announced

[bugnuts]

Yesterday we discovered the Mac OSX "challenge" was not an activity authorized by the UW-Madison. Once the test came to the attention of our CIO, she ended it. The site, test.doit.wisc.edu, will be removed from the network tonight. Our primary concern is for security and network access for UW services. We are sorry for any inconvenience this has caused to the community.

The CIO of UW-Madison has managed to get test.doit.wisc.edu website defaced.

UPDATE on the contest

[EvilStein]

Just in case and of you dumb fuck "Macs suck" knuckle draggers are wondering, It's over. U of Wi pulled the plug.

38 hours and not one successful crack.

Mr "Mac OS X is so insecure" didn't even manage to get in.

http://www.technewsworld.com/story/49296.html