Overblown Security Statements

There have been several stories floating around the web about a recent security flaw in OS X 10.7 that allows a user to change the password of another user without knowing that user’s current password. Although there is a security flaw related to passwords on OS X 10.7 it’s not nearly as severe as many websites are making it out to be.

An overview of the flaw can be found here. In summary the flaw is related to the Director Services command for reading and changing passwords. By entering the following command you can get the shadow hash of any user’s password:

dscl localhost -read /Search/Users/[user]

The value [user] should be replaced with the short name of a user who’s shadow hash you want to obtain. This is a rather serious flaw as there are scripts that can crack shadow has password (in fact one is available on the linked site for OS X 10.7). The other part of this flaw involves changing users’ passwords using the following command:

$ dscl localhost -passwd /Search/Users/[user]

Once again you replace the value of [user] with the system short name of the user whose password you want to change. What most articles I’ve seen regarding this flaw have claimed is that this command allows you to change another user’s password without knowing their current one. This is incorrect as the command requires you to enter the user’s current password before changing it. What this command does allow you to do is change the currently logged in user’s password without knowing their current one. Once again this is a rather serious security flaw but not nearly as severe as many are making it out to be.

I’m not trying to defend Apple here as they royally fucked up by allowing users to grab other users’ shadow hashes. They also fucked up be allowing somebody besides a directory administrator to change a currently logged in user’s password without entering their current one. But this flaw requires one major thing, access to a currently logged in user account. In most cases this means you must have physical access to the machine in which case all bets are off as far as security is concerned (it’s generally accepted that once an attacker has physical access to a target machine it’s game over).

The important question you should be asking right now is how can you defend against this? It’s simple, don’t leave you machine logged in when you’re not around. You should have a password set on your account (if you don’t you have no means of preventing unauthorized access anyways) and the account should be set to require a password immediately after locking the screen. When you walk away from you machine lock the screen (the keyboard shortcut on OS X is control + shift + eject). Remote access shouldn’t be a concern as it requires a remote user to know the user name and password of somebody on the system already (in which point this flaw matters not as they could change the password for the account they known the credential for).

Finally this flaw allows an unauthorized user to change the password of a currently logged in user without knowing that user’s current password but it does not allow that unauthorized user to change the currently logged in user’s keychain password. This means the password, certificates, and notes stored in the keychain will remain encrypted and out of reach unless the unauthorized user is able to crack the user’s shadow hash (in which case they have the password to unlock the user’s keychain).

If you need to give other users access to use your machine it would be smart to create a separate account for them and use the parental controls to prevent access to all applications they do not need (especially Terminal in this case). This isn’t bulletproof by any means but it’s an extra layer of security that should be done anyways.