A security error in OS X 10.7.3 exposes passwords on systems with support for the pre-Lion FileVault home-directory encryption feature. This security flaw, apparantly created when Apple left debugging code in the 10.7.3 update, is only triggered with Lion systems in which legacy support for the original FileVault is retained and when logging in with such an account.
Mac systems using whole-disk encryption with FileVault 2 (introduced in Lion) are not affected. It is also unlikely that revealed passwords can be obtained by malicious parties, unless new malware appears specifically designed to hunt for the exposed logins.
First reported in February by a user registered as “tarwinator” in Apple’s forums, but ignored, the security error became widely reported this weekend when David Emery sent a post to the Cryptome security mailing list describing the problem.
Emery noted in his post that one way of examining the log file in which the password can be found requires an account with administrative access on a booted Mac OS X system and physical access to the system; no administrative password is required to read the log. However, because the file is outside of encrypted home directories, restarting a system in FireWire Disk Target mode allows anyone with their hands on the computer to read the file on another Mac. A Lion system can also be rebooted into the Lion Recovery mode (holding down Command-R after restart), and Terminal launched (Utilities -> Terminal), and then the log file may be viewed without any password. (The file in question is in the Unix /var/log directory, and called secure.log.)
This was clearly an error in code review, as the message in the file says “DEBUGLOG” in all caps. Developers often put in messages that are sent to a log file for such purposes, but should be flagging those in code for review before release, and the quality assurance (QA) process companies follow in sending out updates to any software should catch debugging messages that are unintentionally left on. It’s also baffling that any debugging would reveal a password because of the risk of the logging code being left included by accident, as occurred here.
Apple did not respond to inquries regarding this issue.
Who’s at risk
There’s no simple solution for this problem that doesn’t involve a bit of fuss, even after Apple releases a patch to prevent the password from being logged as clear text. But many (perhaps most) Lion users won’t be affected. If you never enabled FileVault on a computer prior to upgrading to Lion or purchased a computer with Lion installed, you are not at risk. You’re also not at risk if you didn’t update Lion to 10.7.3, or if you never logged in as a user with a FileVault account with 10.7.3 installed.
The only users with the slightest exposure used FileVault in Snow Leopard or an earlier release and, when viewing the Security & Privacy preference pane after upgrading to Lion, clicked Keep Using Legacy FileVault when prompted. (A dialog reads “You’re using an old version of FileVault” when you open that pane in such a circumstance.) If you clicked Turn Off Legacy FileVault, and never restarted the system in Mac OS X 10.7.3 and then logged in to a protected user account prior to that, you’re fine. (Lion’s FileVault 2 encrypts an entire disk, and as noted earlier, this flaw doesn’t reveal its passwords.)
If you fit this bill, then the only problem you have is that the “secure.log” file that contains the debugging information from a 10.7.3 login to a protected directory falls into the hands of a malicious party who can then use that log to obtain your password. This could occur if someone with intent to access your files had physical access to your machine while you were logged in or could restart it in Lion Recovery or FireWire Target Disk mode. A ne’er-do-well could also access files from a Time Machine backup, such as on a shared Time Capsule disk.
Given the recent Flashback malware that affected as many as 600,000 Macs, it’s not preposterous that future malicious software would attempt to scan logs for debugging passwords in order to gain administrative access to Macs as well.
How to fix the problem
The only curative solution until Apple patches the problem is to change the password on a FileVault account after every system restart or when switching accounts to log in. A changed password isn’t logged. You could also disable FileVault access through the Security & Privacy pane, which exposes you to risk of your system being stolen and files retrieved, but reduces the chance of password theft.
For single-user systems, or multi-user Macs in which no one is concerned about hacking each other’s accounts, you could also turn on FileVault 2 for more effective encryption and system protection. FileVault 2 doesn’t individually encrypt each user’s directory so that other users on the same system would have no access (account-based permissions doesn’t protect against administrator access), but it does prevent access to a system without a password to one or more accounts enabled for boot-time access with FileVault 2. Read our Complete guide to FileVault 2 in Lion on how to proceed.
What’s disturbing about this flaw isn’t how many Mac users are exposed to it, but how simply sloppy it is, coming on the heels of Apple’s failure to take Oracle’s Java update and release its own version for Mac OS X in a timely fashion. Apple is behind the security eight-ball, a place it rarely finds itself. It needs to step up its game.
[Glenn Fleishman had his Unix password file stolen once in 1995, and he’s never been quite the same. He is a senior contributor at Macworld, a writer of the Economist’s Babbage blog, and the author of several books on security and networking.]