lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Apr 2006 03:11:34 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Mis-diagnosed XSS bugs hiding worse issues due to
	PHP feature



In a post-disclosure analysis [1] of a security issue announced by
rgod [2], Siegfried observed that the reported XSS actually originated
from a file inclusion vulnerability, in which the XSS was reflected
back from an error message when the file inclusion failed:

>About the xss, it is an xss in the php error message, there are many
>php functions returning errors without filtering them, anybody noted
>that?

Yes.

I would greatly appreciate some corroboration from the real PHP/web
security experts out there on what I'm about to say.  If true, it
would partly explain why XSS is so rampant in PHP applications.

As I understand it, this behavior is due to an XSS problem in PHP
itself before 5.1.2 (CVE-2006-0208), as announced in January 2006:

  http://www.php.net/release_5_1_2.php

It's not clear if PHP 4.x was affected.

The XSS happens when display_errors and html_errors are enabled - it
won't quote the output from raw error messages.

No doubt many so-called XSS errors these days are the result of this
particular issue in PHP.  They're aren't entirely the application's
fault, although obviously they indicate the lack of strong input
validation.

This can hide much more serious vulnerabilities, like file inclusion,
directory traversal, or SQL injection.  I have mentioned this in the
past, but now we know why this seems to happen so often.
(Application-controlled error handlers can still be subject to XSS of
course, even under a fixed PHP.)

For those who do post-disclosure analysis: there *might* be a
resultant XSS issue if the researcher claims both XSS and another type
of bug in the same affected parameter/component, or if the
researcher's report includes error messages that don't seem to be
sanitizing XSS-tainted output.

- Steve

[1] http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044756.html

[2] http://retrogod.altervista.org/claroline_174_incl_xpl.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ