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.

Comments

At least it was fixed

[mangu]

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

Re:At least it was fixed

[LordLucless]

Uh-huh. Because "In a sign that many eyes don't really make (security) bugs shallow" is such an unbiased opening for the story.

Re:At least it was fixed

[Anonymous Coward]

And why is that not a reasonable opening for the summary?

Isn't the 13 year existence of a security bug in open source code a valid argument that open source does not really mean a product is more secure?

The correct answer for what makes a product secure: Proper coding practices combined with proper configuration.

IMO, Apache is certainly a better choice for a web server, but my opinion is not based on that fact that it is open source and instead based on the fact that it is actually more secure than IIS. Apache appears to be less often compromised, therefore I trust it more. However, if IIS one day holds the mantle of least compromised, then I will certainly consider it (I'm holding my breath though).

Re:At least it was fixed

[XanC]

Isn't the 13 year existence of a security bug in open source code a valid argument that open source does not really mean a product is more secure?

No, it isn't. In order to reach that conclusion, you'd have to compare it against closed-source code. Do you really believe there aren't now and have never been bugs that old in the closed-source world?

Re:At least it was fixed

[MobileTatsu-NJG]

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

[Requiem18th]

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.

crypt_blowfish

[TopSpin]

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:Yikes, how do you roll out a fix for that.

[Firehed]

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.

no reason to conclude open source is not secure

[binarstu]

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:no reason to conclude open source is not secure

[tangent]

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 with security flaws performs its intended function as long as it is run within expected bounds. There is nothing for the many eyeballs to attack until someone tries pushing the software into its operational gray areas, then notices that it does something unwanted or unexpected. As soon as that happens, the quote applies: security holes in open source software are typically fixed soon after being identified.

Umm, It's not an official fix

[sdguero]

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.

Re:Come on, it's PHP

[Firehed]

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:So if I understand this right?

[simcop2387]

They mean the british pound sign, not the octothorpe # . Ain't language fun?