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.
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.
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.
In a sign that many eyes don't really make (security) bugs shallow
Also proof that security through obscurity works.
The 'shut up and submit a patch, bitch' excuse really sucks in the long term.
It only holds water if people are actively looking at the code and noticing the bugs, which in many cases they are not.
But you must admit that in some cases people are looking at the code, while in commercial code no one but those who developed it can take a look.
If you have ever developed code you must have noticed how often you spend hours looking at your code trying to find a bug and then someone comes looking over your shoulder and points out the obvious error.
When did ESR get elevated to Linus' level?
"Maybe this world is another planet's hell"
Aldous Huxley
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.
Have a setting in the tools that call it to use the legacy/broken implementation, and enable it by default in the next patch. See: MySQL old passwords. Or some sort of option that you can set on the function, similar idea.
The better but less compatible way is to put a huge warning on the patch, telling people that if the password doesn't match, check again with the USE_BROKEN_BLOWFISH_IMPLEMENTATION flag passed into the function and if that matches, update your data with the good hash and continue on as normal. That will inevitably piss off a lot of people on shared hosting and/or unmaintained applications but from a security standpoint it's the better option.
How are sites slashdotted when nobody reads TFAs?
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.
Everybody tells me they still see asterisks ... :shrug:
You posted as AC because you're embarrassed about linking to bash.org, right?
Perhaps I'm trolling, perhaps I'm not.
So then the real question is... When was it fixed in the "BSD's"???
Ducks:)
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.
Hey, how did they know my password?
Watch this Heartland Institute video
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.
It only holds water if people are actively looking at the code and noticing the bugs, which in many cases they are not.
But you must admit that in some cases people are looking at the code, while in commercial code no one but those who developed it can take a look.
If you have ever developed code you must have noticed how often you spend hours looking at your code trying to find a bug and then someone comes looking over your shoulder and points out the obvious error.
So you only the specific developer who writes a piece of code gets to look at that code in commercial software? There is no review or management process whatsoever?
In that case, commercial software is certainly more error prone.
To have a right to do a thing is not at all the same as to be right in doing it
"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 ..
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.
Parent said "those who developed it" (the organization), as opposed to "the individual who developed it". One set is doubtless larger than the other.
More to a point -- almost every commercial organization I've been in has had one or two reviewers for each patch. Almost every well-organized open source project I've been in has had patches posted to an open mailing list that everyone is encouraged to review, and then required explicit approval from one or two individuals for merge.
You tell me which of those is the stronger process.
It seems like Ulrich Drepper was right opposing, in rather harsh words, my suggestions to include bcrypt in glibc. My bad.
I also briefly thought of where we would be if Ulrich accepted bcrypt into glibc. I have several points to make:
1. It is likely that adjusting the crypt_blowfish code to glibc conventions would happen to remove the bug - just like it happened with Perl's Crypt::Eksblowfish (it's based on crypt_blowfish, but the bug is gone). Yes, this does mean that those coding conventions are maybe superior, although it is easier for them to be such when only a more limited number of platforms is considered. There is a lesson for me to learn here.
2. bcrypt is not only crypt_blowfish. glibc could also use OpenBSD's code (lacking this bug) if it looked more suitable by whatever criteria.
3. I just took another look at Ulrich's SHA-crypt.txt, sha256crypt.c, and sha512crypt.c. I don't see any 8-bit characters in passwords in the test vectors. Unless I have missed those, it looks like a bug in SHA-crypt causing similar misbehavior would go unnoticed. No, I do not find it likely that such a bug exists there, but then I also did not find it likely for crypt_blowfish. Anyone wants to test and confirm that there's no 8-bitness bug in SHA-crypt? Please do. But what to test Ulrich's SHA-crypt against? Does Solaris use the same code or a reimplementation? (I don't know.) If it's the same code, and no reimplementation exists, then you'd have to try causing collisions or something like that, perhaps with low "rounds" (to make this test reasonably quick). Or create that reimplementation for testing. (BTW, I did the latter in phpass, for testing the correctness of my implementation of its "portable hashes".)
4. SHA-crypt is reasonably good, especially for acceptance due to its use of NIST-approved SHA-2 family functions. However, it does have its drawbacks. bcrypt turned out to be GPU-unfriendly, whereas we should see reasonably efficient implementations of SHA-crypt for GPUs soon (this is being worked on and I see no major obstacles). In neither case a GPU is usable for password hashing on an authentication server (there's too little parallelism in one instance of a bcrypt or SHA-crypt hash computation), even if you had a GPU there, so GPU-unfriendliness is an advantage of bcrypt if you compare it against SHA-crypt.
5. Finally, there have been plenty of security bugs in glibc.
not to mention people who manage to get paid for the hobby of pointing out everyone else's mistakes...
Support my political activism on Patreon.
"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!
Actually, it just really sucks overall.