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-next>] [day] [month] [year] [list]
Date: Wed, 14 May 2008 12:28:23 -0500
From: "William A. Rowe, Jr." <wrowe@...e-clan.net>
To: bugtraq@...urityfocus.com
Subject: Correction to BID 29112 "Apache Server HTML Injection and UTF-7 XSS
 Vulnerability"

HTTP User and Desktop Security Communities;

With respect to http://www.securityfocus.com/bid/29112

Per http://www.ietf.org/rfc/rfc2616.txt

3.7.1 Canonicalization and Text Defaults
[...]
    The "charset" parameter is used with some media types to define the
    character set (section 3.4) of the data. When no explicit charset
    parameter is provided by the sender, media subtypes of the "text"
    type are defined to have a default charset value of "ISO-8859-1" when
    received via HTTP. Data in character sets other than "ISO-8859-1" or
    its subsets MUST be labeled with an appropriate charset value. See
    section 3.4.1 for compatibility problems.

Internet Explorer's autodetection of UTF-7 clearly violates this
specification, introducing the opportunity for myriad similar attacks.
These are literally everywhere on the web today, we can trust the kids
to continue to explore this vector until it is fixed by Microsoft.

There are several workarounds in Apache HTTP Server to dodge this particular
vulnerability on your own sites, including

   AddDefaultCharset ISO-8859-1

and by enabling multilanguage error docs (each translation with an explicit
charset) by simply uncommenting this Include of the default httpd.conf file;

   # Multi-language error messages
   Include conf/extra/httpd-multilang-errordoc.conf

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.

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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ