Re: Re: Re: Re: Apache Server HTML Injection and UTF-7 XSSVulnerability

[yos20053@gmail.com]

Dear Bill From Apache

I think that you didn't understand this vulnerability properly. I ask to to check again and run this exploit with Firefox. After running this exploit, change manually the ecnoding in Firefox to UTF-7.. You will see that the alert will jump up. There is no problem to trick the victim and force him to change the encoding of his browser by little social engineering.

But if you, apache guys will set 403 page's charset in the server side by writing it in your server code, that will prevent this script running. In IE autoselect will work only if no charset was set to the page in server side.


We know how to solve this problem and if you want we can help you...

Best Regards and with big respect to Apache

Yossi Yakubov (Yos)
יוסי יעקובוב

[Paul Szabo]

Yossi Yakubov wrote in http://www.securityfocus.com/archive/1/492202 :

> if you, apache guys will set 403 page's charset ...

Done, as per http://www.securityfocus.com/archive/1/492094 :
>> All [current] releases include fixes ...

> ... change manually the ecnoding in Firefox to UTF-7 ... There is no
> problem to trick the victim and force him to change the encoding of
> his browser by little social engineering.

See https://bugzilla.mozilla.org/show_bug.cgi?id=408457 about how this
can be better exploited.

Cheers,

Paul Szabo psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

[Tim]

Hello Yossi,

I've read your previous messages and I'm not convinced.

> I think that you didn't understand this vulnerability properly. I ask
> to to check again and run this exploit with Firefox. After running this
> exploit, change manually the ecnoding in Firefox to UTF-7.. You will see
> that the alert will jump up. There is no problem to trick the victim and
> force him to change the encoding of his browser by little social
> engineering.

Hmm... just about as easy as convincing a user to blindly accept a
forged SSL certificate or run an executable. At that point, who cares?


> But if you, apache guys will set 403 page's charset in the server side
> by writing it in your server code, that will prevent this script
> running. In IE autoselect will work only if no charset was set to the
> page in server side.

So let's see here... You're advocating that all web pages should have
the character set defined in the page source via a meta/http-equiv tag
in order to prevent injections? This is bass-ackwards. Let me explain
why:

Think about what a browser has to do in order to interpret a page.
Before it interprets your meta tag, it already has to guess the content
type, right? If it doesn't know whether it's UTF-32be or UTF-16le, then
it has to guess before it can even locate your meta tag to determine
whether or not the guess was correct. This is just painful and probably
dangerous. http-equiv tags are a terrible idea and are only there
because so many web designers are clueless about how to set proper HTTP
headers.

The charset encoding could apply to any text-based content types besides
HTML. Is the meta tag useful then?

Unfortunately, many sites don't set the content-type/charset at all, so
browsers have to do guess work. Don't fault a web server which does set
it explicitly the right way simply because your browser is happens to
let you bend the rules.

tim

[William A. Rowe, Jr.]

yos20053@gmail.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@apache.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