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.
