Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain vaultwiki.org designates 199.167.148.227 as permitted sender)
To: <internals@lists.php.net>
Date: Thu, 30 Jun 2016 12:17:30 -0400
Message-ID: <9f8e01d1d2ea$e728dc50$b57a94f0$@vaultwiki.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_9F8F_01D1D2C9.6018EA00"
Content-Language: en-us
Thread-Index: AdHS6bi/lhlT1y+NR3KWkPPAAOnHJQ==
Subject: Request: Prevention of FPD in Fatal/Parse/Other Errors
From: pegasus@vaultwiki.org ("Ted Phillips")

------=_NextPart_000_9F8F_01D1D2C9.6018EA00
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

Currently the only real "solution" to Full Path Disclosure =
vulnerabilities in software developed in PHP is to keep display_errors =
disabled. Even if a developer wishes to prevent disclosures at the =
application level instead, it is not currently possible with the current =
implementation of PHP:

=20

- The output text of Parse and Fatal Errors cannot be modified, far as I =
can tell

- Some errors can be triggered by specially crafted requests and occur =
before the application initializes (think max_input_vars, and other =
input-related errors)

- 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.

=20

I propose that the default error handling in PHP be updated as follows:

=20

- 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 =3D '')

$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.

- Automatically register the containing path of PHP_SELF at =
initialization. This will deal will fatal errors occurring before the =
application can specify its paths, such as when max_input_vars is =
exceeded by a crafted request.

- 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 or =
debug_print_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, developers of other modules and =
plugins can still add filters, regardless of whatever framework is on =
top.

=20

By resolving full path disclosures at the scripting engine level, or at =
least providing a built-in solution for them (which per my suggestion =
could be disabled if system administrators don't want to use it), PHP =
can help change the conversation on full path disclosures:

=20

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, =
especially when it is still possible to cause fatal errors that the =
application has no control over. 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.

=20

Thanks,

Ted


------=_NextPart_000_9F8F_01D1D2C9.6018EA00--