Serious Crypto Bug Found In PHP 5.3.7

Trailrunner7 writes "The maintainers of the PHP scripting language are warning users about a serious crypto problem in the latest release and advising them not to upgrade to PHP 5.3.7 until the bug is resolved. PHP 5.3.7 was just released last week and that version contained fixes for a slew of security vulnerabilities. But now a serious flaw has been found in that new release that is related to the way that one of the cryptographic functions handles inputs. In some cases, when the crypt() function is called using MD5 salts, the function will return only the salt value."

When will MD5 be let to die as hash for passwords?

[c0lo]

A collision attack exists that can find collisions within seconds on a computer with a 2.6Ghz Pentium4 processor (complexity of 2^24.1) [wikipedia.org] Does salting garbage result in something edible?

Re:Regression tests are for wimps!

[thue]

From the Bug report [php.net]:

> Confirming, some very recent update broke it - right now unit tests fail on SVN. I wonder if nobody run it before release?

So they do have a unit test for that. They just didn't run it before release :).

Poor QA

[TheNinjaroach]

The PHP project has shown some pretty poor QA when it comes to defects in their code.

Hell, their ODBC interface has been returning wrongly typed data [php.net] for years now and nobody on the project seems to care. It's not like ODBC is something brand new and still widely misunderstood.

It's almost like the people who build PHP aren't even interested in maintaining it.

Re:Regression tests are for wimps!

[msauve]

"I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing."

Two things.

1) The problem was found and announced by "the php development community," and presumably found by them, too (admittedly, not prior to release).
2) Why aren't you involved in acceptance testing, if you see a problem with how it's being done?

Not only that

[Chuck Chunder]

It seems the bug was filed before the release was made.

Re:PHP Bug #55439 FIXED (Aug 20)

[nedlohs]

Nope.

$valid will be the return value of crypt which will be true in the non-broken code as well.

$crypted == crypt($pw, $salt)

will always be true in the broken code, if $crypted was created with any old password and the same salt.

Of course if you have existing such password, they'll always match false, so no one is going to be able to change their password and trigger the problem anyway :)

Re:When will MD5 be let to die as hash for passwor

[Arancaytar]

MD5 should be deprecated, but the collision attack only invalidates signatures; it doesn't help you extract a password from its hash.

Currently there is no feasible non-dictionary attack for that (the preimage attack found in 2009 still has complexity >2^120), and the dictionary attacks are defeated by salt. So in this narrow context, yes.

(Of course, this would end if a somewhat more efficient preimage attack is found. 2^120 is orders of magnitude beyond usefulness, but not many orders...)

Most distributions *not* affected by this!

[GPLHost-Thomas]

The internal crypt() function of PHP is only there whenever the system function doesn't exist. So for example, in Debian, only the blowfish encryption is affected, all other encryption are using the system. Here's Ondrej post about it:

http://lists.alioth.debian.org/pipermail/pkg-php-maint/2011-August/009328.html [debian.org]

I am guessing that this will be the case in most Unix distribution, but it will be an issue on platforms like Windows. So, maybe this is just too much buzz...

Re:When will MD5 be let to die as hash for passwor

[rthille]

What's fixed by using salt in your passwords is that the leaked password file can't be compared against a precomputed password dictionary.

Re:Regression tests are for wimps!

[Chuck Chunder]

1) The problem was found and announced by "the php development community," and presumably found by them, too (admittedly, not prior to release).

That seems entirely incorrect. According to the bug report [php.net] it seems to have been found by someone external, it was found in a release candidate not the released version and seemingly filed before the release was made.

2) Why aren't you involved in acceptance testing, if you see a problem with how it's being done?

Speaking for me, we pay Zend for server licences and imagine that in someway contributes to a professionally run project. Though I have to say we are becoming increasingly unsure as to whether we get any value for money for that, of the security fixes that 5.3.7 fixed I haven't noticed any of them being pushed to Zend Server in a priority fashion and I don't think we've ever had a single support question resolved satisfactorily. Sometimes being a Zend customer seems merely to open you up to sales pushes.

Re:Regression tests are for wimps!

[Rob Aley]

While it could have been caught, the bug was actually a result of testing, namely the use of the Coverity static analyzer which flagged up "strcat(passwd, "$");". In this particular case it was safe use strcat, but was erroneously changed to "strlcat(passwd, "$", 1);" to avoid the warning. Its a lesson perhaps that automated tests aren't the silver bullet for avoiding bugs, understanding the code itself is just as important. It also raises the question of whether much of the criticism in the discussions below should be directed at C instead of PHP. I'll stay out of that one...!