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

[Anonymous Coward]

Oh hi there, InterestingTechGuysIn140Bytes. I was kinda wondering when you'll get a next account after you've blown last previous three.

Re:Great

[leuk_he]

Google already has everything about you. There are barely laws that protect you about the gathering google does. why complain about the plain text part?

Re:Great

[chrb]

I think it's funny that people complain about this while still happily submitting their clear-text passwords to Google.

You mean that people are submitting a password to authenticate themselves to a web site? The horror! Google should obviously do whatever it is that Microsoft and Apple are doing to authenticate their web users...

Re:Great

[TheThinkingGuy]

I know you're being sarcastic, but yes, they should. There's companies who actually care about user's privacy and make md5 hash of the password on the client side. Google does not. This despite the fact that their services need JavaScript enabled, so saying that user might have JS disabled is no valid excuse. Hashing the password on client side would greatly increase security and show that the company actually cares about its users.

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

[Anonymous Coward]

Wow, nice FUD. The article you linked doesn't mention passwords at all, and as an engineer at Google I can confirm that it's impossible to actually get user passwords. ... but keep trolling, Microsoft shill.

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

[Anonymous Coward]

Sure, we believe you random guy on the internet.

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

[Anonymous Coward]

Actually, it is a little better because at least you can't test using the same password at a different website. But, really, what LiveJournal actually does is implement a challenge-response scheme in Javascript. If you have Javascript enabled, what it transmits back is a hash of your password and the challenge string concatted together. You still have the problem that the server knows your plaintext password (fixable by more hashing) but at least it isn't sent to the server on every login. See Digest access authentication for an actually correctly implemented version of this.

Re:Great

[Anonymous Coward]

How does a timestamp help? You either need to ensure the client and server are in lock step, and adjust for transmission delays (impossible), or you allow a window +/- a number of seconds for the timestamp to arrive at the server, thus making replay attacks possible.

Re:Great

[anss123]

How does a timestamp help? You either need to ensure the client and server are in lock step, and adjust for transmission delays (impossible), or you allow a window +/- a number of seconds for the timestamp to arrive at the server, thus making replay attacks possible.

Presumably the timestamp and salt is sent along with the hashed password.

However this does not prevent phishing and code injection style attacks. That's the real problem SSL is trying to solve, namely that any site with a SSL certificate is who they claim to be, and that no one in the middle has slipped in something extra during the download.

Re:Great

[icebraining]

I never said hashing is useless. Hell, the Google Authenticator that I linked does exactly that (HMAC-SHA1 with the Unix timestamp as the message).

I said that an hash of the password is useless, and it is. An hash of pass+timestamp+salt is not the same thing as an hash of the password.

Re:Great

[Anonymous Coward]

grep password /var/log/secure.log

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

[icebraining]

Actually, timestamped hashes like Google Authenticator uses can be easily used to prevent phishing: after you log in with a generated code, you wait for the next code (30s using GA) and then the server shows the new code to the user, authenticating itself the same way he did.

It doesn't protect you from MITM, though.

Re:Great

[errandum]

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

Re:Great

[Anonymous Coward]

Wow, nice FUD. The article you linked doesn't mention passwords at all, and as an engineer at Google I can confirm that it's impossible to actually get user passwords. ... but keep trolling, Microsoft shill.

I think you mean 'Apple shill', this is a story about Apple passwords being stored in plain text, not Microsoft. Why is it that any anti-Google sentiment is immediately met with the idiotic idea that Microsoft - but no one else - would actually be paying people to write crap like that on a site like this?

Re:Great

[anss123]

Google Authenticator "cheats" a bit by using your mobile phone to first authenticate that you aren't some password stealing hack.

Which is good enough for most sites I guess. It's also in one way more secure than SSL, as instead of the site proving itself to you; it's you proving yourself to the site. IOW if someone steels a user’s PW, SSL won't prevent the theif from logging on with it.

Re:Great

[Anonymous Coward]

They are Facebook shills pretending to be Microsoft/Apple shills :-) Watch the shill posts for a while and you will see. They alternate playing pro-Apple/pro-Microsoft, sometimes even from the same account, but the one thing they are consistent in is always being pro-Facebook and anti-Google.

Re:Great

[icebraining]

Google Authenticator "cheats" a bit by using your mobile phone to first authenticate that you aren't some password stealing hack.

What do you mean? I don't use GA itself, but a J2ME app that implements the same algorithm, so I wouldn't know what kind of verifications GA does, but Gmail et all work fine with a basic HTOP/TOTP implementation.

Re:Great

[hobarrera]

No, they can't try the same password somewhere else, but they can click "I forgot my password, email me a reset link" anywhere else.

Re:Great

[anss123]

From: http://support.google.com/a/bin/answer.py?hl=en&answer=1037451

"Google Authenticator is for users enrolled in 2-step verification. Google Authenticator is a mobile application that allows you to generate 2-step verification codes on your smartphone without a network connection."

I've not looked any deeper into it, but a 2-step verification indicates that you must have something more than just a password. So even if the baddy gets your password he can't log on to your gmail account.

It dosn't have to be your mobile, if a J2ME app does the same job then that of course works too.

Re:Great

[Anonymous Coward]

Smells like yet another bonch sockpuppet.

Re:Great

[icebraining]

Oh, right. Well, GA just performs the second step - the first is the normal password input. The second is generating a time-based token from a shared secret (essentially a second password, but you don't input it on the login page).

I just didn't understand what you meant by "cheating", that's why I asked.

Re:Great

[anss123]

I just didn't understand what you meant by "cheating", that's why I asked.

Just that they use something "outside the browser." :-)

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

[mr100percent]

People who actually want security wouldn't be using an older, and slower, version of FileVault in the latest OS and also ignoring the message telling them to upgrade the FS to the latest version.

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

[michelcolman]

Those would have upgraded to the new version of Filevault with full disk encryption to replace the legacy version that had plenty of drawbacks.

Re:malware

[muon-catalyzed]

Expect it announced as a feature, a friendly user password lookup. They got away with worse things like kernel crashing, OS without copy&paste..

Re:malware

[epine]

People who actually want security and don't have insanely busy lives and didn't buy a Mac for precisely the reason of not having to dress like a plumber and promptly read and obey plumber guild news bulletins wouldn't be using an older, and slower, version of FileVault in the latest OS and also ignoring the message telling them to upgrade the FS to the latest version.

I don't have a Mac because I kind of enjoy participating in the anal retentive guild of digital grooming. Inference from logic shouldn't be used on people who own Macs. That's really stupid if you've ever checked out what that kind of person cares about.

If Apple wants to play the paternalistic "let us decide and pamper you card" then need to not mess it up. No excuses.

Re:malware

[Bert64]

People who actually want security are more likely to have upgraded to filevault 2 when they upgraded to lion, i certainly did as did everyone else i know who is running lion.

Re:malware

[mr100percent]

Slow down here chief, these aren't Linux users you're talking about. Apple'a upgrade is easy. It asks if you want to upgrade the encryption to match Lion's. If you said no, then you're exposed since you're using old code. They're not asking you to recompile your kernel here. I've never met anyone serious about encryption who stays versions behind.

Re:malware

[Anonymous Coward]

So? MS has been doing that for the past thirty years or so.

Oh well i guess that's ok then, go Apple for just trying to be an expensive copy of Microsoft.

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).

Re:malware

[Anonymous Coward]

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.

That's arguable. People who care about security may or may not turn off the legacy FileVault, depending on the configuration and the user's needs.

For a single-user system, the new FileVault clearly provides better security because it protects the entire volume.

For a multi-user system, some people might argue that the old FileVault provides marginally better security because it protects each account's data with separate encryption keyed to the user's password, which means that even if someone manages to find a way around the permissions model, your data is still protected except while you are logged in and the volume is mounted. Whether this outweighs the loss of encryption on the rest of the system (swap, etc.) is debatable, of course.

Re:malware

[Smurf]

For a multi-user system, some people might argue that the old FileVault provides marginally better security because it protects each account's data with separate encryption keyed to the user's password, which means that even if someone manages to find a way around the permissions model, your data is still protected except while you are logged in and the volume is mounted. Whether this outweighs the loss of encryption on the rest of the system (swap, etc.) is debatable, of course.

If you are really concerned with security of your data in a multi-user system you will have the really sensitive data in an encrypted disk image (using Apple's Disk Utility or TrueCrypt or something similar) regardless of whether the whole disk, just your directory, or neither are encrypted. And that's precisely for the reasons you cite: you can't prevent the other users' accounts from getting compromised.

Re:malware

[Anonymous Coward]

sorry you are wrong it has nothing to do with File Vault see last thread entry https://discussions.apple.com/thread/3715366

Re:malware

[lipanitech]

I really hope Apple cleans this up and puts there damage control and programmers to work ASAP. Apple as a business needs to handle this right or they could seriously eat a lot of bad press over this would defiantly hurt there stocks and there reputation. I mean two big security holes in only a few months not such great start Tim Cook.

Re:malware

[mcgrew]

these aren't Linux users you're talking about. Apple'a upgrade is easy.

If you think upgrading a modern Linux distro is hard, you're in the wrong place. One click, one password, done.

These aren't Windows users you're talking about here, chief. I always dreaded Windows upgrades, how many times should I have to boot a fucking computer to upgrade a program? Linux upgrades are also fast, I have Win 7 on a notebook (better than previous versions) but I still dread Patch Tuesday. The damned computer's completely useless for ten minutes when it reboots.

I have no clue how easy or hard upgrading a Mac would be, but I'd be willing to bet it's less of a pain in the ass than upgrading Windows.

Re:malware

[thelamecamel]

I just discovered that my uncle's computer is affected by this. He turned on FileVault in 10.6 because it looked cool, then upgraded to 10.7. Lion only tells you that you have a legacy version if you open the Security/Filevault preference pane, which he never did since using 10.7. When we opened it today, it gave us the options of keep using the legacy version or turning it off - I think "keep using legacy version" was the default option (could be wrong). In order to upgrade we had to visit a separate tab, unlock it, hit upgrade and go past a number of scary-looking warnings. So nerds who like to explore probably would not be affected by this, but others certainly are.

What is that sound?

[Anonymous Coward]

Oh, it is the sound of Google and Microsoft doing the LMAO and rolling on the floor. No chairs to through today - except maybe in Cupertino...

Re:What is that sound?

[jo_ham]

Chairs?! Pfff.

Don't you know us Mac users simply float in the air due to our own sense of self-importance repelling us from doing anything as "normal" as sitting on the ground?

Re:What is that sound?

[iggymanz]

imbibing chemicals that fool your brain into believing you are floating does not mean you are levitating in the real world, you danged mac hippie

Re:What is that sound?

[tsa]

You are wrong my friend. It's your disbelief that makes you see us sitting down but in reality we do no such thing.

Ouch!

[jo_ham]

It's a good job that my password is also the combination to my luggage.

In before "lol Mac users deserve this".

That makes for quite the dangerous security breach.

Re:Ouch!

[Anonymous Coward]

Go back to bed, bonch

Re:Ouch!

[Anonymous Coward]

jo_ham isn't bonch. He's just a Mac fanboi.

Really?

[Anonymous Coward]

TFA mentioned filevault, they're reusing system passwords for that are they?

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)

Re:Really?

[Anonymous Coward]

Thanks, that's exactly what it says and I can read :-) Is this only if you're using filevault? I didn't upgrade to Lion due to the stupid mobile orientated features, I'm asuming filevault isn't enabled by default?

Re:Really?

[jo_ham]

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.

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?

[Anonymous Coward]

Went I build software I always make sure any logging never logs sensitive data like passwords. That data is very rarely needed and if it ever is needed that code never touches the main source base.

I do that to specifically prevent issues like what happened here. It's too easy for even a seasoned developer to leave something like this open, better to not even have the possibly.

Re:Do they have a build process?

[gweihir]

I agree. The bug itself is a problem, but the real problem is that this was apparently easy to get wrong. And there, Apple has shown to be on low amateur level. Getting something as serious as this wrong must be hard enough that it only happens by intention and that intention needs to be expressed clearly and subsequent warnings must be in place.

So, yes, they have some sort of build process, but not designed or implemented by people that know what they are doing. Alternatively, the people designing the debug option have no clue who to do this right. Confidential data in logs is a very old and very well understood problem. Only people truly ignorant on how software security fails will get this wrong. That said, plenty of people are making serious and decades old security mistakes in new software. Getting software right is very, very hard and a lot of people writing software do not get it. They are cheap though and easily replaceable with somebody just as incompetent.

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?

[philipmather]

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

Re:Do they have a build process?

[140Mandak262Jamuna]

Exactly. Still it is not foolproof. It would drastically reduce careless mistakes, would not eliminate them. If one experienced savvy developer missed it, chances are his peer is likely to miss it too. And most people doing the review look to see if it would do what it should do, and if it would trigger any regression. This mistake happened after all the heavy lifting is done. At the time of winding up. Both the dev and his peer would have let their guards down. Anyway adding more layers and layers of code review, peer review, mechanical processes, check-in triggers and warnings based on grep and awk [For example: all functions meant for purely debugging must have the string _nc_ or _nocheckin_ in its name. All bodies of such functions will be automatically #ifdef\ed out in production builds] would take it beyond the point of diminishing returns. Developers start relying on these dumb mechanistic processes and let their guards down. Eventually you have careless developers.

Moral of the story: You can't guard against careless developers.

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.

Re:Do they have a build process?

[yuhong]

Reminde me of this: http://www.reddit.com/r/programming/comments/lchhd/ban_programmers_not_functions_about_memcpy_s/

Re:Do they have a build process?

[Anonymous Coward]

Call the function DoNotInclude_XXXX() - then parse the output of the compiler during the build and search the output for labels with that match for the search "DoNotInclude*" - If a match occurs: Fail the build.

Gets trickier with static things - of course..

Automated code review - The only way to go.

Re:Do they have a build process?

[jo_ham]

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

Just playing devil's advocate here, but are you saying that Open Source code is immune to bugs like this?

Re:Do they have a build process?

[smash]

Because open source has proven to be immune to such things? Puhlease...

Re:Do they have a build process?

[bored]

Doesn't Apple grasp this concept of source code versioning and build management?

Its not just apple (if this is even the case), its an amazingly huge number of "software" companies out there. For some reason, the idea of enforcing coding rules for debug flags and the like, along with enforcing a proper build system seem to escape a large (i'm guessing well over 50%) percentage of developers out there. I've seen/heard about it time and time again, where the build going out the door is the one generated on some developers desktop machine, our out of a developers personal checkout of code. What is even worse is often times no one else even sees a problem with this, because its been going on for so long.

Re:Do they have a build process?

[philipmather]

Fair game ;^)
Considerable more immune, yes.

Re:Do they have a build process?

[philipmather]

You're really comapring an unknown and evidently not-so-hot Apple developer leaving debug in their code to Ken Thompson, arguably one of the greatest programmers ever, slipping a self replicating trojan into the binary image of a compiler? "Purhlease..."

You're comparing Apple(s) to oranges. Detecting highly cunning subterfuge is an enitrely different ball game to picking up that one of your peers sat over on the other desk has accidentally left a few lines of debug in.

Re:Do they have a build process?

[Anonymous Coward]

I don't see the word "immune" in the parent posts, I see "protect". Code review and Open Source both help to protect you against careless developers. "Protection" does not imply perfect immunity.

Re:Do they have a build process?

[140Mandak262Jamuna]

True. And we can even have best practices guidelines for developers about naming the functions. All functions that is meant for purely debugging purposes should have the string _dbgfn_ in its name. The entire body of all functions with _dbgfn_ in the name will be automatically protected using the #ifdef at the time of checkin. We can have all such rules. But all these rules assume the developers will follow the guidelines and the code review will be done and peer will not miss it.

lucky for me...

[HeavyDDuty]

Lucky for me I read the fine article and since all my systems had a full Lion install (non-upgrade) it's not an issue. Also lucky for me I didn't use folder encryption in Snow Leopard. Also lucky for me I don't use FileVault.

Re:lucky for me...

[michelcolman]

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.

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:lucky for me...

[jo_ham]

That's what encrypted sparsebundles are for, surely (that you can mount at login).

FileVault 2 assumes that multiple users of the same system are mutually trusting of each other. It was not really meant to service multiple users - that's how version 1 worked and it had nothing but issues.

Re:lucky for me...

[GlobalEcho]

My files were secure from other users of the machine

The way I see it, the technical difficulties -- both manifest and potential -- of protecting users from each other on the same OSX system made FileVault 1 untenable. Every app (written by Apple or not) that put data into unprotected memory, swap, or disk was in principle leaking confidential information from the vault. You may have felt like your files were safe, and if you never turned on remote login or allowed fast user switching you were probably right, but the general multiuser case is full of attack vectors.

So while in principle the per-user protection was nice, in practice it inevitably full of holes. Rather than provide the illusion of inter-user security, Apple switched to full disk encryption in FileVault 2 -- something closer to what most of its users really needed anyway.

bloody hell

[roman_mir]

Why in our time somebody, anybody would need passwords to be stored for log purposes at all? You need to check if the user is typing it the right passwords? Compare the encrypted versions and store a state saying: correct / wrong password was used, what else do you need?

This is just stupidity, there is no other word for it.

Re:bloody hell

[cbreak]

For a Debugging Log. As the article said.

Re:bloody hell

[eldorel]

You missed the gp's point. At what point do you need to see the passwords in a debugging log?

Re:bloody hell

[Anonymous Coward]

Perhaps to check the log file's contents using unit tests...

Re:bloody hell

[Anonymous Coward]

Why in our time somebody, anybody would need passwords to be stored for log purposes at all? You need to check if the user is typing it the right passwords? Compare the encrypted versions and store a state saying: correct / wrong password was used, what else do you need?

Ask the rogue Google engineer who did this.

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.

Re:bloody hell

[michelcolman]

If you want to get hold of a colleague's password?

Re:bloody hell

[gweihir]

Indeed. Secret info in log-files is also a decades old problem. Any competent software developer knows about this and any bright person will figure it out by themselves. Guess the developer(s) in question are neither bright nor experienced. ElCheapo software development at its best.

Re:bloody hell

[icebraining]

If the test is checking log files, it's 1) not a unit test and 2) broken.

Re:bloody hell

[Bing Tsher E]

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.

Do you want to find the passwords of other users?

[140Mandak262Jamuna]

...There is app for that.

Re:Absolute garbage!

[HeavyDDuty]

pathetic.

As an InfoSec pro...

[Zapotek]

...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.

Re:As an InfoSec pro...

[gweihir]

The real problem is that the debug flag could mess things up this badly, apparently without it being readily obvious. Logging passwords is something you should never be able to enable this easily. If really needed, you hard-code debug instructions for secret info and so that it immediately obvious and includes drastic warnings. Like a screen-output you cannot suppress or something like it. Then you remove it after you fixed the problem. Secret information has absolutely no business at all appearing in ordinary debug output.

I wonder what the comment said...

[bhlowe]

I wonder what the source code or version control comments said..

Re:I wonder what the comment said...

[HeavyDDuty]

// TODO: remove trace statements before commit

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....

Bad news - but for a very small subset of users

[93 Escort Wagon]

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.

I can see how those circumstances could occur in the real world; however the first version of FileVault was a pain, and I don't know of many people that kept using it for very long.

I stopped using FileVault v1 after a few days. What sensitive stuff I have is now in encrypted sparsebundles, with the rest of my stuff unencrypted. Time Machine backups are stored on a LUKS-encrypted disk.

FWIW I've stuck with Snow Leopard - not a real fan of Lion. That was another thing I stopped using after a few days, although I did like the whole-disk encryption option.

Re:Bad news - but for a very small subset of users

[jo_ham]

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.

Re:Bad news - but for a very small subset of users

[Cinder6]

It depends on the person. Lion changed a lot of things, and not everyone will be happy with those changes. Personally, I absolutely love Lion, except for the way that Mission Control clumps application windows together (at least you can enable App Expose). I even really like the new way Spaces works; I use it so much more now than I used to.

As for this bug, it's a stupid mistake, but at least one that will hit a very small set of users. It's silly not to have upgraded from FV to FV2, and most people didn't use FV in the first place. I imagine a fix will be coming soon.

Re:Bad news - but for a very small subset of users

[jo_ham]

You'll love Mountain Lion then - the exposé behaviour is going back to the pre-Lion way with a setting toggle in preferences. I know several people who wanted that back.

The specific configurations

[Woogiemonger]

From TFA, the specific configurations that allow this to happen: "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."

Re:The specific configurations

[wbo]

From TFA, the specific configurations that allow this to happen: "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 problem is actually far more widespread than that. I have some Macs running Lion here that have never had FileVault enabled that have this problem. People on the MacEnterprise list have been discussing this bug for about a week now.

Using the legacy version of FileVault may be one method to trigger the bug but it definitely isn't the only one. Many are seeing the same bug when Lion is joined to an AD domain and some are also seeing it when using OD as well (Especially when using mobile home directories).

So far no one has been able to determine exactly what configurations trigger the bug since not all systems appear to be impacted, but the problem is definitely far more widespread than the article indicates.

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'm thinking they just apply the "logging" functionality to all updates (incase it bricks your apple device) they should just remember to cut or disable the sensitive information... just to show ya that apple is just as vulnerable than any other company big or small. - jb

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:We have QA processes which automatically detect

[Anonymous Coward]

Yea, a hugely successful software company like Apple is absolutely clueless. Score one for gcnaddict, the guy who doesn't do anything that anybody cares about.

Re:We have QA processes which automatically detect

[Anonymous Coward]

Sounds like they need the BOverseerFH.

Re:We have QA processes which automatically detect

[bill_mcgonigle]

things such as debug logs during testing

Even rpmbuild will refuse to write a package with extraneous files, but it seems likely in this kind of situation that the log file wouldn't be present until runtime.

Probably SELinux can prevent this situation.

Re:We have QA processes which automatically detect

[macs4all]

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.

I think that a company that has been able to pull off a virtually seamless architecture and word-size change like Apple did with OS X probably has their development methodology pretty well, er, developed, don'tcha think?

Re:We have QA processes which automatically detect

[Anonymous Coward]

Two years isn't double digits

Lone Programmer Accidentally Forgot...

[Anonymous Coward]

Man am I glad to read that! I was beginning to doubt apple's security credibility for a moment there. Luckily we now know that it's this one programmer's fault and not apple's.

At least it's not an iPhone, so there's less risk this man will commit suicide.

Bug Confirmed

[Anonymous Coward]

I've confirmed that this bug is occurring on one of my systems. Its an easy file to find. Its also a bit disconcerting to see my password right there in front of me in plain view. This bug may only effect a small number of systems, but that doesn't matter much if it effects your system.

But Apple are perfect, so of course...

[phonewebcam]

...you're passwording it wrong.

Re:But Apple are perfect, so of course...

[Anonymous Coward]

No matter how many times this type of thing is posted, it just never gets old...

Let me criticize them!

[Anonymous Coward]

Since I've never shipped a piece of commercial code with a bug in it, I feel justified in criticize Apple for what is clearly sloppy quality control.

(Never mind that I've never shipped any commercial code...)

wow

[Anonymous Coward]

could such a leak not be avoided reliably with an automatic test?

cb

Re:wow

[Alex Belits]

No. *Now* it can be avoided. Tests are for known (and therefore fixed) security problems, so they are only good for checking if the same bug is back. What happens in software development disturbingly often.

Re:wow

[Anonymous Coward]

If I cross a road I look before I go. I have never been overrun by a car before. So I learned to test for something that never happened to me.

You are talking about one class of tests, there are others.

cb

Re:wow

[Alex Belits]

All classes of tests are extremely limited in their usefulness. Some are just peddled better.

Re:wow

[Anonymous Coward]

So what? Even a test from an extremely limited test class could have been applied in this case to avoid this leakage.

cb

Re:wow

[Alex Belits]

What if the next bug leaks pasword backwards? In BASE64? Only on Mondays?

You can't test quality into the system. Tests can merely show that something is terribly, terribly wrong, and likely you have deeper problems.

Re:wow

[Anonymous Coward]

The next bug is the next bug. We are not talking about a bug here, at least not a direct bug. In this case somebody did something on purpose, which was to help during development but is definitely not ok in production. So it was clear right from the beginning, that this debug code was not to enter production under any circumstances. Obviously it wasn't sufficient to have a flag.
You mention changes in the setting which could break tests. Wouldn't it be better to track the debug flag itself?

For your generalisation on tests: so just by looking for the existence of tests you can determine the quality of the code? I don't think so. I agree with you that just having tests doesn't make a good system.

cb

Re:wow

[0ld_d0g]

Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build". But yeah, without knowing much about their build process, its just pure speculation at this point and anyone can tell you how this problem can be avoided in hindsight.

But regarding tests, there are various useful tests that can test previously unknown program states. Especially stuff like fault injection testing is incredibly useful. In fact many security researchers find tons of tricky bugs using these techniques. for e.g. send randomized input strings to test for reliability of API interfaces which accept arbitrary strings, or you can use a test suite that 'randomly' makes the system go Out Of Memory to see how different services deal with it reliably, etc.

Re:wow

[Alex Belits]

The next bug is the next bug. We are not talking about a bug here, at least not a direct bug. In this case somebody did something on purpose, which was to help during development but is definitely not ok in production.

It was one of millions things that happen in development. There is no way to count them all -- if developers had to record every instance of enabling or disabling various kinds of output, they would never have time for actual development.

This particular problem would not happen if there was a predefined way of producing debugging output, that is guaranteed to be never enabled in production builds. That would work even if no one ever tested anything. Because it's a matter of development infrastructure, not testing.

Re:wow

[Americano]

Could it be? Sure.

Could those tests also easily (and fairly trivially) be worked around by a developer just "trying to figure out what's happening" and accidentally checking in some bad code to a release branch? Sure.

It's very likely that Apple does builds where "CCFLAGS += -g -D__DEBUG__" doesn't get appended on the compile line. It's very likely that the developer who did this was trying to figure something out, got sloppy/rushed, and checked in something that hard-coded this behavior into the code, and that code - intended for test only - never got removed from the production build.

There's a million ways you could look for this sort of thing, and a million and one ways a developer could - accidentally, or maliciously - circumvent it by hard-coding (or removing) things intended to prevent this type of code from being compiled into production releases.

That doesn't excuse the sloppiness; But there's no way to prevent this sort of a thing 100% of the time - automated tests are useful, and could help minimize the risk, but you simply can't automate away dumb mistakes. The "best" way to have prevented this would probably be a change review by another developer familiar with the code who would say "whoa whoa, you checked in debug code, man" - presuming that second developer takes the time to actually review the change report.

Re:wow

[Alex Belits]

Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build".

No.

There should be no tests. There should be a rule that disables all debugging output in production builds. And, of course, all debugging output should use the mechanism that disables output with aforementioned rule.

Once that is implemented, testing is absolutely irrelevant, unless you are trying to test gcc.

Testing is for finding out if you have screwed up. Quality comes not from testing but from not screwing up.

Re:wow

[Anonymous Coward]

How is a predefined debugging system working? How is it guaranteed to never slip into production? There needs to be a test somewhere.

Re:wow

[Anonymous Coward]

I wasn't talking about Apple not doing enough testing. I was talking about the developer not using an automated system based on testing for a debug flag.

Re:wow

[michelcolman]

Instead of just logging to some file, you call a function like "debuglog" or something like that. Calling any other kinds of logging functions for debugging is absolutely strictly verboten. This function should be very easy to call so noone would have a reason to use any other kind of output functions. If they need a different method for recording debugging information, a new debugxxx function must be written first with the appropriate debug flags. Anyone using cout or any other output, even in a temporary 2 minute test, is terminated on the spot.

The production build simply replaces these debugxxx functions by nop. Problem solved.

Re:wow

[Americano]

And if there is no debug flag? Just some print statements, or #ifdef's being removed, or something like that?

There's no way to guarantee that this problem will ever be caught via an automated test. You can (and should) certainly test for specific scenarios that you can think of, but there's no way automated testing can know the intent or possible ripple effects of changes the developer has checked in; "verify no debug information is included in the production binary" can be automated. "Make sure the developer didn't remove an #ifdef block that turns on / turns off clear-text password logging for this particular binary," is a different question, and really all you can say for sure via an automated test is, "the developer changed some lines of code, here's the diff."

It's possible that the developer's mistake *could* have been prevented, but automated testing is not a magic cure-all that can divine the intent of the developer, and in a situation like this, it's not a "security bug," - e.g., expoitable hole that allows an attacker to escalate privileges - it's a "security bad practice." There's not a lot an automated test tool can do to catch that. It can take informed guesses that something "might" be a risk, but at some point, you need to involve someone who knows the code, and have them inspect the changes to verify that the changes match the intent of the developer without implementing bad practices.

Re:wow

[0ld_d0g]

No.

There should be no tests. There should be a rule that disables all debugging output in production builds. And, of course, all debugging output should use the mechanism that disables output with aforementioned rule.

What are you disagreeing with?

Testing is for finding out if you have screwed up. Quality comes not from testing but from not screwing up.

That is such a meaningless statement. Thats like saying programming is the process of introducing bugs in the codebase. Only after you write tests can you claim any such quality of code base. If quality does not come from testing then it does not exist other than in a programmers subjective opinions.

Re:wow

[Alex Belits]

What are you disagreeing with?

I disagree with a recommendation to add more tests to improve quality.

Thats like saying programming is the process of introducing bugs in the codebase.

No, but "introducing bugs in the codebase, running tests and watching if they cancel each other out" is a very much appropriate description of software development process as practiced by incompetent people. I call it perma-debugging cycle.

Only after you write tests can you claim any such quality of code base.

Tests do not prove anything other than two programs, test and program being tested, producing compatible results. They can just as well be both wrong, and usually test is formally wrong due to the limited scope and implicit assumptions made by a programmer who wrote it.

However a more important question is, do you want to be able to claim something, or actually make it closer to reality? If the former, go ahead, and do all kinds of measurements, tests, up to daily drug tests for programmers. This is a kind of solution we have with airports and TSA now. If you want to have less bugs, make it difficult to write a bug. Build infrastructure. Have infrastructure enforce global rules (such as when debugging logging is available) so programmer who uses it doesn't have to do it every time he implements anything. Re-use code that can be reasonably expected to be correct. Have code reviews.

Once that is done, there may be some talk about any kind of tests outside QA and developer's own initiatives. Maybe.

If quality does not come from testing then it does not exist other than in a programmers subjective opinions.

Of course, it is subjective. You want an objective evaluation of quality? Here it is: all software is wrong. For every piece of software at any point in time there is (known or unknown) valid condition that causes this software to misbehave. This will change when the last bugfix will be committed to some project, and so far no one, ever, made a claim that such an event happened.

But tests???

Tests are the most subjective thing that one can imagine to evaluate software quality. They are written by people who believe that software must pass some rules to be correct. You know what else is an expression of rules that produce software output? Software itself! Write the same program twice, run on all possible inputs (including all timing conditions as they are input, too), verify that result is always equivalent from some objectively defined point of view (again, timing, protocols, interactions with other software and hardware). That would be the only test that guarantees anything at all (+/- bugs in equivalence verification, +/- bugs in test infrastructure, +/- common bugs in both implementations). Anyone willing to implement that as his testing procedure? No? Takes nearly infinite time? Then everyone is welcome to shut the fuck up about tests being "objective" or "guaranteeing" anything.

Re:wow

[0ld_d0g]

So basically you want people to improve the quality of their code base, without actually giving them any concrete and practical way to measure the quality? Also why, are you ranting? No-one in this thread has claimed that tests are some kind of silver bullet. They are an important indicator - as objective as humanly possible - within reasonable constraints of day-to-day software development (we are not talking about NASA level quality and formal proofs and all that crap) - that can be useful in enforcing that software is designed & implemented to be robust, and relatively bug-free.

Also you are wrong that tests cannot guarantee anything. When a human guarantees something to another human it is assumed to not be some kind of absolute statement. This *is* the common use (legal and general) of the term. Because otherwise you need some kind of perfect god like being which can evaluate products/services.

Re:wow

[Alex Belits]

So basically you want people to improve the quality of their code base, without actually giving them any concrete and practical way to measure the quality?

Yes! I want people to avoid writing bugs regardless of those bugs being detectable by tests. I want people who can think of any kind of rule that applies to software, to implement and enforce that rule in their software so it will be logically impossible to violate it, instead of devising a tripwire for any piece of software that visibly violates it.

Also why, are you ranting?

Because this line of thinking reveals one of the most poisonous traditions in modern software development -- writing something that "looks right", and only starting to think when something visibly fails in a spectacular way.

No-one in this thread has claimed that tests are some kind of silver bullet. They are an important indicator - as objective as humanly possible - within reasonable constraints of day-to-day software development

No, they are not. They are arbitrary checks for randomly selected egregious mistakes. Passing tests lulls developers into thinking that their software works correctly when it really does not.

(we are not talking about NASA level quality and formal proofs and all that crap)

Why not? For tests to be meaningful, the difficulty of writing them well exceeds the difficulty of writing formally-proven software. Step down from there, and sufficiently careful logical thinking (a step down from formal proof) will always beat an informal test (a step down from complete test) made with the same level of effort.

that can be useful in enforcing that software is designed & implemented to be robust, and relatively bug-free.

Practice shows that they do not improve quality, they teach people to write software that passes tests, and not think about the whole range of possible situations it has to deal with.

Good programmer writes software that not only behaves properly in all known corner cases, it works properly in those corner cases that he can't imagine. After some level (that is supposed to be long passed at the time of graduation from university), all trivial ways of improving quality already reached their limit and became irrelevant. Tests are among those methods. All further improvement can be only achieved by becoming an aforementioned good programmer, and tests don't in any way help with this. Just the opposite, writing code as if it will never be tested and there is no way to test it, is the only way to keep yourself from avoiding mistakes (even if the code is tested after that).

Also you are wrong that tests cannot guarantee anything. When a human guarantees something to another human it is assumed to not be some kind of absolute statement. This *is* the common use (legal and general) of the term. Because otherwise you need some kind of perfect god like being which can evaluate products/services.

So the purpose of tests is to create an impression of "proof" to people who don't know any better?

There is nothing wrong with testing products in QA, alpha testersm beta testers, etc. -- they just might find something by pure luck or pure stupidity of the programmers. There is nothing wrong with programmers writing mini-tests to check if they are completely off-base in their thinking. However those things have nothing to do with improvement of development process. They are helpful because they often catch brain farts, but they guarantee nothing. The better are programmers, the least helpful are tests, and long before programmers become perfect, tests become worthless. If a company can benefit from including mandatory tests into development process, it means that it's full of incompetent programmers, who should not be there in the first place. Same applies to marathon runners and crutches, and many, many other things that "assist" in a way that only works when something deeper is terribly, terribly wrong.

Re:wow

[Alex Belits]

keep yourself from avoiding mistakes

Should be keep yourself from making mistakes, obviously.

Re:wow

[0ld_d0g]

They are arbitrary checks for randomly selected egregious mistakes. Passing tests lulls developers into thinking that their software works correctly when it really does not.

That is the way /YOU/ see tests. Most people use them to verify that very rule that you're talking about. Testing is not some random code that people throw together. It can be just as carefully written and as planned, if not more, than the actual software being tested.

Why not? For tests to be meaningful, the difficulty of writing them well exceeds the difficulty of writing formally-proven software. Step down from there, and sufficiently careful logical thinking (a step down from formal proof) will always beat an informal test (a step down from complete test) made with the same level of effort.

The development of tests can be done with multiple smart people. They can divide up the program however they want and implement tests for it. This is impossible with formal proof. Without a several iterations you will be unable to even divide up the code the be formally analyzed in parallel. Tests will always be a faster and commercially more superior solution.

Practice shows that they do not improve quality, they teach people to write software that passes tests, and not think about the whole range of possible situations it has to deal with.

Then that means those people sucks at writing tests.

So the purpose of tests is to create an impression of "proof" to people who don't know any better?

Depends on what you're doing. For a large softwares like Windows there are thousands of outstanding bugs and 90% of the users would not even recognize those bugs. Software will still be shipped and the bugs can be addressed in future updates. If you want a zero bug criteria then no software will ever ship on time. And all the companies will go bankrupt because there is no supply of software developers who are able to write that kind of software.

The better are programmers, the least helpful are tests, and long before programmers become perfect, tests become worthless.

This will never happen. Currently majority of software developers are employed by commercial companies. Their aim is to improve profit, not to make their employees better developer. Sometimes those two things can align because higher quality code means more profit, but that happens only a minority of the time. The other large section of software developers will be in academia. They have no clue about software development. They have never shipped anything robust because they have such low number of users that every code path is never tested in their code.

Re:wow

[Alex Belits]

That is the way /YOU/ see tests.

This is also what happens when people use tests.

Most people use them to verify that very rule that you're talking about.

If rule can be expressed, it's possible to create code that always follows it. It may be possible to create code that verifies it (and therefore can be used for testing), but it's always more difficult and often plain impossible (ex: halting problem).

Testing is not some random code that people throw together. It can be just as carefully written and as planned, if not more, than the actual software being tested.

And then the result is still inferior to software being written right to begin with. However more likely tests are buggy, too, even if for some insane reason they are less buggy than software being tested. Tests only help to improve quality if they are written by a programmer far superior to the programmers who write software. This is why it works with teaching students. In all other situations they are merely an unreliable way to reduce the number of massive mistakes. Useful in the same way a guardrail is useful on a straight road -- its presence reassures the drivers that there is something at the edge of the road, and once in a blue moon someone will slam in it and won't die instantly in a ditch, but overall effect on the number and severity of incidents is negligible.

The development of tests can be done with multiple smart people.

And it would be more productive to just let those people write software.

They can divide up the program however they want and implement tests for it. This is impossible with formal proof.

Of course, it's possible! Software should be modular, with interface specifications defined for each module. Then all formal proofs or informal checks have to be done separately for each module, and for interaction model itself. Like with my example with the solution to a problem with debugging logs, once it is defined that a single interface must be used for all debugging logging, it's trivial just by looking at the code to determine that:

1. Debugging logging is never activated by default in production version.
2. All debugging information is logged through debugging logging interface.

So one implementation and one code review gives you very high certainty that all misbehavior related to debugging logs (information disclosure, performance drop, runaway use of space, use of log files as a part of privilege escalation or denial of service, etc.) will not happen on a production system in default configuration. Without this, you can test code until you are blue in the face, and billions of possible instances of debugging output will slip through your tests because they would be still indistinguishable from all other I/O.

When software is designed as a giant blob of spaghetti code, the problem is not with insufficient testing.

Without a several iterations you will be unable to even divide up the code the be formally analyzed in parallel.

If it is not already divided, it's designed poorly to begin with.

Tests will always be a faster and commercially more superior solution.

A solution to create false impression of correctness -- yes.

Then that means those people sucks at writing tests.

Just like in a well-known Kernighan's quote about debugging being twice as hard as writing code, so is writing tests (though I don't think, it's merely "twice", it varies with expected coverage). So everyone sucks at writing tests, and this is why a superior programmer can "rescue" an inferior one by providing tests. However this is like trying to use monkeys for building roads -- can work with enough effort applied by humans directing them, but it's easier to just let humans build those roads in the first place.

Ad the log file in question is ...

[knapkin]

What? Something seriously missing from the summary!

Typical Apple

[toadlife]

Copying features from Microsoft products again.

Re:Typical Apple

[MicroSlut]

Good job. You found an eleven year old Microsoft non-OS software vulnerability that stores passwords in plain text when the service pack for the software is installed in a non-recommended mode.

Re:Typical Apple

[toadlife]

Lighten up Shirley. It was meant as a joke.

Re:Typical Apple

[quenda]

Copying features from Microsoft products again.

And ripping off open source without credit.

Those idiots at Microsoft

[Anonymous Coward]

If they weren't such stupid programmers and had paid any attention to security, this wouldn't have happened.

Re:Absolute garbage!

[mark-t]

There is not a single reason not to use Gamemaker.

I might suggest that your endorsement might have given several people a reasonably compelling reason not to use it.

If you sincerely are advocating that product, you may want to consider altering your sales pitch so that you don't sound so much like a snake-oil sales vendor. Otherwise, you just sound like a raving lunatic.

Of course... if that was your intent. Carry on. Expect to be downmodded, however.

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.

Hi bonch!

[Anonymous Coward]

What are you upto today bonch? Anything exciting?

Just more shilling? :( Well that's too sad. Please take it easy today and don't shill too much bonch!

What a pain!

[techdolphin]

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."

How soon until a fix?

[mark-t]

Because this is problematic if one's login password on a mac happens to be their login password for everything else inside of one company.

Odds are that firewalls will protect outsiders from being able to snoop, but what's to stop somebody on the inside from doing a little covert snooping to discover the administrator's password, and using that to his own advantage in some way?

I would rather hope that Apple addresses this issue before the work day commences tomorrow, because now that this vulnerability is publicly known, it's a shoo-in that it is going to be exploited.

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.

Re:Relatively few?

[jo_ham]

Lion suggests that to you when you upgrade if you have the old version of FileVault running.

Re:Nonsense!

[Anonymous Coward]

doesn't get viruses

Correction: doesn't get PC viruses.

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.

Re:Just a bug

[magamiako1]

The Apple fanboys are still trying to think of something to say, something they can pick on MS for--because security isn't the answer now.

Right now they're hiding in waiting. Some of the more die hards may move to Linux over time.

Re:Just a bug

[mikael_j]

I've seen several non-Apple tech news sources pick this story up. They sure do love a good "Apple goofed" story.

I think the only reason it hasn't gotten more play is because while this is a serious bug it isn't one that affects a lot of users. It only affects those who have upgraded from an earlier version of OS X and have chosen to continue using the old version of FileVault instead of upgrading to the newer whole disk encryption one.

Java's fault /s

[sproketboy]

Must be. Apple can do no wrong.

Maybe it wasn't an accident.

[elucido]

Underhanded C contests prove that it's possible to slip a bug into a critical piece of software in such a way that it looks like programmer error. This allows for plausible deniability from the company (Apple).
http://en.wikipedia.org/wiki/Underhanded_C_Contest

Dear Rich Bastard...

[Anonymous Coward]

It really happened. I was there. Hundreds of letters went out like that because the developer
put some cutesy greeting in his code for debug purposes at the bank where he worked.

The moral of the story is that a good developer never exposes himself in such a way. Never.
This is just sloppy - nothing is perfect. But I don't trust something as important as encryption
to a bunch of novices in a closed architecture like that. It's just as silly as Microsoft's pretend
encryption. It's too easy to circumvent - just google it.

Very sad...

Re:Absolute garbage!

[Anonymous Coward]

Don't bait the meth-fueled troll, and especially not from a named account if you know what's good for you. Have you been paying attention to just how widely he's doing this, how many accounts here (at least six as of right now), how many other sites he's poisoned? There's also a bizarre theistic reference in most of the account names used. Don't debate this freak, use the Flag button next to EVERY one of his posts in every guise, and let the admins with better weaponry deal with him.

FLAG this freak's posts in every one of his guises

[Anonymous Coward]

This has been a recurring spammy problem here at Slashdot for days now, and his insane posts aren't limited to Slashdot; he's poisoned other sites in the same fashion. Search for "gamemakerdom" and you'll begin to see the larger picture. There are more than 6 Slashdot accounts alone involved now, apparently all created and controlled by the same person. He uses one account to make an initial post, and then posts replies to himself using other accounts to make it appear like a conversation. He also replies to criticism, and if you reply from a named account he may search for your other posts and reply to some of them to spread the poison further (that was done to me).

Modding his posts down is fine to hide his behavior from most people, but it will not stop him. Use the Flag button on every one of his posts, in every guise he uses, to bring the full scope of what he's doing to the attention of the Slashdot staff. Hopefully they can not only remove his existing accounts but figure out a way to ban him from creating more and finally put a stop to this mindless spam.

It's a feature.

[mr_lizard13]

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!

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?

[michelcolman]

What if they just hash the password, add a salt (or timestamp), then hash it again? The server only has to store the hashed password then.

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.

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

[Eponymous Hero]

what if they just hashed their corned beef and added salt? add some eggs and a glass of juice, that's a tasty breakfast. and more beneficial than the entire argument being had here.

Maybe Apple doesn't have a QA dept ?

[Anonymous Coward]

Must be a new thing at Apple - if it compiles - ship - make big buck
Tech support? just let the internet support our release

       

So staying with Snow Leopard WAS smart afterall!

[RubberDogBone]

After a year of having to endure "Your old Mac Core2 Solo 32bit can't RUN 64bit-only Lion! Loser!" comments, now, NOW I can say, there is a darn good benefit to staying behind the times! This security issue does not affect me!

This totally refills my Apple User Smugness supply.

What Slashdot Posters Hear

[cstacy]

Bad Summary! Blah blah Modpoints blah blah TFA blah blah Apple blah blah...

Re:What Slashdot Posters Hear

[cstacy]

omg oops ww

Re:What Slashdot Posters Hear

[Anonymous Coward]

And yet somewhow still so appropriate!

Re:FLAG this freak's posts in every one of his gui

[Anonymous Coward]

But there's no way any development system can compete with Microsoft Visual Studio. Microsoft Visual Studio wins the world's best IDE, hands down.

Its not apples fault!

[Anonymous Coward]

Apple didnt do anything, their programmer didnt do it ! This is apple, they never get viruses or have accidents or mistakes happen. Just ask apple, they are perfect beings that have evolved beyond a normal humans ability to make mistakes or be anything less than pure glorgious perfection in every way possible.

Re:Absolute garbage!

[mark-t]

I don't know if the post was inappropriate.

Off topic, almost certainly. Idiotic, without a doubt.... but not actually inappropriate or offensive unless a person is offended by people who sound nuts.

There's nothing at all wrong with OSX Lion here

[Gumbercules!!]

... you're just holding it wrong.

B..B...But! MacOS is SECURE by DESIGN

[Anonymous Coward]

This is simply not possible!

MacOS is secure by DESIGN! It is IMPOSSIBLE to get a VIRUS on the Mac! And it's impossible for this password issue to be true!
It's SECURE by DESIGN!

This is not WinDOZE or M$DOS!

Re:Absolute garbage!

[DnaK]

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.

WHY are PASSWORDS part of debugging?

[Anonymous Coward]

I can see no reason a password should be stored during debugging under any circumstance.

This sounds to me more like a case of a hidden feature being discovered.

It's not there for me

[SignOfZeta]

They say that all FileVault (1 and 2) users on 10.7.3 are affected, so I looked at the appropriate file (apparently no one on the Internet is speaking its path and file name) and found the lines marked DEBUGLOG, but my cleartext password wasn't there. Everything else is. I'm not saying the story is untrue; I'm looking right at a bunch of lines that say DEBUGLOG. I guess I somehow got lucky.

Already Reported

[Anonymous Coward]

This issue has been reported to Apple weeks ago and acknowledged.

Re:FLAG this freak's posts in every one of his gui

[Anonymous Coward]

Modding his posts down is fine to hide his behavior from most people, but it will not stop him. Use the Flag button on every one of his posts, in every guise he uses, to bring the full scope of what he's doing to the attention of the Slashdot staff. Hopefully they can not only remove his existing accounts but figure out a way to ban him from creating more and finally put a stop to this mindless spam.

I did try flagging, but the flag button doesn't deem to work.all I get is a "state reason button that only gives me one (speling) option. Agree with your comment though, we don't need this kind of contamination on an already compromised site like /.

My password gets no respect

[Anonymous Coward]

When I took my iMac to the Apple Store to have a bad power supply replaced, they required an account and password to access the machine. Then they mailed it to me. In cleartext.

So many things wrong... where to start?

Re:Nonsense!

[konohitowa]

Whoa. Dude. Like, I think you meant to post that on /r/trees man.

By accident?

[InspectorGadget1964]

Sure he was not paid by M$?

Problem solved, case closed.

[courcoul]

Late last Wednesday 9 May 2012, Apple released the OS X 10.7.4 update for both the client and server editions of the OS, that corrects this error and closes this security vulnerability, amongst other issues. The update is available thru the standard automated Software Update channel as a delta update for 10.7.3 users or as a combo update for all 10.7.x users, or as downloadable updaters found in http://support.apple.com/downloads/#macosandsoftware The delta update is around 400MB (700 for the standalone downloadable) and the combo update is around 1.3GB (1.55 for the standalone downloadable). From the official blurb:

The 10.7.4 update is recommended for all OS X Lion users and includes general operating system fixes that improve the stability, compatibility, and security of your Mac including fixes that:
Resolve an issue where the “Reopen windows when logging back in” setting is always enabled
Improve compatibility with certain British third-party USB keyboards
Address an issue that may prevent files from being saved to a server
Improve the reliability of copying files to an SMB server
For detailed information on this update, please visit this website: http://support.apple.com/kb/HT5167.
For information on the security content of this update, please visit: http://support.apple.com/kb/HT1222.