php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #64439 \0 causes error_log strings to be truncated
Submitted: 2013-03-16 06:03 UTC Modified: 2021-07-19 14:00 UTC
Votes:3
Avg. Score:3.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: eric at wepay dot com Assigned: cmb (profile)
Status: Closed Package: *General Issues
PHP Version: 5.4.13 OS: CentOS
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: eric at wepay dot com
New email:
PHP Version: OS:

 

 [2013-03-16 06:03 UTC] 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-19 11:41 UTC] 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-10-24 05:28 UTC] yohgaki@php.net
-Type: Bug +Type: Documentation Problem -Package: Scripting Engine problem +Package: Documentation problem
 [2013-10-24 05:28 UTC] yohgaki@php.net
This should be documented.
 [2013-10-24 05:30 UTC] 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-30 00:42 UTC] 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-11-01 06:34 UTC] yohgaki@php.net
-Type: Documentation Problem +Type: Feature/Change Request -Package: Documentation problem +Package: *General Issues
 [2013-11-01 06:34 UTC] yohgaki@php.net
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.
 [2016-09-04 14:22 UTC] yonelceruto at gmail dot com
I've faced with this issue too, so my question is: Why "\0" character is dumped when private or protected properties are serialized ? It is needed for unserialize process?
 [2021-07-19 14:00 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2021-07-19 14:00 UTC] cmb@php.net
This issue is fixed as of PHP 8.1.0[1].  Note that
syslog.filter[2] already allows to escape characters as of PHP
7.3.0.

[1] <https://github.com/php/php-src/pull/7245>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 13:01:28 2024 UTC