ID: 50754 User updated by: andrew at trib dot tv Reported By: andrew at trib dot tv Status: Bogus Bug Type: Output Control Operating System: Fed PHP Version: 5.3.1 New Comment:
Derek, Thank you for taking the time to select a canned response, though it would be much more encouraging to bug reporters if you actually responded to the points made (at length and in the correct manner) in the bug report before dismissing it as bogus. Could you comment on why this is not a security vulnerability? The security implications were initally raised *eight years ago* in bug 17874 by icecube at fr dot fm, but there has been no followup, hence my fresh bug report. If serialize($GLOBALS) manages to finish without crashing PHP and sending a half-complete invalid and potentially sensitive serialisation string to the browser / console, I don't understand why var_export can't do the same, nor what the justification is for claiming that the current behaviour is desirable. Cheers, Andrew Previous Comments: ------------------------------------------------------------------------ [2010-01-14 22:00:57] [email protected] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Remove the @ and you see what really happens: Fatal error: Nesting level too deep - recursive dependency? in - on line 9 ------------------------------------------------------------------------ [2010-01-14 16:52:57] andrew at trib dot tv Description: ------------ My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --------------- <?php class PrivateThing { public $publicvar = 'notsecret'; private $password = 'supersecret'; private $reftoself; function __construct() { $this->reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: ---------------- No passwords here! Actual result: -------------- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=50754&edit=1
