Last Comment Bug 607807 - https://{www,bugzilla}.mozilla.org accept diverted SSL connections
: https://{www,bugzilla}.mozilla.org accept diverted SSL connections
Status: RESOLVED FIXED
:
Product: mozilla.org
Classification: Other
Component: Security Assurance (show other bugs)
: other
: All All
: -- major (vote)
: ---
Assigned To: Jeremy Orem [:oremj]
: Chris Lyon [:clyon]
Mentors:
Depends on:
Blocks: 627964
  Show dependency treegraph
 
Reported: 2010-10-27 16:08 PDT by Matt McCutchen
Modified: 2011-01-21 20:12 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Matt McCutchen 2010-10-27 16:08:48 PDT
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.
Comment 1 Michael Coates [:mcoates] (acct no longer active) 2010-10-27 18:35:43 PDT
How would the attacker perform step 3 without breaking the ssl connection and thus generating a certificate error alert to the user?
Comment 2 Matt McCutchen 2010-10-27 18:38:26 PDT
www.mozilla.org:443 bears a certificate valid for bugzilla.mozilla.org, so the client will not see anything wrong.
Comment 3 Michael Coates [:mcoates] (acct no longer active) 2010-10-27 18:44:14 PDT
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.
Comment 4 Matt McCutchen 2010-10-27 18:47:42 PDT
(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.
Comment 5 Michael Coates [:mcoates] (acct no longer active) 2010-10-27 18:51:33 PDT
I understand now. I will look into this and update the bug. I will most likely have more information tomorrow.
Comment 6 Michael Coates [:mcoates] (acct no longer active) 2010-10-28 11:32:17 PDT
Matt,

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.  

As you mentioned, an attacker could use a dns rebinding style attack to cause this header mismatch on a request for JavaScript made by the primary page. In this situation the attacker would wait for the auto redirect to http://www.mozilla.org and then inject content in the clear text response. This would ultimately infect the users https connection with the original site.

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.
Comment 7 Matt McCutchen 2010-10-28 13:17:43 PDT
(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.
Comment 8 Daniel Veditz [:dveditz] 2010-10-28 20:10:43 PDT
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.
Comment 9 Michael Coates [:mcoates] (acct no longer active) 2010-10-28 20:19:10 PDT
The 403 works for me. Oremj can we do that?
Comment 10 Jeremy Orem [:oremj] 2010-11-05 13:04:05 PDT
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?
Comment 11 Michael Coates [:mcoates] (acct no longer active) 2010-11-05 13:51:57 PDT
(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
Comment 12 Jeremy Orem [:oremj] 2010-11-05 15:25:22 PDT
I'll do this on Monday, so nothing randomly breaks over the weekend.
Comment 13 Matt McCutchen 2010-11-12 06:59:05 PST
Well... are you going to make the change?
Comment 14 Jeremy Orem [:oremj] 2010-11-12 12:10:38 PST
I've set the default vhost to be 403 on all clusters. Let me know if I missed anything.
Comment 15 Michael Coates [:mcoates] (acct no longer active) 2010-11-12 13:09:12 PST
Great, I will update our regression testing script to verify the change and ensure we didn't miss anything.
Comment 16 Matt McCutchen 2010-11-12 14:42:59 PST
With this in the hosts file (that is the IP address for bugzilla.mozilla.org):

63.245.209.72   www.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
Server: Apache
X-Backend-Server: pm-app-bugs03
Location: http://www.mozilla.org/
Content-Length: 231
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.mozilla.org/">here</a>.</p>
</body></html>
Comment 17 Jeremy Orem [:oremj] 2010-11-12 17:11:13 PST
I never touch the bugzilla cluster. Justdave should be able to fix it though.
Comment 18 Dave Miller [:justdave] (justdave@bugzilla.org) 2010-11-15 12:53:20 PST
That particular check is set up exactly the same way it is on all the other clusters (dummy default virtual host).

Index: aa_default_vhost.conf
===================================================================
--- 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]
Comment 19 Matt McCutchen 2010-11-15 12:59:09 PST
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.
Comment 20 Michael Coates [:mcoates] (acct no longer active) 2010-11-15 13:04:20 PST
Bugzilla is fixed and returning a 403

Note You need to log in before you can comment on or make changes to this bug.