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

This is how var_dump is supposed to work. It's a debug function.

If it not bug, then lucky day for hackers. If i hide db name, psw dto class, hacker can easy show it only with php command :)
I think, this is very stupid bug. I now need find new methode to hide password.

If a hacker has access to write arbitrary PHP on a site he can simply open up the file containing the private properties and look at them. The access level of a property is not a security feature.

Must know file path. But, if i open file do $tmp and rewrite to clas, unset($tmp), unset($CFG), hacker no have information.

A simple call to get_included_files() or a shell out to a grep will trivially get the file path.

example:

$path = '...';
$str = file_get_content($path);
$CFG = parseXYZ($str);
$my_class->setCfg($CFG);
unset($path);
unset($CFG);
var_dump($path);

You not know $path, if you not read this file. You can use file_get_content. But, i can use fileReader.php, read from directory blocked by .htaccess for only read for only this file. I can counting reading files in private variable. Readed cfg or not. You cannot use double times to read one file.

Just curious. If you want to steal "private" property info, why don't you use debug_zval_dump()?

$ php -r 'class foo { private $p = "abc"; } $o = new foo; debug_zval_dump($o);'
object(foo)#1 (1) refcount(2){
  ["p":"foo":private]=>
  string(3) "abc" refcount(2)
}

I guess you would like to hide sensitive information in script/object variable from malicious "modules"/"extensions", but it's impossible for many languages/platforms. Java does not allow to dump objects like PHP. Not sure how well other scripting languages hide private property (and app installation path). Are there scripting languages hide private property well and/or hide file path information? (I'm curious about path, too. You can get file path by __FILE__ constant to know app installation path)


Mitigation:
var_dump()/debug_zval_dump()/get_included_files()/etc are debugging functions. Disable them by disable_functions INI. Or applications can tokenize module/extension PHP code and check unwanted functions. This is very fragile security measure because of nature of blacklist security, though.

disable_functions is INI_SYSTEM
main/main.c:562:	PHP_INI_ENTRY("disable_functions",			"",			PHP_INI_SYSTEM,		NULL)

I guess most secure apps are using environment variables for security sensitive information, so getenv() should be restricted in this case. However, getenv() may be used for good reasons.

We may consider change it to INI_PERDIR, perhaps?
It may not be feasible. I don't check the code.

"Securing PHP application module/extension" is interesting topic, but we don't provide it now.

Suggestions are welcome. e.g. Framework that is relatively secure PHP script module/extension, hides application's sensitive information.