Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
PHP Programming Security

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."
This discussion has been archived. No new comments can be posted.

Serious Crypto Bug Found In PHP 5.3.7

Comments Filter:
  • by Niac ( 2101 ) on Monday August 22, 2011 @07:35PM (#37173218) Homepage

    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?

  • by rainmayun ( 842754 ) on Monday August 22, 2011 @07:46PM (#37173294)
    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.
  • by Arancaytar ( 966377 ) <> on Monday August 22, 2011 @08:04PM (#37173370) Homepage

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

  • by Anonymous Coward on Monday August 22, 2011 @08:24PM (#37173496)

    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.

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

  • by gweihir ( 88907 ) on Tuesday August 23, 2011 @07:55AM (#37176524)

    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.

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!