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."

Comments

Re:Regression tests are for wimps!

[thue]

From the Bug report:

> 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 :).

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 :)

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

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: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 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.