Slashdot Mirror
13-Year-Old Password Security Bug Fixed
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.
really doubt it...
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
http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug
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.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
A 13 year old bug is no match for a 13 year old hacker.
This is a myth that should have been debunked years ago. I don't know why people still believe it. It only holds water if people are actively looking at the code and noticing the bugs, which in many cases they are not.
Posted anonymously because this is Slashdot and ESR is a God who can never be wrong.
Everybody tells me they still see asterisks ... :shrug:
My guess is you don't. You'll have to create a new function and leave the old one there. Otherwise anyone who does the fix no longer has matching hashes for whatever it was they used the hash for originally.
Slashdot might be getting a lot of unwanted traffic from Google search queries containing "13-year-old" now...
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.
The irony is that it seems this bug was discovered by developers of John the Ripper, a tool for cracking passwords.
In a sign that many eyes don't really make (security) bugs shallow
Also proof that security through obscurity works.
What the fuck did you expect, excellent design practices and high quality code?
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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?
Lurking at the bottom of the gravity well, getting old
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Eric Raymond's "Cathedral and the Bazaar" postulated (without proof) that open source would be inherently more secure because so many more people would be looking at it, and that they would be able to remove the bugs. Of course, that totally misses the point of good software engineering, which is not to put the bugs into the software in the first place!
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.
It appears that whoever wrote the summary didn't read the links they provided:
/. I just think the summary was trying to tie in too much (old bugs blah blah) and misrepresented the impact and fix.
"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
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 whether the patch gets applied to end users' systems.
Three Squirrels
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.
So then the real question is... When was it fixed in the "BSD's"???
Ducks:)
They would never put in a backdoor to their web server that claimed Netscape engineers were weenies that went undetected for over 4 years. Oh, wait, my mistake... they did do that. http://news.cnet.com/2100-1001-239273.html
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.
...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
It seems like Ulrich Drepper was right opposing, in rather harsh words, my suggestions to include bcrypt in glibc. My bad.
are gonna be so pissed. Enjoy.
This ain't no upwardly mobile freeway This is the road to hell
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. 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 starters it only affects passwords that use 8-bit characters, so passwords typed by anyone using a US-English keyboard still produce the same hashes as the correct Blowfish implementation.
For passwords of length n*4-1 (3, 7, 11, 15, ...), 8-bit characters in certain positions will result in some characters being ignored by the hash function. This makes it possible (though still not easy) to produce a collision, i.e. multiple different passwords that result in the same hash.
It's bad, but I want to stress that using even a buggy crypt_blowfish for password hashing is still a quantum leap over the single-hashed MD5 or SHA1 that you were seeing literally everywhere in the PHP world just a few years ago.
Never approach a vast undertaking with a half-vast plan.
"Gawker used this broken implementation, which replaced all non-ascii characters with question marks prior to hashing". link
"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 equivalent to all other such passwords of the same length". link
Didn't anyone ever test the algorithm to see if if functioned as designed, as in producing unique hashs for very similar passwords. Would be most important as part of an encryption suite ..
Another Linux FAIL.
Open source doesn't guarantee the code will get looked at. However, closed source does guarantee that it WON'T get looked at.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
"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.
PHEM - party like it's 1997-2003!