Req #72527 [Opn->Sus]: Prevent FPD in Fatal/Parse/Other Errors
Edit report at https://bugs.php.net/bug.php?id=72527&edit=1
ID: 72527
Updated by: requinix@php.net
Reported by: pegasus at vaultwiki dot org
Summary: Prevent FPD in Fatal/Parse/Other Errors
-Status: Open
+Status: Suspended
Type: Feature/Change Request
Package: Output Control
Operating System: Centos 7 64-bit
PHP Version: 7.1.0alpha1
Block user comment: N
Private report: N
New Comment:
This is the kind of thing you need to bring up for discussion on the internals mailing list
(php-internals). It's too big and complicated of an issue for a mere bug tracker.
http://php.net/mailing-lists.php
Previous Comments:
------------------------------------------------------------------------
[2016-06-30 14:19:13] pegasus at vaultwiki dot org
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
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=72527&edit=1
Thread (2 messages)