Bug #69833 [Asn]: mcrypt broken in 5.6.10 fd caching not working

From: Date: Sun, 09 Aug 2015 16:56:13 +0000
Subject: Bug #69833 [Asn]: mcrypt broken in 5.6.10 fd caching not working
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-195057@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69833&edit=1

 ID:                 69833
 Updated by:         ab@php.net
 Reported by:        iand at ekit-inc dot com
 Summary:            mcrypt broken in 5.6.10 fd caching not working
 Status:             Assigned
 Type:               Bug
 Package:            mcrypt related
 Operating System:   Solaris 9,10
 PHP Version:        5.6.10
 Assigned To:        leigh
 Block user comment: N
 Private report:     N

 New Comment:

@leigh, ok, i can tell why it is zero now, see http://git.php.net/?p=php-src.git;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054
. I was already wondering as it's already at the first request. @iand, please give the patch a
try with php7.

Normally system could reuse stdin if ulimit was reached or it was explicitly closed. But merely it
seems globals was never properly initialized if ZTS mode. So zero is just an unitialized value, not
something open() has delivered. What is left for this ticket were

- backport to 5.6
- for 7 - integrate the static tsrmls cache

@leigh, let me know if you want to take that over (as it's still assigned to you). I think
CSPRNG part sohuldn't be applied, there the globals are handled correctly, so zero it could be
only in some exceptional case i've mentioned above. Instead there should be some conditions to
avoid a dead loop in both mcrypt and CSPRNG.

Thanks.


Previous Comments:
------------------------------------------------------------------------
[2015-08-06 20:33:34] leigh@php.net

I wasn't 100% confident the patch would fix the issue, however it does mean we correctly
account for the documented behaviour of open().

I'm not even sure how the issue happens in the first place.

------------------------------------------------------------------------
[2015-08-06 19:10:55] ab@php.net

@iand, @leigh at the first glance the patch doesn't fix the issue in ext/mcrypt. While
it's correct to reset the fd after close, MSHUTDOWN doesn't feel like a place fixing it.
Does it fix the issue for you?

The CSPRNG part looks correct however. Whereby the stuff in the php_random_bytes within if (fd <
0) could be moved into RINIT or even to MINIT, but that's another question.

Thanks.

------------------------------------------------------------------------
[2015-08-05 03:23:04] tbmstechnical at gmail dot com

Im seeing this issue on php 5.6.11 under apache 2.4.16 with mpm_event_module on Ubuntu 14.04.

------------------------------------------------------------------------
[2015-08-03 12:43:52] leigh@php.net

Hi, sorry for the late reply.

Yes this affected the CSPRNG fd cache too.

Submittd PRs 1450 and 1451 to address MCrypt and random_* respectively to address the fact that the
fd can be zero.

How it got to be zero is more of a mystery, those read() calls are returning 0 so it looks like it
really was /dev/null in Ians trace.

------------------------------------------------------------------------
[2015-06-22 17:55:11] info at regioconnect dot net

Can confirm this problem on debian 7 on xen PV.
apache 2.4.12, both for php 5.5.26 and 5.6.10
underlying distro is debian wheezy, but apache and php were source compiled.

happens with mediawiki 1.25.1:

in includes/MWCryptRand.php
$iv = mcrypt_create_iv( $rem, MCRYPT_DEV_URANDOM );

changing 2nd parameter to MCRYPT_RAND makes the problem go away.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=69833


--
Edit this bug report at https://bugs.php.net/bug.php?id=69833&edit=1


Thread (18 messages)

« previous php.bugs (#195057) next »