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.
Uh-huh. Because "In a sign that many eyes don't really make (security) bugs shallow" is such an unbiased opening for the story.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
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
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).
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?
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?