full-disclosure - Re: Mis-diagnosed XSS bugs hiding worse issues due to PHP feature

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-prev] [day] [month] [year] [list]

Date: Sun Apr  2 16:23:26 2006
From: max at jestsuper.pl (Maksymilian Arciemowicz)
Subject: Re: Mis-diagnosed XSS bugs hiding worse issues
	due to PHP feature

On Saturday 01 April 2006 10:11, Steven M. Christey wrote:

We have reported this xss (in php display_errors) 28 May 2005. 

http://bugs.php.net/bug.php?id=33173&edit=1
Replay from php developers : ------------"Bogus". ------------
"...Show erros is only a convenience thing to aid you while developing. Thus 
no user will ever see such error messages. So in the end it is not usable for 
phishing and alike..."

Many functions in php are vulnerability of xss. It is no dangerous but can't 
exists. For example 
http://securityreason.com/achievement_securityalert/18
or
gpg version: http://securityreason.com/achievement_securityalert/18/1
function include() in postnuke.

> 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

SecurityReason.Com Europe
-- 
pub   1024D/7FDF4CEE 2005-09-21
uid                  Maksymilian Arciemowicz (cXIb8O3) <max@...tsuper.pl>
sub   2048g/AE816DB6 2005-09-21