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  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: Mon, 09 Jun 2008 16:07:02 -0500
From: "William A. Rowe, Jr." <wrowe@...e-clan.net>
To: bugtraq@...urityfocus.com
Subject: Further Correction to BID 29112 "Apache Server HTML Injection and
 UTF-7 XSS Vulnerability"

William A. Rowe, Jr. wrote:
> With respect to http://www.securityfocus.com/bid/29112
> 
> All releases after Jan 2 include fixes across the board to add an explicit
> charset iso-8859-1 to the built in Apache HTTP modules to compensate for
> Microsoft's vulnerability, including released versions 2.2.8, 2.0.63, and
> 1.3.41.  This does not affect third party modules you may be loading,
> applications hosted-on or proxied-through HTTP Server, etc.

Having reviewed the vulnerability history again, those versions corrected
the unexploitable bug which echoed the supplied HTTP method (CVE-2007-6203).

In fact, the 1.3.34. 2.0.55 and all 2.2 releases resolved the Apache flaw
and tag all canned error responses with charset=iso-8859-1, as identified by 
lament hero with bid 29112.  So why would he be so clueless as to report
these later versions as affected?  Simply, by observation.

My colleague Adam Qualset of Covalent has researched and confirmed that all
versions of IE are exploitable with UTF-7 in the presence of a Content-type
charset field.  As originally cited...

> However this vulnerability should clearly be labeled as a flaw in Internet
> Explorer.  If the browsers under your supervision continue to enable the
> autodetection of UTF-7, your users remain at risk.  As all ISO, UTF-8 and
> related charsets were 7-bit clean, it's clear that Microsoft err'ed on
> the side of accepting UTF-7 charset for automatic detection, contrary to
> to the behavior dictated by RFC 2616.

So this statement stands, and exploits even via IIS itself should be trivial
to construct for the enthusiastic student.

I encourage the securityfocus team to update this vulnerability report
appropriately, and also please note that the cited homepage for References
should be http://httpd.apache.org/ with respect to any Apache HTTP Server
issues.

Many thanks,

Bill

Powered by blists - more mailing lists