Watching the PHP CVS

Thursday, May 10. 2007

One of the worst things in PHP security is the fact that vulnerabilities in PHP are usually patched in the CVS and then wait for months until they are disclosed to the public. Time enough for everyone to grab the fixes from CVS and develop exploits for the vulnerabilities. Therefore PHP vulnerabilities are usually already known to the bad guys for weeks or months when a new PHP version comes out and the public is notified about the vulnerability.

However sometimes even after a release the general public does not know about some vulnerabilities, because it somehow happens that they are forgotten to be mentioned in the release announcement. This happened before and has happened once again with the release of PHP 5.2.2

A while ago a bug in the mcrypt_create_iv() function was reported and fixed that caused the IV generator to create always the same IV. The bug itself is the result of calling php_rand_r() with an unitialised variable as seed. Depending on the stack layout of the system this results in the same IV being generated again and again. In some cases the stack layout might result in a totally predictable seed, which will result in a predictable IV. While this is not a completely dramatic problem, a non random IV will results in a weaker encryption. The bug is therefore a security problem that is NOT mentioned at all in the PHP 5.2.2 and PHP 4.4.7 release notes.

Oh yeah... Why the same bug in the soap extension that can be found by a simple grep for php_rand_r was not found and fixed actually beats me...

Posted by Stefan Esser in PHP, Security at 22:00

Comments (12)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 enygma wrote (Link) ()

Um, correct me if I'm wrong, but do see bug #40999 (the one you link to above) as being in the PHP 5.2.2 Changelog: http://www.php.net/ChangeLog-5.php.

posted on Thursday, May 10. 2007

#1.1 Stefan Esser wrote (Link) ()

The changelog and the release announcement are two separate things. In the release announcement there is a dedicated section that mentions and describes the security vulnerabilities that were found. The mcrypt_create_iv() bug is not mentioned there.

You will also not find this bug mentioned on the frontpage of PHP.net, where a bunch of other security problems are mentioned.

The general public will never read through the Changelog and try to find hidden security fixes.

(Let's ignore for a moment that not all the bugs that are mentioned there as fixed, are really fixed in the release)

posted on Thursday, May 10. 2007

#2 enygma wrote (Link) ()

bah...I wasn't paying enough attention. I think I read "release notes" but was thinking "changelog".

posted on Thursday, May 10. 2007

#3 cartman ()

Thats why I spend my time checking php-commits list and update my distros PHP package accordingly. Life sucks for PHP packagers.

Oh now to fix the soap hole

posted on Thursday, May 10. 2007

#4 Hanno wrote (Link) ()

Stefan, not strictly related, but I think I'm not the only one waiting for some mopb-lookback, especially how the status of all the reported vulnerabilities is in 5.2.2. Have they properly been fixed?

posted on Friday, May 11. 2007

#4.1 Stefan Esser wrote (Link) ()

Well this analysis will come in the next days/weeks.

From what I know atleast one of the bugs declared as fixed is not fixed at all.

And well continuing the tradition of introducing security holes into the last X releases the Zend people have introduced atleast one new security bug into PHP 5.2.2

And yes I mean Zend people.

posted on Friday, May 11. 2007

#4.1.1 Jacques Marneweck wrote (Link) ()

Shouldn't that Zend Employee's php-src commit bit be revoked for a few weeks until the patches he/she supplies is not opening cans of security worms?

posted on Wednesday, May 16. 2007

#5 Henry, web application developer wrote (Link) ()

Stefan, you're the only hope of php developers, concerned about security.
Thank you

posted on Friday, May 11. 2007

#6 kuza55 wrote (Link) ()

On a somewhat related note, do you by any chance know in which PHP release the file names of (temporary) uploaded files were randomised? Because I can't find that in the changelog, but I know it occurred somewhere.

posted on Sunday, May 13. 2007

#6.1 Stefan Esser wrote (Link) ()

I don't know what you exactly mean but from looking at the PHP CVS at cvs.php.net in the file main/rfc1867.c it looks like PHP always used the temporary name generation of the libc. If the uploaded filenames were indeed not random it seems that the OS was doing something wrong.

Or I simply misunderstood what you mean.

posted on Sunday, May 13. 2007

#6.1.1 kuza55 wrote (Link) ()

I think you understood me properly, its probably something going awry in regards to windows, for some reason when I installed php on my computer the filenames weren't random, I assumed that it would have been PHP causing that rather than anything else.

Sorry about that.

posted on Monday, May 14. 2007

#7 Jared ()

http://bugs.php.net/bug.php?id=40999 is a dupe of a much older report http://bugs.php.net/bug.php?id=32157 .

posted on Saturday, May 19. 2007

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar