BugTraq
Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability May 17 2008 07:19PM
yos20053 gmail com (3 replies)
Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSSVulnerability May 17 2008 10:55PM
Tim (tim-security sentinelchicken org)
Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability May 17 2008 10:12PM
Paul Szabo (psz maths usyd edu au)
Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability May 17 2008 10:10PM
William A. Rowe, Jr. (wrowe rowe-clan net)
yos20053 (at) gmail (dot) com [email concealed] wrote:
> Dear Bill From Apache
>
> I think that you didn't understand this vulnerability properly.

We understand it quite well; we simply disagree on the context of which
is vulnerable, the Apache server which holds to RFC2616, or IE (and Firefox
apparently in some cases) which do not. Even allowing for the flexibility
of toggling between ISO, UTF-8 and other 7bit ascii-clean character sets,
the choice by IE and Firefox to violate the RFC in this manner accepting
by guesswork UTF-7 with no canonical definition of the basic HTML control
set clearly has broader implications. I trust as a researcher you can fill
your days for a good long time finding similarly vulnerable configurations
and applications, when in fact the origin of this problem lies in the client.

> We know how to solve this problem and if you want we can help you...

As do we; I mentioned in my first reply that the workaround is in place for
a host of Apache-generated responses, including 403 errors, as of the
current releases of the code (2.2.8, 2.0.63 and 1.3.41). But again this
is working around the client's flaw, not a vulnerability fix of Apache's
flaw, which is why the security team deliberately did not allocate a CVE
at the time these changes were applied. [Some related XSS flaws which
did not rely on client misbehavior were tagged as vulnerabilities.]

For future reference, you are certainly welcome at security (at) apache (dot) org [email concealed] to
sanity check future vulnerability reports before publication, we are always
happy to help out researchers. And we are also very happy to coordinate
security patch releases with scheduled publication of vulnerabilities for
those who prefer this method, although we talk equally with full-disclosure
folk as well.

Bill

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus