Apple security blunder exposes Lion login passwords in clear text

Update on May 9: Apple releases OS X Lion v10.7.4, fixes FileVault password bug

An Apple programmer, apparently by accident, left a debug flag in the most recent version of the Mac OS X operating system. In specific configurations, applying OS X Lion update 10.7.3 turns on a system-wide debug log file that contains the login passwords of every user who has logged in since the update was applied. The passwords are stored in clear text.

Anyone who used FileVault encryption on their Mac prior to Lion, upgraded to Lion, but kept the folders encrypted using the legacy version of FileVault is vulnerable. FileVault 2 (whole disk encryption) is unaffected.

The flaw was first reported by a security researcher David Emery, who posted his findings to the Cryptome mailing list. The bug has not been corrected by any subsequent updates. Emery explains the severity of the issue:

This is worse than it seems, since the log in question can also be read by booting the machine into firewire disk mode and reading it by opening the drive as a disk or by booting the new-with-LION recovery partition and using the available superuser shell to mount the main file system partition and read the file. This would allow someone to break into encrypted partitions on machines they did not have any idea of any login passwords for.

Since the log file is accessible outside of the encrypted area, anyone with administrator or root access can grab the user credentials for an encrypted home directory tree. They can also access the files by connecting the drive via FireWire. Having done that, they can then not only read the encrypted files that are meant to be hidden from prying eyes, but they can also access anything else meant to be protected by that user name and password.

This leak of credentials could be catastrophic for businesses that have relied on the FileVault feature in Macs for years. FileVault is intended to protect sensitive information stored by providing an encrypted user home directory contained in an encrypted file system mounted on top of the user's home directory. If an employee has their Mac stolen, however, anything they encrypted, as well as anything that requires those credentials, can be accessed without hindrance if the vulnerable configuration is in place.

This also affects Time Machine backups to external drives. If your hard drive is stolen, it doesn't matter that the backups require a key to read. The backed-up log file contains the required password stored in clear text. This means your compromised password has been backed up for the long term.

In addition to theft or just plain physical access, it would be possible for cyber criminals to write very specific malware that knows where to look on a targeted system. While this would be difficult to implement, the lure for cyber criminals is obvious; anything encrypted, especially by an enterprise employee, has the potential to be very valuable.

Mac OS X version 10.7.3 was released on February 1, 2012. This means for users who updated immediately, weeks of accessing encrypted folders is now available for anyone to see. The good news is that it isn't the full three months since the log file is only kept by default for several weeks. If you updated last week, then it's only one week of password accesses that has been stored. Of course, sometimes that's all it takes.

Some users have already noticed this feature in the wild but hadn't yet stumbled across the reason. Users on the Novell Forums noticed and have been discussing the issue since last week.

On the Apple Support Communities forum, at least one user noticed the flaw exactly three months ago, and asked for an explanation. Here's what he wrote:

I've tried it on another Mac as well, same result: The login of a normal network user writes this log line as his homedir gets mounted. This poses a security risk. We have some users who are local admins, they could ask another user to login on their Mac and look for the password afterwards. Extration in single user mode would be possible as well.

Is this a "speciality" of our environment or is this a known bug? Can I turn this behavior off? We are running Lion clients with a SL Server and using OpenDirectory.

Nobody got back to him.

This flaw further shows Apple has a quality assurance problem. When it comes to encryption, it's important to choose a secure algorithm, but implementation is even more important. A simple bug in how the keys are secured, managed, or accessed can lead to a massive unraveling, as we've seen here.

Apple needs to fix this issue as soon as possible. Even when a patch is made available, it will be impossible for the company to ensure the log file has been deleted, especially given all the places it may have been backed up. This means your password could still be out there even after you update, so after you do, make sure to change it.

I'd like to thank my colleague Ed Bott for editing and contributing to this report.

I have contacted Apple and Emery, and will update you if I hear back.

Update on May 7: Emery got back to me with a lengthy e-mail. Here is an excerpt of his thoughts:

In my opinion, it should be impossible to turn such a feature on without patching code, and ideally shipped binaries should not contain even a disabled code path to log passwords in plain text.

And considering the consequences for security, there certainly are legitimate questions about whether this was a pure accident by some low level developer that failed to get caught by QA, or a deliberate act by a malefactor ("mole") somewhere within Apple - or by far the least likely but also most sinister - a deliberate act a by someone in authority at Apple - perhaps to meet pressure from some government for access to encrypted partitions (at national borders ?).

Certainly there is a well known strategy for finding this sort of stuff - namely to choose a rather unique password string and search for it across the entire raw disk device (and if you find it or perhaps certain predictable permutations and encodings of it as well, determine what file it is in using the obvious filesystem maintenance commands that track a disk block back to the file it is part of). This is weak in that it doesn't catch all cases of leaks reliably but at least might catch a glaring one like this... I'd frankly expect it would be automatic to run such tests as part of a regression suite on a major product trusted by millions to be somewhat secure.

Update on May 9: Apple releases OS X Lion v10.7.4, fixes FileVault password bug

See also:

• Flashback malware exposes big gaps in Apple security response
• Microsoft: Macs 'not safe from malware, attacks will increase'
• Osama bin Laden didn't use encryption: 17 documents released
• Cross-platform malware exploits Java to attack PCs and Macs
• Syria pushing malware via Skype to spy on activists
• 3 million bank accounts hacked in Iran