Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Apple Security Blunder Exposes Lion Login Passwords In Clear Text

Comments Filter:
  • Great (Score:5, Funny)

    by lemur3 (997863) on Sunday May 06, 2012 @02:12PM (#39909357)

    now i can find out what my password is.

    ive been resisting a reboot for ages!

    • Re:Great (Score:4, Informative)

      by cbreak (1575875) on Sunday May 06, 2012 @02:15PM (#39909389)
      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.
  • malware (Score:4, Funny)

    by Anonymous Coward on Sunday May 06, 2012 @02:12PM (#39909359)

    apple even ships their own malware.

    • Re:malware (Score:4, Insightful)

      by mr100percent (57156) on Sunday May 06, 2012 @02:39PM (#39909553) Homepage Journal

      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 (Score:5, Funny)

        by IamTheRealMike (537420) <mike@plan99.net> on Sunday May 06, 2012 @03:02PM (#39909697) Homepage
        Oh yes, you're right. It sounds like it only impacts people who actually want / need security. So that's OK then.
        • Re: (Score:3, Informative)

          by mr100percent (57156)

          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.

          • by epine (68316)

            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 u

            • Re: (Score:2, Insightful)

              by mr100percent (57156)

              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 (Score:5, Informative)

          by Smurf (7981) on Sunday May 06, 2012 @03:15PM (#39909763)

          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.

        • by Bert64 (520050)

          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.

    • Expect it announced as a feature, a friendly user password lookup. They got away with worse things like kernel crashing, OS without copy&paste..
    • 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 [wikipedia.org]

  • by jo_ham (604554)

    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.

  • by msobkow (48369) on Sunday May 06, 2012 @02:16PM (#39909397) Homepage Journal

    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.

    • by Kjella (173770) on Sunday May 06, 2012 @03:11PM (#39909731) Homepage

      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.

    • by 140Mandak262Jamuna (970587) on Sunday May 06, 2012 @03:40PM (#39909903) Journal
      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.

    • by gweihir (88907)

      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 debu

    • by bored (40072)

      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 so

  • ...There is app for that.
  • by Zapotek (1032314) <tasos@laskos.gmail@com> on Sunday May 06, 2012 @02:24PM (#39909443) Homepage
    ...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.
    • by gweihir (88907)

      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 ordin

  • by bhlowe (1803290) on Sunday May 06, 2012 @02:26PM (#39909461)
    I wonder what the source code or version control comments said..
  • 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

    • by jo_ham (604554)

      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 persona

      • by Cinder6 (894572)

        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 did

        • by jo_ham (604554)

          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.

  • 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."
  • Not really (Score:5, Informative)

    by mr100percent (57156) on Sunday May 06, 2012 @02:37PM (#39909541) Homepage Journal

    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.

    • Relatively few? (Score:5, Interesting)

      by WD (96061) on Sunday May 06, 2012 @04:45PM (#39910225)

      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.

      • by jo_ham (604554)

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

  • by gcnaddict (841664) on Sunday May 06, 2012 @02:50PM (#39909623)
    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.
    • by Anonymous Coward on Sunday May 06, 2012 @03:17PM (#39909773)

      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.

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

    • by macs4all (973270)

      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?

  • by phonewebcam (446772) on Sunday May 06, 2012 @03:16PM (#39909767) Homepage

    ...you're passwording it wrong.

  • What? Something seriously missing from the summary!
  • by toadlife (301863) on Sunday May 06, 2012 @03:35PM (#39909885) Journal

    Copying features from Microsoft [microsoft.com] products again.

  • by Y-Crate (540566) on Sunday May 06, 2012 @04:14PM (#39910109)

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

  • 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

  • Just a bug (Score:5, Insightful)

    by lucm (889690) on Sunday May 06, 2012 @05:47PM (#39910515)

    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.

    • by mikael_j (106439)

      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.

  • by mr_lizard13 (882373) on Sunday May 06, 2012 @07:21PM (#39911055)
    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!
  • 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.

  • Bad Summary! Blah blah Modpoints blah blah TFA blah blah Apple blah blah...
  • 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.

Brain fried -- Core dumped

Working...