Slashdot Mirror
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."
now i can find out what my password is.
ive been resisting a reboot for ages!
apple even ships their own malware.
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.
I do not fail; I succeed at finding out what does not work.
...There is app for that.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...I've got to say that if a fellow pen-tester managed to find a really deep, complex and convoluted vulnerability in by code then that's fair game and kudos to him.
This though...bitten by a debugging flag, the dev must be hitting the sauce right about now.
Now, putting my coder hat back on, why was a debugging flag left enabled while building for production?
That's just lazy/bad setup, everyone knows that you keep your environments separate.
I wonder what the source code or version control comments said..
Actually, Lion's FileVault is not a problem. Only if you were using the old FileVault from previous OSes (which only encrypted the home folder), upgraded to Lion, but did not switch to the new full disk encryption FileVault for some strange reason.
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)
FTA:
So only certain configurations, and relatively few at that.
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.
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
...you're passwording it wrong.
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.
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.
Don't blame me, I voted for Baltar.
What? Something seriously missing from the summary!
Copying features from Microsoft products again.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
No, it's off by default, and if you don't use FileVault (the legacy version) you are effectively not effected - your disk is not encrypted to begin with, and thus starting the machine in target disk mode gives access to your home folder to an attacker (or they can reset your login password with the OS X installer), bit *not* your keychain password which is the same by default, but not if the login password is changed via the root user or another admin).
It's still a bit of a huge security blunder though.
I wasn't a fan of Lion either after only a few days. It still has some things that have changed over SL that I really wish were back (Save As..., the old version of Preview, etc) but I did grow to like it much more when I got a Magic Trackpad instead of using a mouse. I think a lot of my issues stemmed from accessing it with a mouse. It's been designed (for better or worse) with trackpad users in mind.
Still, I can't really say it's been a step forward for OS X over 10.6 - it's a bit of a wash from a personal standpoint.
All of his friends went over to work on iOS and he's been left to pick up the slack. ;)
Now I will have to change my password from "password" to "12345678."
--
A woman once said to Adlai Stevenson, "Every thinking person in America will vote for you," to which Stevenson replied, "That won't be enough, ma'am, I need a majority."
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.
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.
lucm, indeed.
It's a feature designed to enhance privacy by encouraging the user to change their password more often.
Specifically, at each login. And logout. And several times in between. Quick! Keep changing it!
"We live in a global world" - Harvey Pitt, former Securities and Exchange Commission Chairman
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.
http://lkml.org/lkml/2005/8/20/95
Much as it probably is hard for people to acknowledge, Apple doesn't hire the best and brightest. Historically, like Microsoft, they have bought in most of their 'innovation.'
They spent many many millions of dollars trying to produce the 'next generation Mac OS (tagilent, pink, whatever including the one they called sagan until Carl Sagan sued them then they changed it to BHA (buttheaded astronomer..))
Then they gave up because their staff apparently was only producing botique crap and was much more interested in justifying one-button mice than writing good code.
So they bought NeXT and wrote a pretty layer on top of NeXTStep to use as their 'new' OS.
us mods can only hide it from people who don't read @ -1 ! :( But i have been reporting these as i see it to admins hoping for a nice IP ban.