php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54114 Output Buffer Dumps Data On Error
Submitted: 2011-02-28 07:43 UTC Modified: 2013-10-01 04:41 UTC
Votes:6
Avg. Score:5.0 ± 0.0
Reproduced:6 of 6 (100.0%)
Same Version:5 (83.3%)
Same OS:4 (66.7%)
From: danhstevens at gmail dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 5.3.5 OS: all
Private report: No CVE-ID: None
 [2011-02-28 07:43 UTC] danhstevens at gmail dot com
Description:
------------
When output buffering is turned on (via ob_start()) and an error is encountered before a call to ob_end_* is called the entire contents of the output buffer is dumped (to STDOUT) and there appears to be no way to prevent the buffer from dumping - not even by setting an error handler, etc.

This is a security issue since the output buffer may contain sensitive information that is them dumped over to the user. Using set_error_handler does not stop the dump - it appears the dump simply happens with no way to intercept or prevent it.

Test script:
---------------
<?php
ob_start();
echo 123;
trigger_error('test error', E_USER_ERROR);
$contents = ob_get_contents();
ob_end_clean();
?>

Expected result:
----------------
(no output)

Actual result:
--------------
123
Fatal error: test error in ...

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-28 19:37 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2011-02-28 19:37 UTC] rasmus@php.net
I am unable to reproduce this.  My test script:


<?php
function eh($errno, $errstr, $errfile, $errline) {
  $contents = ob_get_contents();
  ob_end_clean();
  echo "Error: $errno, $errstr, $errfile, $errline\n";
}
set_error_handler('eh');
ob_start();
echo 123;
trigger_error('test error', E_USER_ERROR);
echo "After error\n";


And my output is:

Error: 256, test error, /var/www/testing/o.php, 10
After error

No sign of "123" there.
 [2011-02-28 21:40 UTC] danhstevens at gmail dot com
-Status: Feedback +Status: Open
 [2011-02-28 21:40 UTC] danhstevens at gmail dot com
Hi Rasmus,

I was still able to create the problem by calling on a non-existing class to create a fatal error. Here is a variation of your code:

function eh($errno, $errstr, $errfile, $errline) {
  $contents = ob_get_contents();
  ob_end_clean();
  echo "Error: $errno, $errstr, $errfile, $errline\n";
}
set_error_handler('eh');
ob_start();
echo 123;
nonExistantClass::nonExistantMethod();
echo "After error\n";

Output is:
123
Fatal error: Class 'nonExistantClass' not found in ...

Hopefully the above should more accurately illustrate the issue.
 [2011-03-06 16:51 UTC] neweracracker at gmail dot com
I've managed to reproduce this in Windows 7 running php 5.2.17 (with php.ini-dist) and php 5.3.5 (with php.ini-development).

Here is my test script:
<?php
set_time_limit(1);
ob_start();
echo "You shouldn't see this!";
sleep(2); //comment this and you won't see the line above in output ;)
ob_end_clean();
?>

I've reported this as bug #54174 which got closed due being a dupe of this one so I am leaving this comment here for reference purposes.

Regards,
NewEraCracker.
 [2011-03-10 19:41 UTC] danhstevens at gmail dot com
I've found a viable work-around for this bug (although a patch of the core would still be ideal so people don't discover this potential security issue the hard-way).

By registering the following shutdown handler before any output buffering the dump of data can be prevented:

<?php
function shutdown_fn()
{
  //If ob_start has been called at least once
  if(ob_get_level() > 1)
  {
    //Prevent data in buffer from dumping
    ob_end_clean();
  }
}
register_shutdown_function('shutdown_fn');



Now when using the examples above that normally cause the buffer to dump to the client the buffer data is disposed of. Of course, this can be extended to use ob_get_contents and redirect the data to file or other means if necessary. This approach is working for me (on PHP 5.3.5).

~Dan
 [2011-08-17 13:44 UTC] nicolas dot grekas+php at gmail dot com
Here is an other example that can't be workaround using danhstevens' technique:

<?php

function my_shutdown()
{
    echo "secret\n";
    throw new Exception;
}

function ob_custom_filter($b)
{
    return str_replace('secret', '******', $b);
}

register_shutdown_function('my_shutdown');

ob_start('ob_custom_filter');

?>
 [2013-09-30 12:11 UTC] mike@php.net
-Status: Open +Status: Not a bug
 [2013-09-30 12:11 UTC] mike@php.net
I'm not sure why this should be security related?
Why even output security sensitive information at all?
 [2013-09-30 14:58 UTC] danhstevens at gmail dot com
Mike, this is a security issue because users of frameworks like Symfony are highly 
exposed to this bug. Symfony uses OB for parsing configuration files which often 
contain sensitive information. One syntax error in your config file and all your 
config params are on display to the www. It's unexpected behavior, and it can (and 
in my case, has) caused the release of sensitive information.
 [2013-09-30 18:05 UTC] mike@php.net
Well, this is pretty much the wrong 
way then, IMO.  Is this about Symfony 1 or 2?
 [2013-10-01 04:41 UTC] yohgaki@php.net
I think this is not issue of output buffer, but error handling.

There is bug report that fatal error should be catch-able.

I think PHP should allow catching fatal errors even if it may results in 
unexpected behavior. (i.e. Not all features work and could behave badly) Old PHP 
were able to catch E_ERROR, etc.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jan 18 08:03:18 2022 UTC