Serious Crypto Bug Found In PHP 5.3.7 165
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."
Regression tests are for wimps! (Score:5, Insightful)
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! (Score:4, Funny)
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: (Score:1)
Okay, fair point. I try to give PHP the benefit of the doubt... ;) I'd like to think that they've got automated testing of submitted code. I'd like to... :-(
Re: (Score:3, Informative)
Re:Regression tests are for wimps! (Score:4, Insightful)
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.
Re: (Score:2)
Are you certain that it was indeed someone not knowing wtf they were doing? It could (though I do realize this is php..) - COULD have been a mistake by an otherwise knowledgeable individual.
Re: (Score:2)
The person responsible did rather obviously not understand the limits of his own understanding. In normal bugs a more experimental approach to fixing code is fine. But with crypto, you have to understand what you are doing, as crypto very easily breaks in ways that are non-obvious and leave the software functional, yet insecure. Finding this out does not even need in-dept crypto knowledge. Almost all major attacks on crypto in the last few years have been on the implementation, not the crypto itself.
So, yes
Re: (Score:2)
a good read on how it happened
http://pwnhome.wordpress.com/2011/08/22/php-crypt-bug/ [wordpress.com]
Re: (Score:2)
Re: (Score:3)
It does once the feedback loop becomes complete. At least with VB, those developers were not contributing back to the language. The same can not be said for PHP.
Re: (Score:2)
I just want to know who's using MD5 for *anything* anymore other than maybe a stronger CRC?
Re: (Score:2)
Anyone stuck without the funds to do a proper upgrade of a system because management does not think MD5 is an issue worth 'fixing'.
Re: (Score:2)
Re: (Score:2)
Who writes "large projects" in C?
Scalability isn't C's strong point, use C++ for that.
As for PHP... sure you *can* write good code in PHP but on average it's the Visual Basic and Excel Macro programmers who are (ab)using it.
Re: (Score:2)
Whoosh!
Including the other poster, you've now been told the same thing TWICE in addition to the fact that deep down you KNOW its true. PHP attracts the lowest common denominator of programmers. That's not to say better programs don't know the language but the fact remains, the vast majority of PHP users, and in fact the category of programmer it caters to is the low-end, bone-head, wanna-be coder who doesn't know his ass from his keyboard.
Beyond that, your example is dumb. Its literally the same thing as sa
Re:Regression tests are for wimps! (Score:5, Insightful)
PHP can't get better. It drives away anyone good. (Score:2, Insightful)
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!@!#%@!!".
Re: (Score:3)
Re:PHP can't get better. It drives away anyone goo (Score:5, Insightful)
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.
Re: (Score:2)
Yup. The problem here seems to be with procedures rather than technology. Bugs happen. What matters is what you do when a bug happens. The bug was reported before release date and the bug should have been marked as a showstopper.
PHP 5.3.7 should not have been released with a known bug of such magnitude. It's an open source project without commercial interrests; it doesn't matter if a release is delayerd for a couple of days.
Re: (Score:2)
Re: (Score:2)
No, it actually was a bug in the way the function was called, not the library itself - see comment number four: https://plus.google.com/113641248237520845183/posts/g68d9RvRA1i [google.com]
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists, and people are often slow to deploy new versions of PHP - especially major shared hosting providers. Those who manage their own PHP installs and deploy shortly after release tend to have their own set of unit tests, which very likely wo
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:2)
You are laughing at PHP, while grouping .net and java based stuff in the "serious business" category?
Java and everything .net related are the biggest jokes ever in the history of computing.
PHP is a simple language that is robust enough to build complex applications. Sure, it's grown organically, and you can see that in its current design, and yes, a bug escapes here and there, but it's unfair to compare it to Perl. For instance, Perl has been stable for 20 years. PHP was totally rewritten in PHP3, and went
Re: (Score:2)
It's misshapen, blotchy and has bits of shit sticking to it?
Re: (Score:2)
I'll tell my boss that we need to get to work re-writing 90% of what our department has done in the last 5 years as quickly as possible in java. PHP can do anything I need it to do, as besides the occasional security bugs (and this one doesn't seem to effect me), it works great.
It's the programmer that makes the program, not the language.
Re: (Score:2)
We all know "real FORTRAN programmers can write FORTRAN in any language" but when fresh young minds are exposed to programming I don't think PHP is an ideal choice. When (eg.) strings can be compared with numbers without so much as a warning you know there's a WTF brewing.
Re: (Score:2)
None of that changes the fact that it's a horribly "designed" language
It was "designed"??? Whoa...I think I just experienced a negative reality inversion.
Re: (Score:3)
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
Re:Regression tests are for wimps! (Score:5, Informative)
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 :).
Re:Regression tests are for wimps! (Score:5, Insightful)
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: (Score:1)
If you're rushing to release, you've already failed. Best not to make more mistakes.
Re: (Score:3)
Imagine a Beowulf cluster of test boxes (Score:2)
Unit tests are slow and they almost always pass.
That's why they make big ass clusters out of big ass multicore computers. Run a test on each core. Beowulf [wikipedia.org] would be proud.
Not only that (Score:4, Informative)
Re: (Score:2)
Sounds like they need Retaliation [slashdot.org]!
Re: (Score:3, Informative)
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?
Re: (Score:2)
2) Because it's PHP. No one wants to be involved with that.
Re:Regression tests are for wimps! (Score:5, Informative)
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.
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: (Score:2)
Why aren't you involved in acceptance testing, if you see a problem with how it's being done?
I am involved. It's open, right? So, I hereby declare myself to be involved. Further, I declare this release to be unacceptable. I do not certify it, and the release is hereby invalidated. That was easy!
Re: (Score:1)
I know, that's the type of thing we expect from debian when working with cryptography.
Re: (Score:3)
Re: (Score:2)
Not to dismiss the serious amount of time and effort you, Ondej, Raphael and all packagers put in, but I'm pretty sure the parent was making a joking reference to the OpenSSL entropy bug.
Re: (Score:2)
Never once seen a Regression test find something that is broken.
I think I speak for many developers: Then you're doing it wrong.
Re: (Score:2)
No kidding. Either s/he works in an organization where no one ever breaks existing functionality (extremely unlikely) or their regression testing methodology is garbage. I'll go with the latter.
Re: (Score:2)
I believe you don't know the meaning of "regression bug" hence "regression test".
Re: (Score:2)
This is hardly limited to PHP. You'll see much the same thing in the Win32 API, or indeed in the C standard library (gets, anyone)? Deprecated functions left in for compatibility re
Rut Roh (Score:2)
When will MD5 be let to die as hash for passwords? (Score:3, Informative)
Re: (Score:1)
From that wikipedia article "The presented attack does not yet threaten practical applications of MD5".
A collision attack allows you find pairs of values that have the same MD5 hash, but these pairs are very rare.
This is a problem for digital signatures, since an attacker could create two files (one malicious one not) that both have the same signature. It's not a problem for passwords, since attackers can't control the password you pick.
Re: (Score:2)
Re: (Score:3)
Read up on the difference between Collision attack [wikipedia.org] and Preimage attack [wikipedia.org].
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 docu
Re: (Score:2)
Re: (Score:2)
Hmm, when you say "take advantage of it" are you talking about the well-known MD5 collision attack, or the PHP crypt bug?
Re the collision attack: I think you are right. But still, advice going around is "don't use MD5". Researchers are still chipping away at it, so there's no telling when they'll have a working preimage attack.
Re the PHP crypt bug: my understanding is that it's quite serious in that it can throw away the input and just use the salt, causing widespread MD5 collisions. So that could definitel
Re: (Score:2)
The MD5 collision vulnerability only allows you to generate pairs of plaintext that share the same hash. It does not allow you to find a colliding plaintext-B from a given plaintext-A. It also does not allow you to compute a plaintext from a given hash.
In terms of passwords, here's what the exploit looks like: The attacker generates a pair of colliding texts; they use one of them as a password; the other text can also be used for the password. There are some contrived scenarios where this might be a pro
Re: (Score:2)
Amaze your friends; you now have two, Two, TWO passwords! Ah. Ah. Ah.
Why not go a bit further? There are infinite number of inputs for a hash function that produce the same output.
Re: (Score:2)
Well, yes?
http://en.wikipedia.org/wiki/Salt_(cryptography) [wikipedia.org]
Perhaps put very simply.. say you find a file full of e-mail addresses followed by md5 codes, e.g.
example@example.com 5eb63bbbe01eeed093cb22bb8f5acdc3
You deduce that they may be hashed login codes, so you run your MD5 hacking tool and find the password to be either "hello world" or "flurblgrabl".
You enter either "hello world" or "flurblgrabl", and you're in.
Now let's say you find instead:
example@example
Re: (Score:2)
Well, yes?
The problem with salting: transfer the matter into "security by obscurity".
If the repo of you passwords leaks, one can assume the salt grains would leak too. Then you are not better than having the hashed password alone to attack.
Re:When will MD5 be let to die as hash for passwor (Score:4, Informative)
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: (Score:2)
Re: (Score:2)
The problem with salting: transfer the matter into "security by obscurity".
Which is what passwords are in the first place, and, by extension, any mechanism of manipulating or digesting them.
If the repo of you passwords leaks, one can assume the salt grains would leak too. Then you are not better than having the hashed password alone to attack.
Password hashes are typically stored in a database. The salt is typically part of the configuration store. Most systems (Wordpress being the singular counterexample I can think of) store user data separate from configuration data, and configuration data is usually left flat files. (LDAP is an alternative, but I don't believe most services use it)
So even if the password hashes leak, it's unlikel
Re: (Score:2)
Typically, salt and hash are stored together as one string, and each password will have its own randomly selected salt.
Salting is for defending against precomputed dictionary attacks. You're not supposed to keep the salt secret.
Re: (Score:2)
That's not how I've generally seen salts used. Generally, I've seen salts used like "echo $SALT$DATA|md5sum".
I'm not disputing that the method you describe isn't done, I just haven't seen it done that way.
Re: (Score:2)
I remember rainbow tables...and I remember that salting was the counter to them.
Re: (Score:2)
False.
Unless there happens to be a pre-computed rainbow table that includes the salt of the password (likelihood: practically zero), you are still massively better off. In that case, you'll have to generate your own rainbow tables if there's a single salt for all entries, or go cry yourself into a corner in the hopefully more likely scenario where each entry has its own unique salt (because you now need to bang out a rainbow table for every entry in the users table).
Nearly all security is based on obscurity
Re: (Score:2)
The only point of per-site (and ideally per-user) salt is so that a pre-computed rainbow table attack does not work. And salt is a semi-public piece of information. It has to be published in enough places through your code that you must assume that the attacker knows how you salt. And often, the salt is stored right along side the password in the password hash.
Without salt: attackers create the huge rainbow table of about a
Re: (Score:2)
Run an attack against that, take the results (potential salts), now run an attack against all the other MD5 signatures with the found potential salts tacked on until you get matching MD5s.
Now the correct salt has been identified
If you know what a salt is, you should also know that using the same salt for different accounts is very very bad.
Re: (Score:2)
Yep - but sadly commonplace.
Re: (Score:2)
Indeed. I remember running some WWWBoards back in the '90s, and even those salted the password. I believe they just grabbed a particular substring of each password and fed it as the salt into the crypt function, so you had a (more or less) unique salt for every password. And that was a simple perl script from the '90s. I would hope everyone is doing at least a little more than that today.
Re:When will MD5 be let to die as hash for passwor (Score:4, Informative)
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...)
Re: (Score:2)
MD5 should be deprecated, but the collision attack only invalidates signatures;
Because you are not "decrypting" the password, finding a collision will be an attack for passwords as well - fortunately, as others pointed out, it's currently still 2^120.
and the dictionary attacks are defeated by salt
I argue that using a "salting for passwords" it's useless (doesn't do harm, but doesn't bring in too much good either) . Unlike signatures/message digests, the checksum is not made public (the passwords - or their checksum - are stored in a "secure place") and the attacker usually has longer time for cracking a password - until you chang
Re: (Score:2)
You should be salting each password with a unique salt - and storing the salt with the hash!
The reason for salting the password is to invalidate rainbow tables by effectively making the hashing function unique for each password.
Yes it's a problem for an attacker to get your hashes, but if they do you have made sure they have to break each and every password separately rather than the whole lot at once. Or even worse having precomputed MD5 tables being able to break them immediately.
Re: (Score:2)
What you're missing is that even if they have both the hash/checksum and the salt, they then have to start bruteforcing the password from scratch. Because they didn't know the salt in advance, they couldn't have precomputed a dictionary of hash -> password mappings like you can with unsalted passwords, so each password has to be bruteforced separately. If the passwords aren't salted, and are just plain md5 (say), it's entirely possible that they already know what the md5 reverse-maps to because they've s
Re: (Score:3)
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.
Re: (Score:2)
Collision attacks are no threat to passwords. They are a threat to things like certificate signatures when the certificate is made by the attacker.
Please do not post nonsense.
PHP Bug #55439 FIXED (Aug 20) (Score:1)
This bug has been fixed already. See https://bugs.php.net/bug.php?id=55439 [php.net]
Main problem was if an aplication stores its hashes in a database and use them as authentication then:
$valid = crypt($pw, $crypt);
will always be TRUE regardless of $pw
For all this, PHP Team said it is fixed in SVN and recomending to wait (upgrade) till 5.3.8
Re:PHP Bug #55439 FIXED (Aug 20) (Score:5, Informative)
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 :)
It is not a crypto bug.. (Score:1)
.. if the code never calls the crypto. That is the case here.
Re: (Score:2)
It is a crypto protocol implementation bug, or crypto usage bug, short "crypto bug". Actual bugs in crypto algorithm implementation are so rare it does not make sense to reserve the term for them.
Poor QA (Score:4, Informative)
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: (Score:3)
"It's almost like the people who build PHP aren't even interested in maintaining it."
It's not really that, it's just the PHP ethos, PHP has never really been about good software development and that flows not just through the language itself but development of the language. It's not that PHP is inherently bad- rather than focus on good practice, it focuses on just getting things done, and this kind of works, but it also means that you'll more frequently see things like this when you throw best practice out
Re: (Score:2)
Historically Java with something like Spring has been the best bet, but in recent years C# is taking the helm really. With things like ASP.NET MVC being designed for testability, and modularity from the outset and the languages themselves from day 1 have pretty much been designed with the ability to scale in mind.
Ruby on Rails brings better practice development to the web, but it doesn't really solve the scalability issues, so it's really just an alternative to PHP rather than something designed to grow. Tw
Most distributions *not* affected by this! (Score:5, Informative)
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: (Score:2)
This is not correct.
Ondrej's post you link to is specifically referring to the patched version of PHP that you get from the Debian repository. One of the patches Ondrej applies makes PHP use the system crypt(). Without that patch -- with the stock PHP code -- PHP uses its own crypt(). Now, other distributions might apply Ondrej's patch, but I certainly wouldn't count on it, and you definitely will have a broken cry
Re: (Score:2)
Correct me if I'm wrong (Score:2)
Many are assuming that the salt is something that wouldn't be compromised, i.e.
$SITE_SALT = 'LULZYOUCANTGUESSTHIS';
$HASH = MD5($SITE_SALT + $PASSWORD);
I think this is a bit of a misunderstanding. The salt is not necessarily intended to be a secret value unless you can ensure the security of that value, that is the
Re: (Score:2)
Re: (Score:2)
Who uses that? (Score:2)
Re: (Score:2)
I thiiiink you're joking? Seriously, though, I've been using mcrypt in PHP for years, even though it's STILL! not even available through yum for CentOS. libmcrypt and mhash have been required by my infrastructure for a long time, and I've never bothered to use the built-in crypt(). I'm a little peeved that there was no unit test that caught this bug, but I'm glad to be unaffected.
Lack of security people? (Score:2)
Worst of all worlds (Score:4, Interesting)
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.
Re: (Score:2)
> We politely declined his request.
If this predated /etc/shadow, I would have just mailed him back his root password. :)
Re: (Score:2)
That's all fine if you're running a server for people's personal web pages. We're not. suEXEC doesn't play well with group access.
Re: (Score:2)
As long as you know how to properly secure and administrate your server, there should be no issue giving users PHP access.
If you add in that you don't care about the server's participation in botnets and facilitation of malware infrastructure, I'll agree with you. But you rather sound like the typical "I want my PHP" whiner that hasn't the foggiest clue about security. And I *do* care about not having servers participate in botnets, so no, we don't and won't allow PHP on our servers. Hosted servers are another matter and for that we rely on detection and remediation. With PHP it isn't a matter of if, but when.
Re:Perhaps THIS is the reason why THIS occurs? (Score:5, Funny)
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.
Re: (Score:2)
Steve, I know you're pretty animated on stage, but it's just not the same when you're only using boldface and caps.
Re: (Score:2)
Maybe I would like Java more if the people who owned it weren't so evil they make MS look good.
And if the people who choose to use it didnt use 5000 different addon libraries with confusing names that say nothing about what they hell they do (Spring, Struts, Hibernate etc etc etc)
Re: (Score:2)
Don't worry, the OSGi people are going to fix the confusing name mess. Pretty soon, those libraries will be OSGi Spring or Struts OSGi or HibernateBeanOSGi.
But first they need to figure out what OSGi stands for. Or even what it does. (They know it doubles as a sandwich spread and a floor cleaner, and there are a lot of buzzwords involved, but are not quite clear beyond that.)