Doc->Req #64439 [Opn]: \0 causes error_log strings to be truncated

Edit report at https://bugs.php.net/bug.php?id=64439&edit=1 ID: 64439 Updated by: yohgaki@php.net Reported by: eric at wepay dot com Summary: \0 causes error_log strings to be truncated Status: Open -Type: Documentation Problem +Type: Feature/Change Request -Package: Documentation problem +Package: *General Issues Operating System: CentOS PHP Version: 5.4.13 Block user comment: N Private report: N New Comment: Thanks for the info, but I knew this kind of attack can be done. Anyway, even if we made logging binary safe, there would be other problems. We cannot simply escape special chars because it may broke log analyzers. It's possible escape special chars, but it would not happen in released version. There is developer working on this issue. Changed bug type. Previous Comments: ------------------------------------------------------------------------ [2013-10-30 00:42:10] spam2 at rhsoft dot net this is also *security relevant* simply strip or escape control chars and you are done study the mod_security code, they know how to escape log lines http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1862 ------------------------------------------------------------------------ [2013-10-24 05:30:10] yohgaki@php.net Automatic comment from SVN on behalf of yohgaki Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=331939 Log: Fixed Doc Bug #64439 \0 causes error_log strings to be truncated ------------------------------------------------------------------------ [2013-10-24 05:28:11] yohgaki@php.net This should be documented. ------------------------------------------------------------------------ [2013-03-19 11:41:45] laruence@php.net hmm, yes, error_log is not binary safe. and fix that need a huge work, all sapi's log message need to be updated. and also send mail, log to file related apis a workaround could be done at user side. ------------------------------------------------------------------------ [2013-03-16 06:03:30] eric at wepay dot com Description: ------------ A string containing "\0" passed into error_log() causes the message to be truncated after that character. This is especially apparent when a log message contains a serialized object which has private properties, as their serialization key is \0classname\0propname. file_put_contents is not affected, nor is using error_log with the destination parameter; only when using the ini setting. Digging around through source, it looks like it's caused by the use of c strlen() in xbuf_format_converter (main/spprintf.c:576) which assumes null-terminated strings, called by vspprintf() -> ssprintf() -> php_log_err() Happens in 5.4.x as well as a just-built git master 5.6.0-dev Test script: --------------- <?php class a { private $b = 'c'; } $obj = new a; $str = serialize($obj); ini_set('error_log', '/Users/eric/Desktop/error_log.log'); error_log($str); // truncated file_put_contents('/Users/eric/Desktop/fpc.log', $str); // ok error_log($str, 3, '/Users/eric/Desktop/error_log_param.log'); // ok Expected result: ---------------- All three files should contain the following string: O:1:"a":1:{s:4:"ab";s:1:"c";} (note that "ab" is actually "\0a\0b") Hex dump: 4F 3A 31 3A 22 61 22 3A 31 3A 7B 73 3A 34 3A 22 00 61 00 62 22 3B 73 3A 31 3A 22 63 22 3B 7D Actual result: -------------- error_log.log contains only the following: [16-Mar-2013 04:23:06 UTC] O:1:"a":1:{s:4:" (the timestamp is not relevant) 4F 3A 31 3A 22 61 22 3A 31 3A 7B 73 3A 34 3A 22 0A The other two files (error_log_param.log, fpc.log) correctly record the full string. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=64439&edit=1