Patrick Dunstan has put up a disquieting post on Defence in Depth, following up on a 2009 blog post on cracking OS X passwords. Not to put too fine a point on it, he describes a flaw in the way in which Lion's authentication scheme has been implemented. I don't have access to a Lion system here, but I thought this was significant enough not to postpone blogging it.
Password shadowing is a technique that started to be used to improve password security in UNIX and UNIX-like operating systems around the end of the 1980s: it contains password hashes in a file separate from the passwd file. Whereas passwd is "world-readable" – that is, unprivileged users have read-access to it as they use system components and utilities that need it – a shadow file is readable only by root or an equivalent privileged user.
Originally, this was intended to prevent an attacker from reading a password hash and using a password cracker to test possible passwords offline (i.e., without tripping alarms when an intruder keeps logging in with an incorrect password).
As you'd expect, unprivileged Lion users are unable to access a shadow file (each user has one) directly, but the issue Dunstan has highlighted is this: invoking Directory Services can generate a listing that includes the ShadowHashData attribute irrespective of privilege, giving you the password hash, inter alia. However, in this case, the potential for password cracking isn't the only problem. According to Dunstan, Directory Services doesn't require authentication before changing the currently logged-in user's password (i.e., you don't need to know the original password if the system thinks that you are the logged-in user), and he even offers a limited privilege-escalation scenario (basically, where the user under attack has administrator privileges).
This isn't quite as bad as it sounds, although some correspondents seem to have the idea that typing a single command gives any hacker the key to your iMac: in fact, the problem is only going to arise in a situation where the attacker has direct (but not necessarily local) access at the same time that you do. Still, it's reasonable to assume that Apple will take remedial action sooner rather than later, and in the meantime, Dunstan offers a quick mitigation by limiting access to dscl:
$ sudo chmod 100 /usr/bin/dscl
Chet Wisniewski, in a Sophos blog, makes some further (characteristically sensible) suggestions which I will paraphrase here. First of all, of course, the better your password, the more resistant it is to brute force attacks using stolen hashes.
Steps you can take to lessen the risk from bad actors with direct physical access include:
- Enabling your screensaver and requiring it to prompt for your password.
- Disable automatic logon (so they need to know your password to log in)
- Don't leave a system logged in and unattended. (He suggests using a "Hot Corner" or theKeychain lock.)
He notes that he's unable to confirm CNET's report that it's possible to change other users' passwords, and I notice that other comments on various reports based on this issue are also not entirely consistent with the findings reported or re-reported. Caveat lector.