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

Regression tests are for wimps!

[Niac]

Who cares about testing security code for regressions?

I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing. In this day and age, why on earth is it the case that bugs like this get through?

Re:Regression tests are for wimps!

[PCM2]

I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing. In this day and age, why on earth is it the case that bugs like this get through?

Speaking as an occasional PHP developer, you must be new here.

Re:Regression tests are for wimps!

[rainmayun]

True, PHP has a history of "winging it", but by now they should be doing a pretty damn extensive suite of regression tests against each release candidate, if not each build. At this point in its life and supposed maturity, the PHP Group should really be doing better.

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:Regression tests are for wimps!

[Arancaytar]

Unit tests are slow and they almost always pass. When you're in a rush to release, sometimes you feel lucky.
Of course, you're not. That's the whole point of unit tests...

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.

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

Re:Regression tests are for wimps!

[gweihir]

Automated tests are nice, but fixing the code requires somebody that _really_ understand what they are doing. Fixing problems found in automated tests so that the tests stay quiet without understanding what is going on is about the most stupid thing you can do in security-relevant code. It is grounds for immediate and permanent removal of code maintainer status.

Also note that the Debian OpenSSL disaster was a result from doing the same thing with valgrind, so there has been at least one very public warning about this sort of thing.

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 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:Perhaps THIS is the reason why THIS occurs?

[ledow]

Did you know that houses were the favoured target of burglars? Quick! Sell your house and buy a bungalow! Even though only 1% of houses are bungalows, they're attacked only 1% of the time if you consider all burglaries!

It's like saying "cars most likely target in car thefts".

Dickhead.

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

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:PHP can't get better. It drives away anyone goo

[EvanED]

I think that the post you replied to was a bit extreme, but it's not the bug in the library function that caused him to say that: it's the fact that the PHP project lacks the testing infrastructure that any reasonable project of that size would have.

Anyone can commit a bug; that's easy and excusable. What makes it look like PHP is developed by a bunch of 12 year olds is the fact that they have a test suite with a test that exhibited the bug, and yet no one ran it before they made a release, because they've got too many failing tests so it just got swamped in with that noise.

I'm working on some dinky pieces of research software, and while we probably don't have as extensive a test suite as PHP does, we have a way better testing regimen. A project like PHP should have a CI server that runs their tests at least nightly, and a release shouldn't be made while there are failing tests. That's what expected failures are for. (They even know about expected failures, but still have over 200 failing tests for some reason.) Even we've got that.

It's the QA that's messed up, not the coding.

Worst of all worlds

[93 Escort Wagon]

I know there's no reason a skilled programmer can't use php, but in my experience the users that request php access are generally the users who you'd least want to have any sort of script-level access to your servers. When I've explained to requestors why we don't generally provide php, I've been told on several occasions "I don't want or need the ability to run scripts! I just want to create php web pages." Oh, and mysql access requests usually come hand-in-hand with php requests.

I remember one guy, quite a few years ago, who asked us to 1) enable php on our department's web server; and 2) give him access to create and run php scripts. To demonstrate to us that he wasn't just another newbie... he wrote a php script and placed it on his own personal box as a demo of his coding skill. This script let anyone, anywhere, examine the content of any file in the /etc/ directory via an easy to use web interface.

We politely declined his request.