Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Bug Open Source IT Linux

13-Year-Old Password Security Bug Fixed 130

Posted by timothy from the not-13-year-old's dept.
arglebargle_xiv writes "In a sign that many eyes don't really make (security) bugs shallow, a thirteen-year-old password-hashing bug that affects (at least) PHP, some Linux distros (Owl, ALT Linux, SUSE), and a variety of other apps has just been patched. This problem had been present in widely-used code since 1998 without anyone noticing it." Better late than never; reader Trailrunner7 points to this article outlining the dangers of old exploits, given old code for them to toy with.
This discussion has been archived. No new comments can be posted.

13-Year-Old Password Security Bug Fixed More

13-Year-Old Password Security Bug Fixed

Comments Filter:

  • At least it was fixed (Score:3, Interesting)

    by mangu ( 126918 ) on Monday June 20, 2011 @06:54PM (#36507520)

    How many bugs are there in commercial software that we don't know?

    What we do know is that there are many exploits for commercial software. The vendors claim that such exploits only exist because that software is more popular, but this does not explain why Apache doesn't have four times more exploits than IIS [netcraft.com]

    • Re:At least it was fixed (Score:4, Insightful)

      by MobileTatsu-NJG ( 946591 ) on Monday June 20, 2011 @08:57PM (#36508402)

      How many bugs are there in commercial software that we don't know?

      Heh.

      Monday:

      "Really old bug finally patched in some popular Microsoft software!"

      This shows how terrible proprietary software is!

      Tuesday:

      "Really old bug finally patched in some popular OSS!"

      This shows how terrible proprietary software is!

      • Re:At least it was fixed (Score:4, Interesting)

        by Requiem18th ( 742389 ) on Monday June 20, 2011 @09:39PM (#36508638)

        In all fairness, software is only as secure as the culture behind it. Everybody using PHP knew of this bug for ages, just, nobody gave a damn. Except those who didn't know that also didn't give a damn.

        PHP has never been crazy about security, what else do you expect from a runtime that once let you insert arbitrary variables into the script namespace?

        The few people using PHP who care about security that much are using DIY password management anyway.

    • How many bugs are there in commercial software that we don't know?

      And how many bugs are there in FOSS software that we don't know? The answer "none, because many eyes..." does not sound so convincing now.

      • Re: (Score:2)

        by cduffy ( 652 )

        The answer "none, because many eyes..." does not sound so convincing now.

        Who ever said "none, because many eyes..." rather than "fewer, because many eyes..."?

        It's a strawman. Nobody sensible ever made that claim.

      • "Many eyes" doesn't solve everything, and nobody claimed it did. One thing it does do is shorten the 'half-life' for bugs to be found. Bugs tend to be found faster when many eyes are looking at the source. Some can remain for a long time - obviously - but according to every metric I've seen, open-source code tends to have noticeably fewer bugs than proprietary code.

  • Not unprecedented (Score:3, Interesting)

    by slimjim8094 ( 941042 ) on Monday June 20, 2011 @06:56PM (#36507524)

    http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug [osnews.com]

    These kinds of stories make me nervous, because I always assume that crackers know about these and are using them secretly.

    Though this is obviously not a OSS issue. Were this Windows, it might not have been found at all.

    • Re: (Score:2, Funny)

      by martin-boundary ( 547041 )
      Exactly. In Windows, you'd simply be told to reboot frequently enough so the password bug doesn't get triggered :)

      • Exactly. In Windows, you'd simply be told to reboot frequently enough so the password bug doesn't get triggered :)

        Nah, windows already reboots frequently enough. Its now a "feature".

    • Re: (Score:3)

      by blair1q ( 305137 )

      I always assume that crackers know about these and are using them secretly.

      And when caught at it publish everything they have and blame you for not securing your system.

    • Certainly not unprecedented:
      17-year-old issues in NTLM not many people know about (now fixed)
      http://www.ampliasecurity.com/research/OCHOA-2010-0209.txt [ampliasecurity.com]
      http://www.ampliasecurity.com/research/NTLMWeakNonce-bh2010-usa-ampliasecurity.pdf [ampliasecurity.com]

    • Re: (Score:2)

      by satuon ( 1822492 )

      If crackers were using them a lot and there were viruses in the wild that were using them, then people would have quickly found out about those bugs and patched them. I think the reason they stayed hidden for such a long time was nobody really exploited them.

    • Re: (Score:3)

      by daid303 ( 843777 )

      If you read the report, you'll notice that the bug introduces a slight incompatibility and a slight reduction in password strength if you use the 8th bit (read none-latin) characters. With blowfish (one of the many possible hash functions)

      Yes, it's a bug. Yes, it needs to be fix. No, it's not OMG we're going to be pwned!

    • Re: (Score:2)

      by sjames ( 1099 )

      This one certainly needed fixing, but probably had a fairly small impact. Few passwords have the 8th bit set in any of the characters.

      • If you use Blowfish
        If you use this library
        If you use extended chars in a password

        then sometimes (1/8 chance) a small part of hash is ignored reducing the strength slightly ...

        A lot of if's to not very much effect ...

  • A 13 Year Old Bug ... (Score:3)

    by WrongSizeGlass ( 838941 ) on Monday June 20, 2011 @06:59PM (#36507554)
    A 13 year old bug is no match for a 13 year old hacker.

    • That's what they meant by "13-year-old password security bug"! Turns out you could get access to any system by screaming "Cockfag!" into the microphone.

  • Slashdot might be getting a lot of unwanted traffic from Google search queries containing "13-year-old" now...

    • Re: (Score:1)

      by mangu ( 126918 )

      Slashdot might be getting a lot of unwanted traffic from Google search queries containing "13-year-old" now...

      At least Slashdot will not be alone [google.com]

    • You know, it's weird, but ya, it'll get you traffic.

      One of the things I do is run a mainstream news site. In that, pedophiles get bused for all kinds of things. Those end up being keyword rich pages that seem to come up for all kinds of fucked up variations of what pedophiles look for. There's nothing like reviewing your logs to have an amazing disgust for society as we know it.

      There is only one thing I feel good about. On some keywords and phrases, we come up

      • There is only one thing I feel good about. On some keywords and phrases, we come up in the top 3 results. So the pedophiles may be looking for underage smut, but instead they're presented with news stories about other pedophiles going to jail.

        Which presumably just makes them into more careful pedophiles who are harder to catch. Good work!

  • I can't easily tell exactly what the bug is here, but it appears to require that you have your password algorithm set to blowfish and use passwords with non-ASCII characters? That doesn't seem a likely combination on any modern Linux installation.

    • Re: (Score:3)

      by blair1q ( 305137 )

      In the US maybe.

      Though, yes, it implies you're using accented characters and have blowfish as your algorithm.

      So it's a vulnerability enabled by a very small portion of a very small population.

      Which is why it lasted for 13 years with nobody caring much, except academically.

      But, if you knew you could use 8-bit characters, and you generated your passwords randomly, this could affect half of your password space. Which could be significant if your passwords were kept in compartmentalized files that themselves a

      • But, if you knew you could use 8-bit characters, and you generated your passwords randomly, this could affect half of your password space.

        If you generate your passwords randomly, you are going to have a hard time entering them from a lot of keyboards and OS. For example, I don't seem to be able to enter this \xa3 "pound sign" on this OS using the "alt+0163" Windows hack.

        In any case, if you cut the number of selections for each character in a password in half, you cut your password space by 2^n, where n is the number of characters in your password.

    • I read the linked comment (not much of a description there), but it does appear that it is triggered by "8 bit characters" in passwords.

      It talks about "pound sign" as the test, but claims that it is "\xa3 in C". I didn't know that C had a different definition for ASCII characters than ASCII does, and in my ASCII tables the octothorpe is 0x23. Ahh, maybe a language difference, and the "british currency symbol" is what he is referring to.

      Or maybe this points out the error of relying on non-standard characte

      • Re: (Score:3, Insightful)

        by simcop2387 ( 703011 )
        They mean the british pound sign, not the octothorpe # . Ain't language fun?

      • Re: (Score:1)

        by hattig ( 47930 )

        Slashdot strips it, it's a known bug with Slashdot since 1998, and still not fixed. What's that? 13 years? I think the HTML works ... £

        It also appears that if this library was used for any other hashing, that this bug would arise. And if that included binary files then it almost certainly would have been triggered.

        The main issue is that it consistently generates the wrong hash, so that it actually appears to work fine.

        However the bug fix means it now generates the correct hash. Which is going to be di

        • Slashdot strips it, it's a known bug with Slashdot since 1998, and still not fixed. What's that? 13 years? I think the HTML works ... £

          I can't believe an open source coded site like slashdot could have a 13 year old bug.

  • In a sign that many eyes don't really make (security) bugs shallow

    Also proof that security through obscurity works.

    • Re: (Score:3)

      by arth1 ( 260657 )

      Also proof that security through obscurity works.

      Evidence, perhaps, but certainly not a proof, unless you can prove that black hats haven't exploited this in the last 13 years.

      Contrary to popular belief, most black hats aren't in it for the fame, but for other reasons including personal satisfaction, thrill and in some cases monetary gains. And when you're not in it for the fame, you don't disclose what you've found -- you guard the secret carefully so you can continue to exploit it. Yes, for thirteen years. I know of active backdoors far older than th

      • Re: (Score:2)

        by mangu ( 126918 )

        when you're not in it for the fame, you don't disclose what you've found -- you guard the secret carefully so you can continue to exploit it. Yes, for thirteen years

        What you are saying is that there are worms and viruses out there using it, there are botnets based on that bug? Interesting, why has no one noticed anything so far?

        • Re: (Score:2)

          by arth1 ( 260657 )

          Exploits are more than botnets and viruses. There are people who log in to a former employee's server every week, copies a few documents, and leave without a trace. For years.
          Some spy on exes, bosses or celebrities just for the thrill.
          Some skim a little CPU power or storage here and there.
          Some do single account transfers that aren't discovered.
          Others simply enter machines because they can, again without running botnets and viruses.

          • Re: (Score:2)

            by mangu ( 126918 )

            There are people who log in to a former employee's server every week, copies a few documents, and leave without a trace. For years.

            And those, invariably, use social engineering. You don't break a password hashing function when all you have to do is read the post-it stuck under the table.

            • Sometimes you don't want to put your fingers anywhere near the site, be it for building security or whatever the reason. The continued proliferation of people who consider that you can just beat someone with a rubber hose for a password, or read it off a post it note so who would bother breaking this algorithm are entirely unhelpful to fostering a secure environment. Just because there are easy methods of physical access, doesn't mean every cracker out there is using them, just like not every cracker out th

      • You're doing at least as well as the "intelligence" communities. Seems that all their secrets get leaked nowadays. ;>)

    • Re: (Score:3)

      by Jonner ( 189691 )

      In a sign that many eyes don't really make (security) bugs shallow

      Also proof that security through obscurity works.

      How is this proof of that? For all we know, crackers have been exploiting this vulnerability for years.

    • This is a slight reduction in password strength if you're using Blowfish and have a british pound sterling sign in your password, rather than a normal password and using the standard salted MD5 hash or deliberately changing from MD5 to SHA1, which is the only likely change most people would make. It almost never happens and doesn't create an instant break when it does; it's effectively a non-issue, but you know.. if it's loose, tighten it up, I don't care if it's going to fall off or not.

    • Re: (Score:2)

      by sjames ( 1099 )

      More like bugs that are rarely triggered enough don't cause much trouble.

  • What the fuck did you expect, excellent design practices and high quality code?

    • Uh, crypt_blowfish is pretty definitely not written in PHP. You know you can't just scan the summary for buzzwords and draw conclusions without actually reading and comprehending it don't you?

    • Re: (Score:2)

      by Simon80 ( 874052 )
      Thanks for making me laugh, but at a glance, it looks like the bug is actually in this package [openwall.com], not PHP.

    • Re:Come on, it's PHP (Score:5, Insightful)

      by Firehed ( 942385 ) on Monday June 20, 2011 @08:13PM (#36508150) Homepage

      To be fair, it's hardly PHP's fault that the shared library's implementation was broken. The primary benefits of using a library (not reinventing the wheel, wisdom of many, etc.) are generally outweighed by occasionally inheriting one of their bugs. Especially since you also inherit their bugfixes. While the core PHP team is actually quite well accomplished at security (even if PHP enables any idiot to make insecure sites by virtue of being easy to learn), I'd still rather them use widely adopted libraries than come up with their own implementation.

    • Re: (Score:3)

      by kat_skan ( 5219 )

      What the fuck did you expect, excellent design practices and high quality code?

      Honestly? A second function named blowfish_real_hash_string.

  • crypt_blowfish (Score:5, Informative)

    by TopSpin ( 753 ) on Monday June 20, 2011 @07:22PM (#36507744) Journal

    The common thread among these systems (PHP, (Open)SUSE, etc.) is the use of crypt_blowfish, a flawed implementation of the blowfish hash function. Constructing passwords that collide is easy due to a sign extension bug. A SUSE user can observe the use of blowfish in /etc/default/passwd, where the default value of CRYPT_FILES is 'blowfish'.

    To be clear, the problem is a flawed implementation; the blowfish hash algorithm itself remains sound.

    The PHP crypt() function supports several common hash algorithms including blowfish. The PHP 'documentation' implies that DES is default. Anyone care to speculate on the likelyhood of widespread blowfish use by public sites?

    • Re: (Score:1)

      by Anonymous Coward

      Just to clarify something: there is no "blowfish hash function". Blowfish is just a (symmetric) block cipher with a relatively expensive (and memory-hungry) key schedule.

      Although it's true there are several ways of turning a block cipher into a hash function (via Merkle-Damgaard construction, for instance), they are obviously not the same.

      In a nutshell: there is no "blowfish hash function", but a "hash function based on Blowfish".

    • Anyone care to speculate on the likelyhood of widespread blowfish use by public sites?

      Wide. Many major PHP projects have been moving toward Openwall's PHPass algorithm that uses Blowfish as its preferred hashing algorithm. Note that even with this bug it's still better than the unsalted MD5 or SHA1 hashes that most projects were using previously. Today any of those old hashes can be brute-force cracked by a $200 GPU in about a day.

    • Allowing the use of single DES should also be considered a security bug.

    • OpenSSL has a blowfish cipher, which I assume doesn't have the same bug. If your system has OpenSSL, but not OpenWall, would PHP use OpenSSL?
      The OpenWall site says that PHP 5.3 uses it, but is it included in the PHP binary so OpenSSL isn't an option?

  • http://www.ampliasecurity.com/research/OCHOA-2010-0209.txt
    http://www.ampliasecurity.com/research/NTLMWeakNonce-bh2010-usa-ampliasecurity.pdf

  • These moved from DES to MD5 passwords a long time ago and were never vulnerable to this.

    • Many many moons ago I seem to recall the documentation saying not to use the passwd function and to use MD5 for password storage anyway.

  • no reason to conclude open source is not secure (Score:4, Insightful)

    by binarstu ( 720435 ) on Monday June 20, 2011 @07:55PM (#36508024)
    Concluding, from this bug, "that many eyes don't really make (security) bugs shallow" is absolutely not justified. This is a single anecdote (sample size = 1), and there is no good or easy way to compare this to what would have happened had the code been closed. One could just as easily claim that if the code were not open, it would have been 10 more years before the bug was uncovered.

    • Re: (Score:3, Informative)

      by tangent ( 3677 )

      The famous quote doesn't apply to unidentified security flaws.

      The point of the quote is that when someone points out buggy behavior, the many eyeballs will quickly pierce to the heart of the bug and find a way to fix it. With fewer eyes, really nasty bugs often remain unfixed long past the time they are first identified because none of the brains behind the few eyeballs that have looked at it have figured out the fix yet.

      The nature of most security bugs is that their existence is not obvious. Most software

      • Re: (Score:2)

        by Steeltoe ( 98226 )

        You sure? Because I could've sworn security is nothing without taking into account unidentified security flaws.

        Or else, you could argue the best security is blinding your eyes, screaming: "LALALALALALALA, no bugs heeere!"

        This is why privileged account is so silly to be logged in to, something Windows Vista and 7 tries to fix using UAE. Unix has been superior in that department since day 0 using unprivileged accounts by default (ie. in the default Ubuntu-install). Even if there is a vulnerability, ie. in the

  • Umm, It's not an official fix (Score:5, Interesting)

    by sdguero ( 1112795 ) on Monday June 20, 2011 @07:57PM (#36508032)
    It appears that whoever wrote the summary didn't read the links they provided:

    "I am going to provide an official fix for crypt_blowfish (likely the one-liner plus added tests). I thought I'd bring the issue up on oss-security sooner rather than later."

    So, the bug appears to have been found today and the developer has a one liner solution but hasn't released a patch. I think the summary did a piss poor job talking about what is affected by the problem too... specifically crypt_blowfish, which i know my company uses for a few things. It is interesting to know that this hash is now far weaker than originally thought until it gets patched (which will prolly take a long time to make it into major distros).

    Anyway, i'm done bitching, definitely a story worthy of /. I just think the summary was trying to tie in too much (old bugs blah blah) and misrepresented the impact and fix.
  • Seems to me that there are at least two different questions here, and that most of these comments confuse them.

    The first, and perhaps more intriguing, is how a bug like this could sit undetected for years. Regardless of whether it's proprietary or Open Source software, bugs will remain until someone, somewhere finds them.

    The second, and this is where Open Source arguably has an advantage, is how soon a vulnerability is patched once it has been found - in this case pretty fast.

    And of course wheth

    • The first, and perhaps more intriguing, is how a bug like this could sit undetected for years.

      It does seem odd that people haven't run fuzzed data against a number of different implementations of blowfish and not noticed differing output. I'd have thought that would be a fairly normal thing for someone developing a crypto algorithm implementation to do.

      • It does seem odd that people haven't run fuzzed data against a number of different implementations of blowfish and not noticed differing output. I'd have thought that would be a fairly normal thing for someone developing a crypto algorithm implementation to do.

        Of course. But there are reasons why this didn't happen to a sufficient extent in this case. None of these reasons are valid excuses. There are lessons to learn from this.

        There were test vectors, and the implementation behaved exactly like OpenBSD's on those. The code was in John the Ripper, and it was correctly cracking password hashes from OpenBSD. So it felt like the code was working just as it should have, because it actually did (on the tests that were thrown at it). There was no expectation that

  • Blowing things out of proportion (Score:1, Insightful)

    by Anonymous Coward

    A flaw in an obscure blowfish implementation that isn't used by any of the major distributions is not the dire situation implied here (considering SUSE basically irrelevant anymore). This incident actually reaffirms the many eyes philosophy. Few eyes had the motive to look at this particular code, so the flaw was simply not seen.

    • Guess what, I have currently one laptop and two desktops running the latest openSUSE, so for me this bug and platform is not irrelevant.


  • Do people still use the same salt for all hash-functions? I assume this can be easily fixed if you just use an unique value (like the username) as a salt.
  • are gonna be so pissed. Enjoy.

  • The impact of this is actually pretty wide. Crypt_blowfish has been gaining popularity as a hashing algorithm in PHP thanks to Openwall's PHPass framework [openwall.com]. Four years ago most PHP projects that I know were still using MD5 or SHA1 to hash passwords. Today those MD5 and SHA1 hashes can be brute-force cracked by free software running on a $200 GPU in a matter of days if not hours. So even a buggy version of Blowfish is still better by far.

    So yeah, it's a wide-ranging bug but not a world breaking one. For start

  • "Gawker used this broken implementation, which replaced all non-ascii characters with question marks prior to hashing". link [openwall.com]

    "Versions of jBCrypt before 0.3 suffered from a bug related to character encoding that substantially reduced the entropy of hashed passwords containing non US-ASCII characters.

    "An incorrect encoding step transparently replaced such characters by '?' prior to hashing. In the worst case of a password consisting solely of non-US-ASCII characters, this would cause its hash to be equivalen

  • Open source doesn't guarantee the code will get looked at. However, closed source does guarantee that it WON'T get looked at.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close