Slashdot Mirror
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."
A collision attack exists that can find collisions within seconds on a computer with a 2.6Ghz Pentium4 processor (complexity of 2^24.1) Does salting garbage result in something edible?
Questions raise, answers kill. Raise questions to stay alive.
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 :).
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.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
"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?
"National Security is the chief cause of national insecurity." - Celine's First Law
It seems the bug was filed before the release was made.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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 :)
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...)
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...
What's fixed by using salt in your passwords is that the leaked password file can't be compared against a precomputed password dictionary.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
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.
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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...!