Closed Bug 796475 (CVE-2013-0776) Opened 12 years ago Closed 12 years ago

HTTPS can be effectively disabled by attackers on rogue networks using a proxy that returns 407 with embedded script

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
15 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
firefox17 --- wontfix
firefox18 - wontfix
firefox19 + fixed
firefox20 + fixed
firefox21 --- fixed
firefox-esr10 --- wontfix
firefox-esr17 19+ fixed
b2g18 19+ fixed
b2g18-v1.0.0 --- fixed

People

(Reporter: lcamtuf, Assigned: mcmanus)

References

(
URL
)

Details

(Keywords: csectype-priv-escalation, reporter-external, sec-high, Whiteboard: [qa-][adv-main19+][adv-esr1703+])

Attachments

(1 file)

patch 0
12.41 KB, patch
jduell.mcbugs
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
akeybl
: approval-mozilla-esr10-
akeybl
: approval-mozilla-esr17+
lmandel
: approval-mozilla-b2g18+
abillings
: sec-approval+
Details | Diff | Splinter Review
There appears to be a relatively nasty bug in your handling of HTTPS. To reproduce, set up a TCP server on, say, localhost:1234, and have it read the HTTP request and respond with: -- snip! -- HTTP/1.0 407 Burp Proxy-Authenticate: basic Connection: close Content-Type: text/html <html> <h1>pwnd</h1> <script>alert(location.href)</script> [...some padding...] -- snip! -- Then, configure localhost:1234 as a proxy for HTTP and HTTPS (on a rogue network, this could be done through auto-discovery). Next, have the victim navigate to https://www.paypal.com/. A prompt will come up, but doing the most reasonable thing (dismissing it or hitting ESC) will display the HTML content returned by the proxy over plain text, executing it in the context of https://www.paypal.com/.
Calling this "docshell" for now, although it be actually a network-layer issue.
Component: Security → Document Navigation
Product: Firefox → Core
I thought this was a known issue with 407 responses from a proxy. And that in fact there were lots of proxies that _depend_ on this behavior... Over to networking, where I know people have looked into this in the past.
Component: Document Navigation → Networking: HTTP
Summary: HTTPS can be effectively disabled by attackers on rogue networks → HTTPS can be effectively disabled by attackers on rogue networks using a proxy that returns 407 with embedded script
The problem here is mostly that Firefox actually renders the error page as if coming from the target server. This is specific to Firefox. Most browsers display a password prompt if they hit 407, which is probably required for some proxies to work and is still somewhat bad phishing-wise, but at least it doesn't compromise the HTTPS origin.
Ah, I see. That's odd, I agree. Patrick, Jason, did that come up before?
So the previous discussion was in bug 599295 and bug 491818 and bug 479880. Patrick, is there a reason we can't reset the channel principal to a null principal in this situation (failed SSL connect with 407)?
(In reply to Boris Zbarsky (:bz) from comment #6) > So the previous discussion was in bug 599295 and bug 491818 and bug 479880. > > Patrick, is there a reason we can't reset the channel principal to a null > principal in this situation (failed SSL connect with 407)? that's my inclination. I haven't done the due diligence on it.
FYI, most other browsers don't display the server-supplied error page at all: if auth fails, they just show something like about:neterror. Perhaps that's an even simpler fix.
That's a much harder fix in terms of actual code changes, actually. The question is what the goal is. The testcase in this bug would still alert the server location and the url bar would show the server location, with the null principal thing. But the site would not run with that server's permissions (e.g. would not be able to do XHR to that server). It might still be a serious spoof risk. :(
we could probably easily suppress the OnDataAvailable calls for the 407 body.. but I do worry there are cases where that information is important for actually authorizing to the proxy.
Possibly, although 30x redirects, 5xx codes, 4xx, etc, already don't work in Firefox if returned by the proxy for CONNECT requests, and it's already breaking some stuff (bug 491818). Displaying the proxy-supplied HTML if the address bar still displays https://www.paypal.com/ is probably a very bad choice either way. You could maybe replace the URL with moz-proxy://.../, but then the behavior of "reload" may be a bit confusing.
I do not think we should show the proxy's error page at all. If we do show it, then the proxy will be able to spoof any HTTPS website. We cannot rely on the user noticing the lack of a security indicator. (As Limit always said, people tend to never notice that an indicator is missing.) So, IMO, we must create an about: page for this case, regardless. Also, should we be returning the proxy's response to XHR? I vote that we do not.
Returning it via XHR would probably mean potential script injection in half of the HTTPS-enabled "web 2.0" stuff (certainly GMail, Facebook, etc).
>> most other browsers don't display the server-supplied error page at all: if >> auth fails, they just show something like about:neterror. > > That's a much harder fix in terms of actual code changes, actually. Returning a boilerplate error page instead of renderin the HTML reply is what we did for failed 30x replies. Why is that harder for failed 407s? I agree with Brian that we probably shouldn't be rendering the reply. > I do worry there are cases where that information is important for > actually authorizing to the proxy. That was also a concern when we stopped rendering proxy responses for 30x responses. It sucked not to be more proxy-friendly, but in the end it was non-trival to render the HTML safely.
(In reply to Jason Duell (:jduell) from comment #14) > That was also a concern when we stopped rendering proxy responses for 30x > responses. It sucked not to be more proxy-friendly, but in the end it was > non-trival to render the HTML safely. so be it!
> Why is that harder for failed 407s? It's not harder than it is for 30x, modulo compat issues. It's harder than stamping a nullprincipal as the owner, which is literally a single line of code. ;)
Yello, Just a gentle ping at a two-month mark :-)
Patrick - can you take this one?
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
gecko actually tries to do the right thing here (showing the proxy connection error page) - it is specifically the path dealing with the cancellation of the auth box that has the bug. If you just fail to authenticate (provide bad credentials a few times) you don't see the message body provided by the server and instead get the error page.. so fixing the cancel bug isn't going to break any new ground in terms of a vector people were relying on to provide instructions, etc..
Attached patch patch 0 — — Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=f2fc44897a57 Displays an existing error page when proxy auth dialog is canceled.
Attachment #694454 - Flags: review?(jduell.mcbugs)
Comment on attachment 694454 [details] [diff] [review] patch 0 Review of attachment 694454 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me. Nice to have test coverage :) ::: netwerk/protocol/http/nsHttpChannel.cpp @@ +4156,5 @@ > { > LOG(("nsHttpChannel::OnAuthCancelled [this=%p]", this)); > > if (mTransactionPump) { > + nit: splinter seems to show extra whitespace on blank line @@ +4166,5 @@ > + // because we do want to show the content if this is an error from > + // the origin server. > + if (mProxyAuthPending) > + Cancel(NS_ERROR_PROXY_CONNECTION_REFUSED); > + ditto
Attachment #694454 - Flags: review?(jduell.mcbugs) → review+
Comment on attachment 694454 [details] [diff] [review] patch 0 [Security approval request comment] How easily could an exploit be constructed based on the patch? The patch indicates the problem clearly - but exploiting the bug requires an active mitm attacker. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? probably Which older supported branches are affected by this flaw? this bug has always existed in firefox If not all supported branches, which bug introduced the flaw? na Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? no. fairly easy to make with low risk. How likely is this patch to cause regressions; how much testing does it need? pretty average level for a bugfix.
Attachment #694454 - Flags: sec-approval?
I'd like to sec-approve this but I want to know what the branch story is from Release Management first.
(In reply to Al Billings [:abillings] from comment #23) > I'd like to sec-approve this but I want to know what the branch story is > from Release Management first. Al, considering we have gone to build with all our beta's , this will be going wontfix for Fx18.We could target timely landings for future versions .
(In reply to bhavana bajaj [:bajaj] from comment #24) > (In reply to Al Billings [:abillings] from comment #23) > > I'd like to sec-approve this but I want to know what the branch story is > > from Release Management first. > > Al, considering we have gone to build with all our beta's , this will be > going wontfix for Fx18.We could target timely landings for future versions . When do we want to get this in then? Second week of new cycle?
(In reply to Al Billings [:abillings] from comment #25) > (In reply to bhavana bajaj [:bajaj] from comment #24) > > (In reply to Al Billings [:abillings] from comment #23) > > > I'd like to sec-approve this but I want to know what the branch story is > > > from Release Management first. > > > > Al, considering we have gone to build with all our beta's , this will be > > going wontfix for Fx18.We could target timely landings for future versions . > > When do we want to get this in then? Second week of new cycle? Makes sense to me, as far as risk of regression versus security visibility risk. Let's land in the next couple of weeks, and definitely before Beta 3 goes to build on 1/22.
Attachment #694454 - Flags: sec-approval? → sec-approval+
https://hg.mozilla.org/mozilla-central/rev/2e17ce2c711c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
status-firefox21: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Comment on attachment 694454 [details] [diff] [review] patch 0 [Approval Request Comment] Bug caused by (feature/regressing bug #): original sin User impact if declined: theoretical MITM spoof of HTTPS by active attacker against only users using HTTP proxies who hit "cancel" on the auth popup Testing completed (on m-c, etc.): on m-c Risk to taking this patch (and alternatives if risky): other than my hand testing we have very little exposure to the use patters of corporate proxy users. String or UUID changes made by this patch: none Personally, I wouldn't backport this and instead take normal channel testing.. it has existed forever, requires an esoteric exploit path (the user has to cancel the popup, they can't simply provide bad credentials), and doesn't have any cited exploits. The change is relatively simple, but its not in an area we have extensive tests with (manual or automated). those who nominated/approved it for tracking might feel differently.
Attachment #694454 - Flags: approval-mozilla-beta?
Attachment #694454 - Flags: approval-mozilla-aurora?
(there is automated testing of this change included in the patch.. I realize my comment 29 might have been confusing on that point.)
Comment on attachment 694454 [details] [diff] [review] patch 0 I think this should be approved and landed for -aurora and -beta, as the patch itself is very instructive for how to exploit this flaw. Also, if I am understanding the first few comments correctly, this flaw allows the proxy to render content and execute code with the principal of the victim. That is extremely bad, and this is why I am also nominating for ESR and B2G.
Attachment #694454 - Flags: approval-mozilla-esr17?
Attachment #694454 - Flags: approval-mozilla-esr10?
Attachment #694454 - Flags: approval-mozilla-b2g18?
Yeah, that's the impact. The mitigating factor is that the user needs to dismiss an auth dialog first. The mitigating factor to the mitigating factor is that dismissing the modal dialog is the only way to continue using or even close the browser, IIRC.
(In reply to Michal Zalewski from comment #32) > Yeah, that's the impact. The mitigating factor is that the user needs to > dismiss an auth dialog first. The mitigating factor to the mitigating factor > is that dismissing the modal dialog is the only way to continue using or > even close the browser, IIRC. if you simply say ok to the dialog (maybe twice) the contents of the 407 are not rendered in 18. Its specifically only if you say cancel.
Flags: sec-bounty+
(In reply to Patrick McManus [:mcmanus] from comment #33) > if you simply say ok to the dialog (maybe twice) the contents of the 407 are > not rendered in 18. Its specifically only if you say cancel. Understood. But, it's too subtle. Especially, if the user isn't even expecting to enter a username/password, then they're going to click cancel. And, more generally, "Cancel" should always be a safe action to take in any security prompt.
I agree that confused users are likely to cancel (or hit Escape which amounts to the same thing). Cancel on this dialog is -meant- to be a safe action, it's just that it isn't due to this bug. But because it's usually safe we should expect a number of users to do that as their first reaction.
Comment on attachment 694454 [details] [diff] [review] patch 0 Approving for all branches except B2G, as that branch is still in flux. We'll ping when ready to uplift there as well.
Attachment #694454 - Flags: approval-mozilla-esr17?
Attachment #694454 - Flags: approval-mozilla-esr17+
Attachment #694454 - Flags: approval-mozilla-esr10?
Attachment #694454 - Flags: approval-mozilla-esr10-
Attachment #694454 - Flags: approval-mozilla-beta?
Attachment #694454 - Flags: approval-mozilla-beta+
Attachment #694454 - Flags: approval-mozilla-aurora?
Attachment #694454 - Flags: approval-mozilla-aurora+
I don't know what tracking-b2g18: "19+" means exactly. Because this allows a MitM to effectively MitM even an HTTPS site, it is really important to land into B2G 1.0 if at all possible.
blocking-b2g: --- → tef?
Agree, a bug of this severity is worth taking even this late in the cycle.
blocking-b2g: tef? → tef+
Attachment #694454 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
Landed on mozilla-b2g18 prior to the 1/25 branching to mozilla-b2g18_v1_0_0, updating status-b2g-v1.0.0
status-b2g18-v1.0.0: --- → fixed
Marking as qa- per comment 30. Please only remove the tag if you want any specific manual testing done around this fix.
Whiteboard: [qa-]
Whiteboard: [qa-] → [qa-][adv-main19]
Whiteboard: [qa-][adv-main19] → [qa-][adv-main19+][adv-esr1703+]
Alias: CVE-2013-0776
Michal, would you mind testing to see if this is fixed on your end? It should now be fixed in Firefox 19 Beta, 20 Aurora, 21 Nightly, and 17.0.3esr.
Here is the Microsoft Research paper from 2009 that talks about these kinds of attacks: http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf and here is the Hacker News story: http://news.ycombinator.com/item?id=5253136
Depends on: 904590
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: