bugtraq - Re: Re: 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>] [day] [month] [year] [list]

Date: Thu, 15 May 2008 00:10:36 +0200
From: "lament hero" <lament.hero@...il.com>
To: bugtraq@...urityfocus.com
Subject: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSS Vulnerability

Hello,

Please try to understand what we did here.
You might be right in here:

"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 in violation of RFC 2616."

But as I said in the 1st mail that I sent:

"We leave it to other hackers to upgrade the attack and make it fully
automatic."

I mean that the FireFox will not show the XSS unless you change the encoding.
If it was "fully automatic" it could change the FireFox encoding, but
it's not it's only a PoC.

Try to change FireFox to auto-select and refresh it so it will jump to UTF-7.

Yaniv Miron aka "Lament".

______________________________
__________
Gentlemen,

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.

There are several workarounds in Apache HTTP Server to prevent Microsoft's
vulnerability, including

AddDefaultCharset ISO-8859-1

or by enabling multilanguage error docs (with explicit charsets) by simply
uncommenting this Include directive of the default httpd.conf file;

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

All releases after Jan 2 include a global fix that adds an explicit
charset iso-8859-1 to compensate for Microsoft's vulnerability, including
2.2.8, 2.0.63, and 1.3.41.  However this vulnerability should clearly be
labeled as a flaw in Internet Explorer.

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 in violation of RFC 2616.

We are be pleased to offer SecurityFocus the opportunity correct this
misinformation before we raise issue on the public discussion forums.

Bill
Apache HTTP Server