Bug #73103 [Com]: Release 1.1.0 has random behaviour

Edit report at https://bugs.php.net/bug.php?id=73103&edit=1 ID: 73103 Comment by: mbechler at eenterphace dot org Reported by: tvdijen at gmail dot com Summary: Release 1.1.0 has random behaviour Status: Open Type: Bug Package: *General Issues Operating System: CentOS 7 + RHEL6 PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Commited a fix to SVN. Thanks for the patch, but I don't think it's quite right - the problem is that the base64 encoded buffer is not zero terminated anymore after the 1.1 changes (wrapping in zend_string) so the strcpy overflows the allocated buffer (the size is correct). Fixed that by properly using strncpy. I guess this can be closed (and if someone can tell me how to get a bug category and developer access to it, that would be great). Previous Comments: ------------------------------------------------------------------------ [2016-09-17 16:15:22] tvdijen at gmail dot com Proposed fix: https://github.com/tvdijen/krb5/commit/e932d7a4240aac75c5bfe930f20033b4aee7c601 This fixed the problem for me. I think it needs space for a trailing null-character. ------------------------------------------------------------------------ [2016-09-17 14:57:11] tvdijen at gmail dot com Yet another update: I've managed to narrow it down to the strcpy lines at the bottom of the doAuthentication-function. Specifically the second one. Whenever I put in a RETURN_TRUE; above these lines, everything is working fine. When I put it underneath, de segfault is showing up again. ------------------------------------------------------------------------ [2016-09-17 12:25:23] tvdijen at gmail dot com I was also able to lift this error from /var/log/httpd/error.log: [Sat Sep 17 14:22:10.007578 2016] [core:notice] [pid 2914] AH00052: child pid 2920 exit signal Segmentation fault (11) ------------------------------------------------------------------------ [2016-09-17 11:39:28] tvdijen at gmail dot com This should be connected to the krb5-module: https://pecl.php.net/package/krb5 It somehow failed to do so. ------------------------------------------------------------------------ [2016-09-17 11:27:39] tvdijen at gmail dot com Description: ------------ The doAuthentication-method sometimes fails to return anything (execution stops). It actually fails more often than it works. This behaviour started after updating the krb5-module to the latest release 1.1.0. I started debugging my php-code by adding debug-lines. It turned out that code-execution stops at doAuthentication for no obvious reason. No errors are being displayed or even logged. See example-code below. When I start IE and run the test-script, it will fail with a 'Page cannot be displayed'. Apache access log shows that the page request is received. I can see my own debug-lines in the logs up to doAuthentication() and then I run into a dead end. When I repeat the test (close IE completely, start it again en run the script again), let's say one in ten times it fails. A rollback to version 1.0.0 of the module fixed everything, so my guess is that the recent changes have something to do with this random behaviour. I've seen this behaviour on both RHEL6+PHP5.3 and CentOS7+PHP5.4 Test script: --------------- <?php if(!extension_loaded('krb5')) { die('KRB5 Extension not installed'); } if(!empty($_SERVER['HTTP_AUTHORIZATION'])) { list($mech, $data) = explode(' ', $_SERVER['HTTP_AUTHORIZATION']); if(strtolower($mech) == 'basic') { echo "Client sent basic"; die('Unsupported request'); } else if(strtolower($mech) != 'negotiate') { echo "Couldn't find negotiate"; die('Unsupported request'); } $auth = new KRB5NegotiateAuth('/path/to/keytab'); if($reply = $auth->doAuthentication()) { header('HTTP/1.1 200 Success'); echo 'Success - authenticated as ' . $auth->getAuthenticatedUser() . '<br>'; } else { echo 'Failed to authN.'; die(); } } else { header('HTTP/1.1 401 Unauthorized'); header('WWW-Authenticate: Negotiate',false); echo 'Not authenticated. No HTTP_AUTHORIZATION available.'; echo 'Check headers sent by the browser and verify that '; echo 'apache passes them to PHP'; } ?> Expected result: ---------------- I'd expect doAuthentication() to at either return true/false or throw an error. Actual result: -------------- Code execution stops for no apparent reason. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73103&edit=1