php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #72527 Prevent FPD in Fatal/Parse/Other Errors
Submitted: 2016-06-30 14:19 UTC Modified: 2016-06-30 14:59 UTC
From: pegasus at vaultwiki dot org Assigned:
Status: Suspended Package: Output Control
PHP Version: 7.1.0alpha1 OS: Centos 7 64-bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
27 - 15 = ?
Subscribe to this entry?

 
 [2016-06-30 14:19 UTC] 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


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-06-30 14:59 UTC] requinix@php.net
-Status: Open +Status: Suspended
 [2016-06-30 14:59 UTC] requinix@php.net
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
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 17:01:29 2024 UTC