1. When it comes to security, from the point of view of an OS vendor, if you have gained unauthorized access to an interactive shell on a target machine it's already "game over, man". You cannot protect against physical access, and you can pretty much assume that there are a plethora of unknown privilege escalation bugs so that any account is effectively a root account. Every company has limited security resources, and at some point there are trade-offs between usability and security. This is why efforts are typically focused on keeping the baddies out.
Once the bad guy gets in, you can only mitigate potential harm. This is the goal of things like File Vault (which will still protect your stollen laptop, assuming you put on a screensaver password). This is also why merely being able to change a password is not nearly as bad as...
2. Being able to recover the plain text of a user's password. I'm not going to discuss how or why, but this was possible on earlier versions of OS X and fixed only in Lion. In this regard, "cracking" passwords is much harder on Lion than it was on Snow Leopard and earlier.
Of course, that sort of level-headed approach to this kind of topic seems to be rarer and rarer on HN these days...unfortunately...
Think of any system as a castle. Having access to an interactive shell is like standing outside the King's bedroom. Sure, you might not have the keys to the bedroom door, but you've already made it past the archers, the moat, the drawbridge, the boiling oil, and the King's personal body guards. You don't put a 3 ton door on the King's bedroom and say, "Well, that should keep the invading army out!"
No, you strengthen all of the defenses leading up to the door so you never have to worry about just how strong that door is. That's not to mention that the King probably doesn't appreciate having to swing a 3 ton door every time he wants to go to sleep.
Same idea with computer security. Only give accounts to trusted individuals. Assume anyone with an interactive shell can quickly gain root access. Physical access is even worse. If you can sit at the keyboard, then you control everything. This is why most banks have key servers locked in real physical vaults with 3 ton doors.
Honestly, I'm a little surprised. This is all "Computer Security 101" level stuff here. Getting worked up about "cracking" passwords given local access is akin to worrying about someone spying on you when you visit this site: http://www.josephcrawford.com/2006/11/11/scary-isight-trick/ . If you want some real security research meat to sink your teeth into, the pwn2own contests are always pretty good, especially the most recent one (http://arstechnica.com/security/news/2011/03/pwn2own-day-one...). You might notice, if you read about the pwn2own contest, that the contest is over as soon as the exploit runs arbitrary code on the local machine and successfully breaks out of the application sandbox. At that point, you're knocking on the door...
That an attacker has physical access does mean that your computer is compromised, so you're half right.
If you seriously think having an account on a machine is as good as having the root account, then you should call up every shared hosting provider and let them know. They hand out accounts to any asshole with $10.
jballanc didn't say you can't guard against privilege escalation. He said, assume you can't. The point is subtle but important: given limited resources, you should allocate the majority of them to keeping the hacker off your system in the first place.
I'll leave it as an exercise to the reader to compare and contrast the entirely different use cases between a shared hosting server and a desktop machine running OS X.
I can create an account on the machine without having root access. Which gives me a shell. Which means I can exploit a flaw to change root password. Which means I have access to cookies and other fun things. Which means I can probably access that person's gmail which is pretty much game over, man.
Bedroom analogy is wrong. The computer is the castle. They have it. The problem is that your lord knows the secret entrance to your main castle (in the cloud). You want one of two things to happen: Keep the lord safe, or kill the lord so his secrets are gone with him. The attacker formatting the machine, or replacing the hard drive is fine, he already physically has it, just like he can take the vault and throw it outside and make a new one. However you don't want him accessing that vault.
He means "any account with local access" is effectively a root account, which is true. Resetting passwords is trivial when you can reboot and have an install disk.
You can also just boot your Mac in single-user mode (Command-S), then mount the main filesystem and type "passwd bob". Much easier and produces the same effect.
That risk level is not at all on par with this though. That won't help with filevault turned on, and it requires both a reboot and a physical presence at the machine. This can be done remotely with shell access, and discloses hashes from other accounts.
Enabling Open Firmware password protection disables the ability to boot a Mac into single use mode; it also disables booting from an external hard drive, flash drive, etc.: http://support.apple.com/kb/HT1352
Unless the Mac has a firmware password. You could just remove that by resetting the PRAM, unless you wanted to go undetected. In that case, you could remove the hard drive, mount it elsewhere, and change the password hash. Is FileVault plus a firmware password the only safe way to keep your Mac?
FileVault by itself is sufficient, at least with Lion. Even if you're able to boot the machine or mount the HD, you'll need the user's original password to decrypt the data. The Password Reset app is useless until you first unlock the encrypted drive.
(I'm pretty sure that pre-Lion's FileVault is in the same case, where you'll still need the user's old password to decrypt their home directory's encrypted dmg, but I'm not 100% certain.)
In the article, it mentions that the password are hashed using SHA-512. As has been mentioned before, using such a fast hashing scheme for passwords is a terrible idea. Any idea as to why they do it this way? (instead of using bcrypt)
Apple uses a key strengthening algorithm on their passwords, similar in concept to Bcrypt - I think they've increased the number of rounds past the 1000 mentioned since this paper came out: http://people.cis.ksu.edu/~sakthi/src/data/filevault_sakthi....
If you've already compromised an account and have access as that user, it's likely that what you're going after isn't going to be their password...
... although, if you were to nab the password file and their keychain file (which contains passwords to other accounts that they access) which is generally encrypted with the same password (the system nags you if it's not the same), you could potentially do some real damage.
It's bad, but it's not that bad. SHA is widely supported, and not that bad, yet.
Also this is protecting desktop computers, where cracking hashes is not a common security problem. Getting the machine stolen in starbucks is probably much more common for this type of machine.
Most everybody uses some form of slow hashing. Bcrypt is a particularly secure and convenient form of slow hashing, which is why people recommend it so much, but there are other schemes possible. For example, you can take a cryptographic hash function and iterate it a few thousand times.
You're using an apple product. When did they ever claim to be secure? Your life is easier, more magical, full of glass, and very fast! Security is... a little bit of whipped cream on top. So enjoy your gestures on that magic touchpad, don't worry about being safe.
Apple doesn't ignore security, they advertise security enhancements in their products:
"Address space layout randomization (ASLR) has been improved for all applications. It is now available for 32-bit apps (as are heap memory protections), making 64-bit and 32-bit applications more resistant to attack."
"Application sandboxing protects the system by limiting the kinds of operations an application can perform, such as opening documents or accessing the network. Sandboxing makes it more difficult for a security threat to take advantage of an issue in a specific application to affect the greater system."
Erm... I forgot I was in a place where preemptively apologizing for making a joke isn't enough for people to think you're joking.
I would like to point out though, that the text you just copied are pretty much apple's only words on the topic.
To further my joke even more:
Google search for "easy" on apple.com [1] returns 3.3 million results.
Google search for "secure" on apple.com [2] returns .5 million results.
On the internet easy returns 3.6 billion results, and secure 1.25 billion. So on the apple site, you would expect easy to show up 3 times as much as secure. In fact, easy shows up over 6 times as much as secure.
This definitely proves apple cares about security only half as much as the rest of the internet does!
I downvoted not because you joked, but because you made patently untrue claims and then backed them up with a very poor methodology. So poor that you can't simultaneously be smart enough to read and understand this site and dumb enough to think it's logical to argue this way.
I wasn't talking about the downvotes, that's to be expected. I was talking about the humorless replies :)
If we all acted our IQs, all the time, the world would be a very boring place. It's not responsible to buy myself expensive toys, it's not respectable to be sarcastic. Yet we do it anyway.
Trolling is meant to make people angry, I meant to to get a chortle out of at least somebody... but now I know, beyond a shadow of a doubt, that this is not the site for that. Thank you for helping me realize it.
Joking is fine -- as long as you make a point and contribute to the discussion. Throwing out some one-liner about Apple security is not a valuable contribution, and then yes, your jokes weren't funny either.
This feels a little bit like a naughtily published zero-day exploit.
I'm disappointed the post doesn't mention any appropriate disclosure to Apple prior to publication. Sure, it's not an out-right crack of the shaddow password algo but this vector could still be used in damaging ways.
Compensation is irrelevant - if you bothered to sniff around a specific vendor's security and you discover an exploit then you really should disclose it. Such is the lore of white-hatism.
Sure many don't do the above, but the OP author is presenting himself as white-hat/legitimate.
And as informed users, we should consider carefully giving our business to vendors who don't go out of their way to encourage private disclosure --- a zero-day on a vendor is a zero-day on all of it's customers.
Sorry, but no. Compensation is highly relevant. Do you work for free? Or do you just not consider security research to be worth anything?
Although there are various opinions on the best way to disclose bugs, your view of what it means to be "whitehat/legitimate" is not actually consistent with the infosec industry, so please do not misuse the terms to throw judgments at others.
We can easily spin it the other way too after all - one could say that the largest, most profitable company in the world has a moral obligation to compensate those that are protecting their users where they failed to.
Yes I do work sometimes for free - its called Open Source - and sometimes I see my labor implemented into commercial projects. That's fine by me. I take from the well more than I give to it.
I entirely agree that Apple should be compensating those that disclosure exploits appropriately - I didn't say otherwise. But if you have a status quo where a vendor won't compensate and you have a zero-day opportunity, I say the appropriate thing is to inform the vendor first anyway (you can always disclosing publicly if you get no response). I fight for the user and all that.
Disclosing it publicly zero-day doesn't make you any money anyway.
Full disclosure is the only responsible sort of disclosure.
Apple, like Microsoft, has the tendency to sweep things under the rug when they feel it is unlikely the situation will become public. The only way to correct this behavior is release what you find to the public and as fast as possible.
TL:DR of above link: "[responsible disclosure] is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details"
Not really. There's no privilege escalation. You can only change user's password if you're already logged-in as user. That's bad, but it's only going to happen if you literally walk away from a terminal and someone else sits down.
How? The problem he mentions at the end of the post only applies to the currently logged-in account. If you can change root's password, then you're already root, and don't need to change root's password to gain access.
"Like I said, it's not good, but it's not what I would call a "security hole" because there is no escalation of privilege."
Doesn't the end of the article suggest that without admin access, you could just reset the password for any admin user, then be able to log in as them? Sounds like priv escalation to me.
Edit: Actually, reading further comments, it seems you can only reset the password of the currently logged in user without reauthentication, so you can only get admin privs if you've already got a console with admin privs. I'm wrong.
I know this isn't the same, but I feel like mission control set to a hot corner bypasses the password screen from time to time. I never really notice it though
I suppose it's different if an unauthenticated user can perform a password change with the system powered on, but similar things can be done with Windows and a Linux live cd with some tools, and Linux passwords can be changed in "single user" mode.
`dscl` should change the FileVault disk password for the associated user as well.
Note that if you're able to run `dscl`, the disk has already been unlocked and is insecure. You may as well just copy any interesting data while you're there.
I'm wondering the same thing. I use filevault, but I don't feel like messing it up by changing the password this way.
I wonder if you can reset the password and use that password to simply disable the filevault.
Btw. My five cents. Write a script to:
1. change current users password to X
2. sudo "something really bad"
3. use password X
And there is a virus that can do anything on a mac. If you can change the password of the current user and he/she is an administrator, then any application can escalate to SU.
Yea with this I'd be worried about something doing that, making a new hidden user and then setting the password on the original account back leaving no immediately visible signs that anything is wrong.
The article also shows how you can obtain the current password hash without knowing the password - so you might be able to stash that away, and then surgically put the old hash back once you're root.
You can easily disable the ability to boot an Mac OS X CD or DVD and change the password using Open Firmware password protection: http://support.apple.com/kb/HT1352
1. When it comes to security, from the point of view of an OS vendor, if you have gained unauthorized access to an interactive shell on a target machine it's already "game over, man". You cannot protect against physical access, and you can pretty much assume that there are a plethora of unknown privilege escalation bugs so that any account is effectively a root account. Every company has limited security resources, and at some point there are trade-offs between usability and security. This is why efforts are typically focused on keeping the baddies out.
Once the bad guy gets in, you can only mitigate potential harm. This is the goal of things like File Vault (which will still protect your stollen laptop, assuming you put on a screensaver password). This is also why merely being able to change a password is not nearly as bad as...
2. Being able to recover the plain text of a user's password. I'm not going to discuss how or why, but this was possible on earlier versions of OS X and fixed only in Lion. In this regard, "cracking" passwords is much harder on Lion than it was on Snow Leopard and earlier.
Of course, that sort of level-headed approach to this kind of topic seems to be rarer and rarer on HN these days...unfortunately...