Date: Thu, 15 Feb 2007 18:26:59 +0100
From: "Rogier Mulhuijzen" <rogier.mulhuijzen@...ice.casema.nl>
To: <hugo@...ohacking.com>, <bugtraq@...urityfocus.com>
Subject: RE: Apache Multiple Injection Vulnerabilities

No offence meant, but in all of your advisory only the control-code stuff and possibly pissing off IPS/IDS systems makes sense. 

But you need to have the user click a URL on a page you control. If a URL he clicks on your site makes the IPS/IDS shout alerts, he might just get a clue, and suspect your site instead of the site you linked to. Either way, it's harmless, as long as there are no weird bugs in browsers concerning this. But even then it's just as easy to make your own webserver spew out the harmful data. 

Now correct me if I'm wrong, but your cache poisoning in combination with redirection only works if you can edit the html files accessed. Well now, if you can edit the html files, you can just put redirects in there. Now, I agree that it's a bug, but it's not a _security_ bug.

Other than that, the fact that the Host header is used to make redirects, is absolutely normal, not a bug, not a security bug by a long shot. If the user can reach a server with a certain hostname, getting a redirect with the same hostname is something you'd want. The fact that you can manually craft a header with a fake hostname doesn't mean you can get a user's browser to do that.

You have a nice "Proof of Concept" on your site, where you put some JavaScript in the Host header of the request. But how would you ever get a user's browser to have that crafted header? If you can control the browser to that extent, there are much much worse things you can do. And if you craft a URL with that as a hostname, the browser will not be able to resolve it to an IP.

Greetings,

	Rogier

> -----Original Message-----
> From: hugo@...ohacking.com [mailto:hugo@...ohacking.com]
> Sent: woensdag 14 februari 2007 6:21
> To: bugtraq@...urityfocus.com
> Subject: Apache Multiple Injection Vulnerabilities
> 
> There's a new advisory at:
> http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/apache/inde
> x.html
> 
> Summarizing:
> 
> "1.- HTTP 404 error response almost arbitrary injection (Apache)
> 
> Impact right now:
> 
> a) fake virus injection in Apache 404 HTTP responses wich can lead in
> alarms on corporate gateway antivirus, lose of trust on supposed trusted
> sites, end user paranoid...
> 
> b) Control codes injection -backspaces, etc.- thus allowing script
> injection in the server response. Right now it seems that this
> vulnerability is not
> affecting real browsers, just because of the "backspace" escaping in the
> clients, or due to other things. Anyway, the problem is that echoing back
> control codes is a violation of the Content-Type charset in the response
> and is IMHO a security risk.
> 
> Impact in the future: REAL injection in Apache 404 HTTP responses of
> almost any kind of file, that is virus, binaries, trojans, etc. The
> attacker must
> be able to modify the "Content-Type" HTTP header of the server response.
> Also, due to some restrictions in the injected "payload", the attacker
> must avoid
> using some chars like null bytes.
> 
> 2.- Location HTTP header injection in server redirect responses (Apache,
> IIS, Zeus 3.2, Google Web Server, Jigsaw/2.2.5, probably many
> others)
> 
> Impact: Depending on the affected web server it could be a Denial of
> Service -when combined with a proxy caché poisoning-, HTTP URL
> redirection, etc."


This e-mail message and its attachments are subject to the disclaimer published at the following website of Casema: http://www.casema.nl/disclaimer

Powered by blists - more mailing lists