Message-ID: <35642.217.201.68.230.1143923071.squirrel@webmail.zone-h.fr>
Date: Sat, 1 Apr 2006 22:24:31 +0200 (CEST)
From: "Siegfried" <admin@...e-h.fr>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	coley@...re.org
Subject: Re: Mis-diagnosed XSS bugs hiding worse issues due to PHP feature


Recently i saw http://seclists.org/lists/fulldisclosure/2006/Mar/1815.html

The person who found it sent it to me before sending it elsewhere, as i
thought he wouldn't send it to any mailing list, i decided to verify the
information, and the directory traversal isn't just a directory traversal,
if you look at the code, you see this:

----------------------
if(!empty($chemin))     $chemin     = stripslashes($chemin); else $chemin
= $depart;


// ----------------------------------- Sécurité navigation
-------------------------------------------------- //

$chemintotal = $chemin;

// ------------------------------- Récupération des fichiers et
répertoires dans tableau-- //


$handle  = @opendir($chemintotal);
$file    = @readdir($handle);
-----------------------

This poor check doesn't secure anything as it doesn't check slashes, and
it's useless, BUT this isn't just a directory traversal as you can do
http://[target]/dir.php?chemin=/etc/
and it works as well..

I usually don't verify them as i don't have the time, but when i verify
and find incorrect informations, i see that i'm the only one correcting it
(on my site), and many security sites just relay the information because
they don't have the time to verify them too.

You guys of mitre can't make something like a "verification process" ? or
another web site to verify all the informations, i think it becomes really
necessary..

Siegfried


Le Sam 1 avril 2006 19:13, Siegfried a écrit :
> About that xss, it was really a normal xss, like i wrote in my second post
> (i respect rgod's work because he always made good analysis and good
> advisories). But there are indeed many vulnerabilities that are classified
> as XSS while they were much more than a XSS, or a XSS in a PHP error
> message.
>
> Those XSS issues are actually vulnerabilities that were fixed in PHP 5.1.2
> (i know at least 2 examples: an inclusion error message, a missing
> function which name is based on user supplied data).
>
> See also:
> http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2005-10/0040.html
>
> There is also this problem with SQL injection vulnerabilities, everyday we
> see a bunch of XSS and SQL injection advisories, but who has the time to
> check them all? ..
>
> Siegfried
>
Le Sam 1 avril 2006 10:11, Steven M. Christey a écrit :
>
> 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
>

Powered by blists - more mailing lists