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.
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 that.
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.
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
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 are accessible only to different authorized people. Bureaucracy can get very hairy, in such circumstances.
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 characters for anything. According to my Web Design nutshell book, \£ is the British pound symbol, but apparently FF3 doesn't know it (or /. strips it.) Here are two in a row: -- I see nothing. That's defined in ISO 8859-1, however, and not ASCII.
In any case, it looks like if you use standard ASCII characters in your password you are not a target for this bug.
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 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.
It seems like an acceptable solution to me. Pollute their searches with so many non-smut sites, preferably with news stories about long prison terms, or deaths by the hands of other inmates. Maybe it will help encourage them to make their best attempt at winning a Darwin Award.
Serious? Seriousness is well above my pay grade.
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?
I'm an advanced slashdot user, I don't even read the summary anymore.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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
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.
How are sites slashdotted when nobody reads TFAs?
Honestly? A second function named blowfish_real_hash_string.
They mean the british pound sign, not the octothorpe # . Ain't language fun?
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.
Support my political activism on Patreon.