Apple security blunder exposes Lion login passwords in clear text

Apple security blunder exposes Lion login passwords in clear text

Summary: With the latest Lion security update, Mac OS X 10.7.3, Apple has accidentally turned on a debug log file outside of the encrypted area that stores the user's password 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:

Topics: Software, Apple, Hardware, Malware, Mobility, Operating Systems, Security

Emil Protalinski

About Emil Protalinski

Emil is a freelance journalist writing for CNET and ZDNet. Over the years,
he has covered the tech industry for multiple publications, including Ars
Technica, Neowin, and TechSpot.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It's not a bug...

    ... It's a feature. ;)
    The one and only, Cylon Centurion
    • You are debugging it wrong

    • Wow.

      Flagged already. Sad thing is, that's all security is to Apple... A joke. Truth is, they did this to themselves. When your customers are under the impression they're invulnerable, how do you go about telling them they're not?
      The one and only, Cylon Centurion
      • Some Mac zealot flagged you again

        Imagine that, some people don't like the truth.
      • they just

        really really do not want to know truth about it.
      • In this case

        Being flagged is something to be proud of. ZD aren't going to take it down, so flagging is meaningless. To the flaggers, a message, but you probably won't pay attention: "FLAGGING IS NOT CODE FOR "I don't agree""

        I use both platforms, (and code on Windows), and I have to say that security is a joke for both of them. But Windows users are more likely to be aware that its a joke.
      • Whine about it?

        You going to whine about being flagged? While I agree there was no reason for it I don't see you making any comments about cheap shot comments getting voted up 40+ times. It's not different than an Apple Fanboy flagging you, it's just MS Fanboys or Apple Haters voting for posts with no relevancy what so every that are are childish cheap shots. One is no better than the other but you only have an issue with the one that came from an Apple fan I see. You see them from both sides, this just happens to be a thread that has more anti Apple people voting on posts. The whole post voting system here is basically a joke because it means nothing when people simply vote based on their fanboy or hatred position.
    • It actually is a feature

      There's no bug here, just a feature used by the developers then accidentally not disabled before shipping. There's certainly no exploit associated with this, you'd need physical access to the machine to take advantage, and even then you'd also need the user not to be using the newer version of FileVault.

      This is practically a non-issue. A lot like Macdefender and Flashback...

      *opens umbrella*
      • Not a non-issue

        Think stolen laptop. That's sort of the point with most hard-drive encryption tools.
      • Typical Apple Fanatic response

        If the situation had been reversed and Microsoft was the one storing passwords in clear text, you would have been all over them. It is time to stop thinking of Apple as the perfect child in a non-perfect world and that everyone is picking on Apple. Apple made a mistake and it is about time they owned up to rather than simply pooh-poohing it.
      • Are you dreaming?

        Inhaling something Mr. Fanboi?
      • Two replies:

        I understand this relates to stolen laptops. The article is very suggestive however that some new strain of malware might take advantage of this, which is ridiculous considering it would need administrator or root access to read the file in the first place.

        To protect against theft, all you have to do to get around this is use the new FileVault. If you're on the latest version of the latest version of OS X, chances are you've also updated to the latest version of FileVault.

        No I wouldn't. Windows did full disk encryption from the off so it would be even less of an issue for them. I didn't mean what I said as a Mac vs PC thing, you're reading way too much into it.
      • Microsoft and excuses!


        Don't give me that hogwash; people give Microsoft excuses all the time. Heck most people expect Microsoft to do such nonsense because their product quality naturally stinks. The problem with you Winheads (hence Micronazis) is you assume that Macheads think Apple is perfect, but contrary to popular belief most Macheads think Apple makes great products (big difference); which is mostly true with a few caveats. Microsoft on the other hand...!
    • Poor debug practice for a feature nobody uses

      It was poor debug practice, but this was a feature created a decade ago for a few customers when Apple was a niche operating system. Nobody uses FileVault 1. They have all long moved on to either third party solutions or FileVault 2. Most likely FileVault 1 will be removed from the OS in the next release or two. They don't have much time invested in FileVault 1 since it is basically a legacy feature originally intended for a few specific customers. Don't turn it on and you don't have to worry. In fact you can't turn it on anymore. They disabled the ability to enable FileVault 1 in 10.7
    • Not Windows

      We are not talking about Windows here.
    • You're being flagged because you're a troll

      It most likely has nothing to do with OSX vs. Windows, or the veracity (or lack thereof) of your comment. You are most likely being flagged because you are a troll, and that comment exemplifies it. Care to differ? Let's look at the definition:
      "In Internet slang, a troll is someone who posts inflammatory, extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion."
      "One who posts a deliberately provocative message to a newsgroup or message board with the intention of causing maximum disruption and argument"
      Etc., etc..
      Feel free to post a definition from any source that lets you off the hook here. Good luck with that. Now how about you go back to harassing goats crossing your bridge?
      • You started out okay, but then, you turned into a "troll", judging by the

        definitions you quoted.

  • Nice report, Emil. Good editing job, Ed.

    Amazing how things slip through the cracks sometimes. I'd hate to be the Apple employee who had resolution responsibility regarding that three month old forum post.
    • The forums aren't frequented by Apple employees ....

      ... and so this post just sat out there and Apple never saw it, most likely. Sometimes Apple employees do respond, but it's not like they are assigned to a forum and have to read everything. The ones that seem to do the best job are the monitors who like to rid the forum of things negative to Apple, discussions about Apple policies, "bad" words, etc. They are assisted by a group of tattletale customers/fanboys that make it their job to help with the sterilization effort. So comments that damage the image are excised, but technical postings on a serious security problem are ignored. I'm still hopeful Tim Cook will be able to correct their behavior, get rid of the arrogance, etc., but I'm not holding my breath.
      • What?

        Where are you getting this from?