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."
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?
http://gabrielcain.com/
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.
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..
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.
PHP has gotten itself into a vicious cycle where it inherently can't get better.
Anyone who knows what their doing will refuse to use PHP. That means that only the worst "programmers" out there will even consider it, let alone use it.
WIthout having good developers using it, it'll never have good developers contributing to it. No good developer would want to publicly admit that they've contributed to PHP.
At this point, some fool will throw out some crap like, "OmG but W1kip3D1A n faceb00K yooze PhP!@!#%@!!". None of that changes the fact that it's a horribly "designed" language, and it's just as poorly implemented. This single bug shows just how awful it is.
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...)
A bug in a library function shows how a language is poorly designed? Methinks you need a little more logical organization to your thoughts. and I can't help but laugh at "no good developer would want to publicly admit that they've contributed to PHP". Perhaps no good developer would want to admit to posting your comment, hence Anonymous Coward status.
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/
I just had to have a very similar situation for a web site that I wanted, I went out for bids, and got about 5 solid coders, each one real good, each had a quote price with in 4500 of each other, all different languages it all came down to delivery date.
I took the PHP guy, why, real simple, he said to me, prototype web site in Photoshop in 3 days, working web site idea in a week, beta test on the 14th day, can go live within another week and afterwards with 3 months of support, bug cleaning, and code clean up free. bottom line he said, if it works you'll hire me on the 4th month for years, and then we can recode it in whatever you want.
the truth of the matter seems that i wanted a delivery date that could be hit, Who knows I might have done something wrong but first to market always get's the attention.
if you see me, smile and say hello.
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.
Of course an attacker who steals your password database knows the salt values in use for each account.
But unless they have a rainbow table calculated with every possible salt value taken into account, they can't do a simple lookup on a precomputed map of hash values to top-5,000,000-common-passwords and hope to get a match... so their expense to actually break any of those passwords is much, much higher.
Read up on the difference between Collision attack and Preimage attack.
MD5 is vulnerable to collision, but not yet preimage attacks. The preimage attack the GP is mentioning is something like this: Alice is required to digitally sign off on all money withdrawals from an account, and MD5 is used as a hash algorithm. Bob creates two documents, one saying "I authorize the withdrawal of $100." and another saying "I authorize the withdrawal of $1,000,000." He uses a collision attack to ensure that these two documents both hash to the same MD5 value. He then gives Alice the $100 note to sign. She does so creating a digital signature, which happens to also be valid for the $1,000,000 note (unbeknownst to her). Bob then submits the $1,000,000 request for withdrawal, along with a valid signature from Alice.
In general, it is Very Bad if two documents can be created with the same hash. But yes, not going to help cracking passwords though.
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.
#DeleteChrome
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists
Yes they are, because the two don't do the same thing. md5 just calculates the md5 of data, whereas the md5 support of crypt uses salting and a large number of rounds to make password cracking harder.
I don't think they should have pulled it, if you don't use the the crypt() function the other fixes and features of the upgrade may well make it a worthwhile upgrade. However I agree that the download page should be marked with this information, not just the front page.
No, but releasing an update without even running the existing unit tests shows how amateurish the whole PHP project is. The terrible design of the language is also a reflection of its amateurish nature.
It's true that some websites manage to do wonderful things with PHP, but then it's also true that some artists manage to make wonderful sculptures out of manure. That doesn't mean it's a good choice for most people.