Req #72527 [NEW]: Prevent FPD in Fatal/Parse/Other Errors
| From: | pegasus at vaultwiki dot org | Date: | Thu, 30 Jun 2016 14:19:17 +0000 |
| Subject: | Req #72527 [NEW]: Prevent FPD in Fatal/Parse/Other Errors | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-201943@lists.php.net to get a copy of this message | ||
From: pegasus at vaultwiki dot org
Operating system: Centos 7 64-bit
PHP version: 7.1.0alpha1
Package: Output Control
Bug Type: Feature/Change Request
Bug description:Prevent FPD in Fatal/Parse/Other Errors
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 bug report at https://bugs.php.net/bug.php?id=72527&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=72527&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=72527&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=72527&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=72527&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=72527&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=72527&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=72527&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=72527&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=72527&r=support
Expected behavior: https://bugs.php.net/fix.php?id=72527&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=72527&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=72527&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=72527&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=72527&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=72527&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=72527&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=72527&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=72527&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=72527&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=72527&r=mysqlcfg