Apple Security Blunder Exposes Lion Login Passwords In Clear Text

An anonymous reader writes "An Apple programmer, apparently by accident, left a debug flag open in the most recent version of its Mac OS X operating system. In specific configurations, applying the 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."

Comments

Great

[lemur3]

now i can find out what my password is.

ive been resisting a reboot for ages!

Re:Great

[cbreak]

Only if you entered it after the update and within the expiration date apparently. And you probably need local admin rights. Not a big hurdle if you're sitting in front of the computer.

Re:Great

[beelsebob]

Yes, because having a known md5 hash to transmit in plain text is much more secure than having a known password to submit in plain text.

If you want to do this properly, you use SSL for login (and possibly more) or you implement a secure password exchange protocol (e.g. SRP).

Re:Great

[icebraining]

You obviously have no fucking clue of what you're saying. If you hash the pass before sending, then what happens if someone sniffs the connection? They can just send the hash!

The hash effectively becomes the password.

So no, it doesn't increase security. But you know what does? Two-factor authentication. And do you know what big consumer oriented company start offering those first? I'll give you an hint.

Re:Great

[gutnor]

The hash effectively becomes the password.

Come on now, nobody simply hash the password: you timestamp it and salt it first then hash it. That is how it is done, and you know it. So yes the parent is incorrect, but saying that hashing is useless is misinformation. If you properly hash, a sniffer will be able to use the hash as a password only once. So that is a man in the middle, that sucks but it is not a complete pwnage as you suggest it is.

Re:Great

[icebraining]

Protecting against replay attacks is easy: don't allow two logins to the same account in the same window of time (30s, using Google Authenticator).

Most people won't login twice in 30s anyway, so they aren't affected.

Re:Great

[errandum]

In this case, because it is a false allegation. He should read the article he posted (and so should you)

malware

[Anonymous Coward]

apple even ships their own malware.

Re:malware

[mr100percent]

considering how this only affects people who used FileVault encryption on their Mac prior to Lion, then upgraded to Lion but kept the folders encrypted using the legacy version of FileVault, I hardly think this will be a popular vector for any attacks, malware or otherwise.

Re:malware

[IamTheRealMike]

Oh yes, you're right. It sounds like it only impacts people who actually want / need security. So that's OK then.

Re:malware

[Smurf]

Oh yes, you're right. It sounds like it only impacts people who actually want / need security. So that's OK then.

No, because the people who actually want/need security would have already turned off the legacy FileVault (i.e., the one that only encrypts the user's home directory leaving the system directory where the log file in question is located unprotected) and turned on the new FileVault which encrypts the whole disk, including all system directories. That was one of the few really compelling features of Lion.

BTW, this is a Mac OS X 10.7.3-specific issue. It does not affect users of pre-Lion systems which only have the legacy FileVault option.

Re:malware

[Isaac Remuant]

The problem with Linux and generalizations is that there's more than one Linux.

I've never recompiled a kernel (that I'm aware of).

Do they have a build process?

[msobkow]

When I build a system for Linux distribution, I use scripts to configure the options on the build server. I don't use manually specified configurations from developer workstations.

Doesn't Apple grasp this concept of source code versioning and build management? Or was the debug flag in question hard-coded in the source rather than specified as a build option? If so, Apple needs to revisit it's coding structure and figure out how to set BUILD TIME options instead of hard coding them.

Re:Do they have a build process?

[Kjella]

Well I've seen many logging frameworks where debug logging and application logging was simply a different severity level, particularly since you may want crash/debug logs from users. All it takes is one sloppy developer that needed a log output, copy-pasted an application log line instead of a debug log line, because it's only temporary and you're going to take it out right? Both works for him. And then suddenly you end up with debug info in your production logs. I don't see why this would have to be a problem with their build process.

Re:Do they have a build process?

[140Mandak262Jamuna]

All your debug flags and compiler flags and build settings etc assume the developers would properly bracket their code under proper #ifdefs .

Like:

#ifdef DEBUG_BUILD

SaveDebugInfo(logfile);

#endif

But if the developer had not bracketed their code with proper protection macros, no build setting is going to rescue you.

I have tried make the system as automatic as possible. I have laid down rules to my team. But if you make the system very very foolproof only fools would be able to use it. The process requirements will swamp out the developer. Most likely the error happened at several stages. Originally a function that will be called only under debug build was making a call to save stuff to the log file without protection because the whole damned function is supposed to be called in debug mode. Then someone cut/paste parts of the code out to a function that is called in both debug builds and protection builds. Carelessly.

There is no way you can protect yourself against careless developer. Anyone working at such sensitive parts would be a senior developer, probably a manager stepping in to fix something simple in a module that he himself wrote ages ago. He was very confident and the build guidelines might have mutated without him knowing it. #ifdef DEBUG_BUILD might have been changed to #ifdef DEBUG_OSX and #ifdef DEBUG_IOS and he never got the memo because he was not a regular developer. Such things happen.

Re:Do they have a build process?

[icebraining]

There is no way you can protect yourself against careless developer.

Of course there is. It's called "code review".

Re:Do they have a build process?

[Just Some Guy]

All your debug flags and compiler flags and build settings etc assume the developers would properly bracket their code under proper #ifdefs .

It's safer to bracket the logging code in #ifdefs:

void SaveDebugInfo(logfile) {
#ifdef DEBUG_BUILD
... write it out ...
#endif
}

so that you only have to get it right one time. If you make developers repeat a process 10,000 times and they get it perfect 99.9% of those times, that means it's still screwed up in 10 places.

Re:Do they have a build process?

[Just Some Guy]

That's option B, option A is called "Open Source".

Which works as a distributed form of... wait for it... code review.

Do you want to find the passwords of other users?

[140Mandak262Jamuna]

...There is app for that.

Re:Really?

[michelcolman]

Your login password also unlocks the encryption password for FileVault. The login passwords were apparently logged in a file outside of the encrypted image. (Only for the old pre-lion version of FileVault running under Lion)

Not really

[mr100percent]

FTA:

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.

So only certain configurations, and relatively few at that.

We have QA processes which automatically detect

[gcnaddict]

things such as debug logs during testing.

Does Apple have no such thing? This leads me to think that Apple either has no development lifecycle or, in case they have one, only half-heartedly obey it.

Re:We have QA processes which automatically detect

[Anonymous Coward]

I've been working here and there for Software Verification for a number (double-digit) number of years, on a number of products. I've seen programmers do some things in development that they forget to clean out before release that would curl your hair. Especially from the ones fresh out of school, who don't have a lot of experience. "Oh, I'll put in these debug lines just for now." No wrappers or conditional compliation of any kind, so they leak out into the final product with no one the wiser.

Another commenter pointed out that a proper assurance test would look for rogue files. That works for unauthorized/unspecified log files, such as in this case, if the organization has good specifications and tight testing. I'm not in a position to comment about Apple's coverage in this area. The problem is that other debug statements could make unauthorized entries into authorized logs, and who would catch it?

What I saw was most effective was peer code review, especially if you had the coder equivalent of the BOFH in the audience to catch crap like this. There's nothing like people seeing "release" code with debug stuff not stubbed out.

Re:I wonder what the comment said...

[Mr. Underbridge]

//REMEMBER TO COMMENT THIS SHIT OUT SO I DONT GET FIRED

Filter error: Don't use so many caps. It's like YELLING....

Re:lucky for me...

[Sancho]

Some "strange" reason?

How about you've got multiple users on the machine? With Filevault2, any user can unlock the whole disk. As much as I like macs, it's a complete joke. With Filevault1, you had homedir encryption on a per-user basis. My files were secure from other users of the machine.

Re:bloody hell

[iluvcapra]

Looking at the actual message, it looks like the dev in question just took an "attributes" NSDictionary argument and stuck it into his NSLog() call whole hog, as in:

//print arguments
NSLog(@"about to call _premountHomDir with %@", attributes);

"%@" in an OSX printf-style format string will call -(NSString *)description on whatever object in on the vararg position for that %-code, and put that string in the output. The "description" selector on a dictionary spits out the keys and values of the dictionary in a human-readable format. The "attributes" object in this case contains a lot of information that would be interesting for a human debugger, the password being an exception.

Typical Apple

[toadlife]

Copying features from Microsoft products again.

Don't blame the one guy still working on OS X.!

[Y-Crate]

All of his friends went over to work on iOS and he's been left to pick up the slack. ;)

Re:Don't blame the one guy still working on OS X.!

[StripedCow]

Oh, and I thought everybody was working in the legal department.

Relatively few?

[WD]

What qualifies that statement? Any FileVault user that upgraded to Lion would be affected, which I would think would be more than a few. FileVault is not upgraded to FileVault 2 automatically. The user would need to manually disable FileVault and then re-enable it to get the whole disk encryption feature.

Just a bug

[lucm]

Somehow I have a feeling that if this same kind of "bug" had been found in another operating system, such as one coming from Redmond, the discussion and media coverage would have been quite different, and there would have been much more Slashdot comments on this story.

We are talking about passwords stored in clear text, no fix yet, and based on the article, no assurance that the fix would remove copies of the unencrypted passwords. For a company that was wondering how to spend 100 billions. What a joke.

timestamp it and salt it and then hash it?

[YesIAmAScript]

First, if you timestamp it, you don't need to salt it. The password would effectively have a lifetime of minutes at best, so adding a salt doesn't improve anything.

Second, your idea ruins the whole point of using a trapdoor function (what the internet means by "hash"). The point of the trapdoor function is that the server doesn't have to have your password stored on it, because you can just verify the password presented by comparing a hashed form of the presented password to the hash you have stored.

But with a time+password hashing scheme, the server must know the user's password because each time the user logs in, the must construct a new hash from the password and the current time.

So, if your server is going to know the password, just use a shared secret system like SRP. Then you get two-way mutual authentication too.

Re:timestamp it and salt it and then hash it?

[fgouget]

The point of the trapdoor function is that the server doesn't have to have your password stored on it, because you can just verify the password presented by comparing a hashed form of the presented password to the hash you have stored.

But with a time+password hashing scheme, the server must know the user's password because each time the user logs in, the must construct a new hash from the password and the current time.

Not true. The server can just store the salt + hash of the password. Then when a client wants to authrenticate the server sends the salt + random one-time value. The client uses the salt to generate the password hash. Then it concatenates the random value and resulting hash and hashes the whole and sends the result to the server. The server too computes the hash of the concatenated random value and password hash. It then compares that with what the client submitted. If it matches then the client had the right password. The hash sent by the client cannot be used for replay attacks because the random value will be different for the next login. The server does not know the user password and the hash is salted making it hard to recover the user password (which helps if it was used on other sites). The stolen hash can however be used to authenticate through the login algorithm however.

There's probably better solutions but this is enough to prove the server does not have to know the user password even if timestamps or one-time random values are used.