bugtraq - Re: Apache Multiple Injection Vulnerabilities

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-prev] [day] [month] [year] [list]

Date: Tue, 20 Feb 2007 19:38:11 +0200
From: Amit Klein <aksecurity@...il.com>
To: hugo@...ohacking.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Apache Multiple Injection Vulnerabilities

hugo@...ohacking.com wrote:
> There's a new advisory at:
> http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/apache/index.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."
>
>   

Hi

I've been discussing this off-list with Hugo (the paper's author).

1. The redirection issue, if it exists, is relevant only to redirection 
through HTTP responses with status code 301. In other words, it seems 
that Apache 2.0 mod_cache+mod_proxy doesn't cache HTTP 302 responses.

2. In my experiments, the whole issue does not exist in the "standard" 
reverse proxy configuration. By default, the proxy server does not 
forward the HTTP Host header. Instead, it uses the host as it appears in 
the ProxyPass directive. The directive that governs whether the Host 
header will be preserved or not is ProxyPreserveHost 
(http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost). 
And the example configuration for reverse proxy 
(http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#examples) doesn't 
override this default.
Unfortunately, Hugo's configuration file (as well as his proxy server 
machine) is no longer available, so we cannot reproduce the case in 
Hugo's lab. Hugo told me that his configuration was based off that 
example snippet from the Apache mod_proxy documentation (see above), 
which does not include ProxyPreserveHost.

3. I noticed some weird caching results with my own Apache 2.0 
mod_proxy+mod_cache when 301 response is cached - something quite 
different from Hugo's results.

I encourage readers to test the 301 redirection scenario and report to 
the list whether the Host header was forwarded to the web server or not.

Thanks,
-Amit