Edit report at https://bugs.php.net/bug.php?id=69833&edit=1
ID: 69833
Updated by: nikic@php.net
Reported by: iand at ekit-inc dot com
Summary: mcrypt broken in 5.6.10 fd caching not working
Status: Open
Type: Bug
Package: mcrypt related
Operating System: Solaris 9,10
PHP Version: 5.6.10
-Assigned To:
+Assigned To: leigh
Block user comment: N
Private report: N
New Comment:
@leigh: Please also check whether this applies to the CSPRNG as well.
Previous Comments:
------------------------------------------------------------------------
[2015-06-15 04:40:16] iand at ekit-inc dot com
Description:
------------
mcrypt has broken in 5.6.10 on my platform under apache 2.4.12
running with threaded mpm.
$ /opt/local/apache/bin/httpd -M |grep mpm
mpm_worker_module (static)
Symptoms are that under apache, php's use of mcrypt runs into time limits...
but if you run the same code from php command line it works fine.
Fatal error: Maximum execution time of 30 seconds exceeded in /opt/local/apache/htdocs/mcr.php on
line 7
Inspection with truss shows it is failing to open /dev/urandom
This is a truss from apache 2.4.12 with php 5.6.9:
24686/27: munmap(0xCD3B0000, 4096) = 0
24686/27: munmap(0xCD390000, 7880) = 0
24686/27: munmap(0xCD3A1000, 5040) = 0
24686/27: munmap(0xCD370000, 2724) = 0
24686/27: munmap(0xCD380000, 3028) = 0
24686/27: open("/dev/urandom", O_RDONLY) = 17
24686/27: read(17, "02F7F1F1 3CA $A8", 8) = 8
24686/27: close(17) = 0
24686/27: open("/opt/local/lib/libmcrypt/tripledes.la", O_RDONLY) = 17
whereas on apache 2.4.12/php 5.6.10 (below) it keeps reading from fd #0
(lsof says this is /dev/null) until the timeout is reached.
25529/27: munmap(0xCD3B0000, 4096) = 0
25529/27: munmap(0xCD390000, 7880) = 0
25529/27: munmap(0xCD3A1000, 5040) = 0
25529/27: munmap(0xCD370000, 2724) = 0
25529/27: munmap(0xCD380000, 3028) = 0
25529/27: read(0, 0x0853CF78, 8) = 0
25529/27: read(0, 0x0853CF78, 8) = 0
25529/27: read(0, 0x0853CF78, 8) = 0
25529/27: read(0, 0x0853CF78, 8) = 0
25529/27: read(0, 0x0853CF78, 8) = 0
Looking at the php change log for 5.6.10 and the related changes in mcrypt.c
it would seem that the changes here have caused this fail.
Looking at these changes, I can spot one obvious error; the close code
doesn't consider fd#0 an open fd. Patch for this below.
However I suspect there is something else going on perhaps related to
the multi-threaded environment.
$ diff -c mcrypt.c.orig mcrypt.c
*** mcrypt.c.orig Wed Jun 10 07:42:27 2015
--- mcrypt.c Mon Jun 15 03:33:18 2015
***************
*** 450,461 ****
php_stream_filter_unregister_factory("mcrypt.*" TSRMLS_CC);
php_stream_filter_unregister_factory("mdecrypt.*" TSRMLS_CC);
! if (MCG(fd[RANDOM]) > 0) {
close(MCG(fd[RANDOM]));
}
! if (MCG(fd[URANDOM]) > 0) {
close(MCG(fd[URANDOM]));
}
UNREGISTER_INI_ENTRIES();
--- 450,463 ----
php_stream_filter_unregister_factory("mcrypt.*" TSRMLS_CC);
php_stream_filter_unregister_factory("mdecrypt.*" TSRMLS_CC);
! if (MCG(fd[RANDOM]) >= 0) {
close(MCG(fd[RANDOM]));
+ MCG(fd[RANDOM]) = -1;
}
! if (MCG(fd[URANDOM]) >= 0) {
close(MCG(fd[URANDOM]));
+ MCG(fd[URANDOM]) = -1;
}
UNREGISTER_INI_ENTRIES();
-----------
So further debugging is required.
Test script:
---------------
<?php
$plaintext="hello world";
$key = "1;lk23GH2KJ:l*&^$^%$913S";
$encrypted =
bin2hex(mcrypt_encrypt(MCRYPT_3DES,$key,$plaintext,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_3DES,MCRYPT_MODE_CFB))));
$decrypted_data =
trim(mcrypt_decrypt(MCRYPT_3DES,$key,hex2bin($encrypted),MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_3DES,MCRYPT_MODE_CFB))),
"\0");
print "orig=".$plaintext."\n";
print "encr=".$encrypted."\n";
print "decrypted=".$decrypted_data."\n";
if($plaintext != $decrypted_data) {
print "MISMATCH\n";
}
else {
print "MATCH\n";
}
?>
Expected result:
----------------
Instant; no timeout
Actual result:
--------------
timeout
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=69833&edit=1