The https://www.mozilla.org and https://bugzilla.mozilla.org servers both bear a certificate valid for *.mozilla.org and respond to connections that specify an incorrect HTTP Host header with a redirect to a http:// URL. As a result, a network attacker can divert a client connection bound for any *.mozilla.org site to one of these servers and cause the client to receive an incorrect redirect. This is already a breach of the integrity that SSL is supposed to provide. But what is worse, since the redirect is to http://, the attacker can substitute arbitrary content and thereby perform XSS.
An attack would look like this:
1. User navigates to https://bugzilla.mozilla.org/ .
2. Client connects to bugzilla.mozilla.org:443 to retrieve the HTML page; attacker lets it through.
3. Client opens additional connections to bugzilla.mozilla.org:443 to request embedded scripts. Attacker diverts them to www.mozilla.org:443. The www.mozilla.org server responds with redirects to http://www.mozilla.com/ .
4. Client follows the redirect and fetches http://www.mozilla.com/ . Attacker substitutes a malicious script. Client executes it in the https://bugzilla.mozilla.org/ origin.
How would the attacker perform step 3 without breaking the ssl connection and thus generating a certificate error alert to the user?
www.mozilla.org:443 bears a certificate valid for bugzilla.mozilla.org, so the client will not see anything wrong.
This is true that the certificate is valid for both sites. However there is no way an attacker could force the user that is accessing a page over https to redirect to another location. Any attempt to modify or inject content into a request or response would require the attacker to compromise the ssl connection between the victim and the server. This could be done with a man in the middle attack but the mitm would have to use an invalid certificate and this would generate an alert to the user.
(In reply to comment #3)
> However there is no
> way an attacker could force the user that is accessing a page over https to
> redirect to another location.
I'm proposing that the attacker intercept the TCP connection to bugzilla.mozilla.org:443 and divert it to www.mozilla.org:443, so that the client completes an SSL handshake with the real www.mozilla.org thinking it is bugzilla.mozilla.org.
I understand now. I will look into this and update the bug. I will most likely have more information tomorrow.
I have reviewed the issue and confirmed your concern. Defenses are in place to redirect requests that contain host headers that do not match the domain of the URL. However, as you've pointed out, this sometimes results in redirects to HTTP pages which could be intercepted by an attacker and modified with malicious content.
A few notes:
1. This would require the ability to perform dns rebinding against the victim. So this would be a targeted attack.
2. The user would receive a mixed content SSL warning message in the browser since the modified content would be sent over HTTP
Either way, it should be fixed. I'll work on getting this closed up. My thoughts are to modify the host header mismatch scenario to either throw a 404 or just use https in all situations.
(In reply to comment #6)
> 2. The user would receive a mixed content SSL warning message in the browser
> since the modified content would be sent over HTTP
By default, Firefox shows the mixed content warning only once, and the scenario is (unfortunately) common on legitimate sites, so it is unlikely to be a mitigation.
> Either way, it should be fixed. I'll work on getting this closed up. My
> thoughts are to modify the host header mismatch scenario to either throw a 404
> or just use https in all situations.
Thanks. If you change the redirects to https, that will close off the script injection, but a network attacker will still be able to cause the client to see the wrong site: strictly speaking a vulnerability, though the impact is presumably low. While you're looking at this, I would encourage you to fix the issue all the way by returning an error, preferably one from which the client is unlikely to draw a false assumption about the real server (e.g., that the file actually does not exist). 400, 403 or 503 would be decent, or you could make up your own status like "566 Under Attack". The ideal behavior for SNI clients would be to fail the SSL handshake with an unrecognized_name alert, but Apache doesn't seem to support that; maybe I will file an enhancement request.
I don't understand how redirects are a solution. If the Host header doesn't match you know there's some kind of attack, or at the very least serious routing problems. Where do you redirect? If anything maybe back to the host in the Host header, but if it's an attack that resource might not exist. The host header already tells you the client didn't want to go to www.mozilla.org so I don't know why you'd ever redirect there.
I'm with Matt on the error code, 403 seems right. 400 would be ok. 503 is supposed to imply a temporary condition that the client can retry so I'm less keen on that one. I don't trust various machines on the path (proxies? the client?) to handle a made-up error code correctly so I'm not keen on 566 either.
The 403 works for me. Oremj can we do that?
Just to be clear on what needs to be done. We want to return 403 for any Host header that is not specifically defined in a virtualhost?
(In reply to comment #10)
> Just to be clear on what needs to be done. We want to return 403 for any Host
> header that is not specifically defined in a virtualhost?
Yes, oremj I add chatted on irc. We are just modifying the response given from our current host header checks. We will 403 instead of redirect. Original host header checks implemented in bug 573917
I'll do this on Monday, so nothing randomly breaks over the weekend.
Well... are you going to make the change?
I've set the default vhost to be 403 on all clusters. Let me know if I missed anything.
Great, I will update our regression testing script to verify the change and ensure we didn't miss anything.
With this in the hosts file (that is the IP address for bugzilla.mozilla.org):
I am still seeing:
$ curl --include https://www.mozilla.org/
HTTP/1.1 301 Moved Permanently
Date: Fri, 12 Nov 2010 22:40:50 GMT
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>301 Moved Permanently</title>
<p>The document has moved <a href="http://www.mozilla.org/">here</a>.</p>
I never touch the bugzilla cluster. Justdave should be able to fix it though.
That particular check is set up exactly the same way it is on all the other clusters (dummy default virtual host).
--- aa_default_vhost.conf (revision 9677)
+++ aa_default_vhost.conf (working copy)
@@ -5 +5 @@
- RewriteRule .* http://www.mozilla.org/ [R=301]
+ RewriteRule .* - [F]
@@ -18 +18,2 @@
- Redirect permanent / http://www.mozilla.org/
+ RewriteEngine On
+ RewriteRule .* - [F]
bugzilla.mozilla.org seems to be fixed: the test in comment #16 gives me a 403 error.
Will someone make this bug public now? It doesn't look like I can.
Bugzilla is fixed and returning a 403