Description:
------------
Currently the only real "solution" to Full Path Disclosure vulnerabilities in software developed in PHP is to keep display_errors disabled. If we wish to prevent disclosures at the application level instead, it is not currently possible with the current implementation of PHP:
- The output of Parse and Fatal Errors cannot be modified, far as I can tell
- Custom error handlers are needed to remove path strings for other errors, but if multiple frameworks are used together, the error handlers may conflict on which strings should be removed. Only 1 shutdown function can actually be used.

I propose that the default error handling in PHP be updated as follows:
- Include a new ini directive for fpd_prevention, defaulting to On or a string for replacement, like the ever-popular [path]
- Provide a new function hide_fpd_path (or pick a better name), defined as:
function hide_fpd_path($path, $replacement_string = '')
$replacement_string would default to the system defined [path] string or other ini value. The function provides an interface to a registry of paths that should not appear in error output, should an error occur.
- Automatically treat the paths in include_path (and updated by set_include_path) as if they were registered with hide_fpd_path using the default replacement string (or other [include-path] string). Because of set_include_path's existence, it may be best to apply this at error time.
- For convenience, perhaps automatically register the containing path of PHP_SELF.
- When outputting any error, including E_ERROR or E_PARSE, filter the file paths with this new registry, applying the most specific pathnames first. Now the security implications of display_errors are largely mitigated.
- Many custom error handlers use debug_backtrace. I would suggest adding a new DEBUG_BACKTRACE_SKIP_FPD constant in case the error handler absolutely does not want the paths filtered by PHP. However, because there are cases where multiple frameworks have error handlers with different internal filters, I believe the default behavior of debug_backtrace should pre-filter those. This way, other developers can add filters, regardless of whatever framework is on top.

By resolving full path disclosures at the scripting engine level, or at least providing a built-in solution for them (which by the way could be disabled if system administrators don't want to use it), PHP can help change the conversation on full path disclosures: Many instances of full-path disclosure vulnerabilities currently go unresolved because there is a debate whether they are configuration issues (of display_errors) vs bugs in the application, because some developers are resistant to writing software that works well in tandem with the software of other developers, and because many developers do not want to release security patches every time a fatal error is found. The question is sometimes raised whether FPD issues are really worthy of being considered security issues at all; however, I have seen authorities issue CVEs for them. I think this suggestion provides a solution for all these camps of people.

Thanks