bugtraq - Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability

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

Message-ID: <482F57BB.3020708@rowe-clan.net>
Date: Sat, 17 May 2008 17:10:03 -0500
From: "William A. Rowe, Jr." <wrowe@...e-clan.net>
To: yos20053@...il.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability

yos20053@...il.com 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@...che.org 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