Apple Security Blunder Exposes Lion Login Passwords In Clear Text 205
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."
Re:Great (Score:2, Interesting)
Oh hi there, InterestingTechGuysIn140Bytes. I was kinda wondering when you'll get a next account after you've blown last [slashdot.org] previous [slashdot.org] three [slashdot.org].
Re:lucky for me... (Score:5, Interesting)
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 (Score:5, Interesting)
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:
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.
Re:Do they have a build process? (Score:5, Interesting)
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:Great (Score:5, Interesting)
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 [google.com].
Relatively few? (Score:5, Interesting)
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.