Do not upgrade to PHP 5.3.7 due to a bug in crypt() | Hacker News Reader

Do not upgrade to PHP 5.3.7 due to a bug in crypt()

php.net

108 pointsthere34 comments

I'm sure this was initially caused by the updates to crypt_blowfish (to fix the 8bit character issue we talked about a couple of months ago).

Interesting: Their build server has a failing test for crypt: http://gcov.php.net/viewer.php?version=PHP_5_3&func=test...

So I would assume that this should have been caught by running the tests before making the release. Or whoever ran the tests had them passing due to build artifacts of previous builds.

Or there are just too many tests that fail regularly: http://gcov.php.net/viewer.php?version=PHP_5_3&func=test... - when you have 201 failing tests, one more probably isn't going to cause any concern.

201 failing tests is really shocking to me. Does anyone know of similar pages for languages such as ruby or python?

http://rubyspec.org/ is the language "spec" that most ruby implementations of note, jruby/rubinius/mri, use to test that they are compliant.

I couldn't find a page with automatic tests running against each implementations head/master branch. But I do see crypt() like specs in there: https://github.com/rubyspec/rubyspec.git

Python's test page: http://python.org/dev/buildbot/all/waterfall

And here's one with just Python 2.7 on high-priority platforms: http://www.python.org/dev/buildbot/all/waterfall?category=2....

Here's the CI for MRI (the major Ruby implementation): http://59.106.172.211/~chkbuild/ruby-trunk/recent.html

Perl will not install if any of its tests fail after it's built. I'm surprised that PHP's test suite isn't run on the user's box after building it, allowing end users to "double check" the release process.

I'd imagine the majority of people are installing it via their distro's binary packages, so they're not going to run the tests anyway.

Of course, the packager for the distro should be running tests, and raising some serious questions when stuff fails.

In fact, it is. Just type make test. There are thousands of unit tests and it takes a long time. I generally run it and expect a 98% passing rate. If it's below that, I might have an issue. One or two failing tests will never get noticed.

It seems like they add tests for bugs before actually fixing the bugs. I can see that being useful, but they need to do a better job of marking which bugs are ignorable and which are not.

This is a an open source project - anyone want to volunteer?

Just because it's an open source project does not mean that your contributions will be happily accepted.

Nor does that mean you can't try.

I would like to say that I would never release code with a failing test, but in truth, my NSNMP module on CPAN has a test that fails occasionally due to some kind of race condition that I've never bothered to fix, because I kind of abandoned NSNMP when I stopped doing any SNMP work in I think 2005. I get email about it from CPANTS every week, and have been since at least 2005.

Now that I've made my confession, I think that this is the latest piece of evidence in a long line showing that the PHP core team just doesn't know how to program. See also this horrorshow that is the list of attempted fixes for an integer overflow vulnerability in 2007: http://use.perl.org/~Aristotle/journal/33448 and this complete freshman-level lack of comprehension of C: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=34.... And of course there are the evidences of incompetence permanently enshrined in the language, like the fact that "a ? b : c ? d : e" parses incorrectly as "(a ? b : c) ? d : e", but those could simply mean that Rasmus didn't know how to program when he was first designing PHP.

Nevertheless, it must be said that PHP is an incredibly useful piece of software. It clearly shows that intelligence and even basic programming competence are not sufficient or even necessary to build great software. You can do it on sisu alone, and without sisu you can't do it.

This isn't the first time a major bug has been introduced and found shortly after release. How do these major bugs get past testing? Does PHP have poor test coverage? This bug would have been found pretty quickly with basic unit testing.

If you read the bug report, looks like the tests were failing, yet nobody bothered to either test, or investigate the results...

Sounds like plain old incompetence. PHP is slowly becoming even more of a joke due to things like this.

Not identifying this bug was the result of an (in my opinion) egregious human error. PHP has decent test coverage, and this issue does cause the current tests to fail. I really don't know how this was missed.

How can I get important information like this delivered to my inbox?

I'm serious. Without seeing this here, I might have used YUM to upgrade to the latest version (5.3.7) like I often do. I get the php-announce emails telling me that a new version is available, but nothing telling me when a problem like this emerges.

I think the answer is that this announcement should go out in php-announce. Maybe it will later today.

isc sans rss feed is how I first saw this. a better approach is subscribing to the security list for projects you are interested in.

We use portaudit - http://www.freshports.org/security/portaudit/

I'm sure there's something similar for Linux.

I really enjoy PHP: I learned on it and in doing so became familiar with its numerous idiosyncrasies. However, and I know this is a weird sentiment, I'm waiting for it to fall out of favor. Then, hopefully, most everybody new to programming/scripting will move on and the community supporting PHP will be pared down. The release cycle will slow, and the gains the language has made can be consolidated and stabilized.

But that's me: I'd rather code in a quiet backwater (e.g. PHP in the future, when everyone has moved on) than be screaming along the cutting edge. Such a goal is definitely the opposite of many.

PHP isn't a quiet backwater, it's a cutting-edge when you should have stable, well-tested code (security-related functions like crypt()), and a backwater when you want to be cutting-edge (object-oriented and functional paradigms).

Isn't this a feature..?

No, I'm not serious. But if everyone wakes up for a second, checks if they are vulnerable and maybe, accidentally stumbles upon 'Why you don't want to use MD5 for your authentication' posts.. Wouldn't the world be a better place tomorrow?

Get ready for some WTF-ery Crypt takes an optional salt. If that value is an MD5 hash it is prefixed with the chars $1$ to tell the underlying crypt(3) function to use Modular Crypt Format[1].

MCF is an ad-hoc cruft because the orginal crypt() is weak.

Anyway guess who did it :

"let's use strlcpy/strlcat instead for these static string copies" - Rasmus I guess that's Lerdorf himself

Whoever it was also didn't check the return values for error. Strlcat returns the length of the new string which might not be the same as strlen(dst) + strlen(src).

"I'm not a real programmer. I throw together things until it works then I move on." - Rasmus Lerdorf

Here's where he broke it : Sun Aug 7 16:10:34 2011 UTC http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/php...

Here's it being fixed : Fri Aug 19 22:49:18 2011 UTC http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/php...

[1] http://packages.python.org/passlib/modular_crypt_format.html

If you have never broken anything you have probably never built anything.

The project leader.

Tests, I'm in charge, I don't test.

This code had a unit test, and it failed after the change as expected:

http://gcov.php.net/viewer.php?version=PHP_5_3&func=test...

crypt()'s MD5 is salted and iterated and therefore perfectly adequate to use for your authentication. Just not in PHP 5.3.7. bcrypt() or scrypt() might be better, but crypt() with MD5 is perfectly adequate.

Are you sure it's iterated? I just checked the manual for crypt() and it just says it's MD5 with a salt, but it could be a failure of the documentation.

Yes, see http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt... where it says, "for(i = 0; i < 1000; i++)".

1000 isn't very many at all in this day and age. And because MD5 has been actually broken I'd avoid it entirely. Use scrypt.

Or bcrypt, which is actually implemented in PHP as part of the crypt function ;-)

This is tricky to answer.

Of course I don't want to advocate using MD5, even iterated a thousand times, for both of the reasons you state. There are better alternatives. scrypt appears to be one of them, and if it stands up to analysis, it's better than PBKDF2 and bcrypt, which in turn are better than MD5-crypt.

However, MD5 iterated 1000 times is still 1000 times better than MD5 iterated once (which an alarming number of codebases still use!) and the vulnerabilities that have been published in MD5 are not sufficient to speed up an attack on an MD5-crypted password file.

So MD5-crypt is still vastly preferable to many alternatives, including traditional Unix crypt(), even though MD5 has been broken and DES hasn't.

Ouch. I'm actually still on 5.3.6, waiting for 5.4.0. Guess laziness is a blessing sometimes after all.

Aw man, I was all excited because I thought my posting was getting a bunch of traffic. Then I realized this is just a repost :( plays violin

http://news.ycombinator.com/item?id=2912066

Reply on news.ycombinator.com