Closed Bug 739099 Opened 12 years ago Closed 11 years ago

HTTPS Everywhere allows spoofing attacks

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: theo, Unassigned)

References

(
URL
)

Details

When HTTPS-Everywhere add-on is enabled, the proof of concept (http://majorsecurity.net/html5/ios51-demo.html) works: "www.apple.com" appears in the address bar, whereas the site is hosted on majorsecurity.net.
It can't be reproduced without HTTPS-Everywhere.
Bug filled in the HTTPS-Everywhere bug tracker :
https://trac.torproject.org/projects/tor/ticket/5477
Maybe until this is fixed it should be blocklisted? It could easily fool a user into thinking it's a real site - It did the first time when I looked at the testcase, and I knew that it was fake.
I'd love to see this blocklisted too. Could someone related to Add-ons security do it, please?
Filed Bug 739133. I wasn't sure if this should be the blocklisting bug, or if this is not only a flaw in HTTPS Everywhere, but a flaw in both, but only aided with HTTPSE.
Please do not blocklist HTTPS Everywhere.  I apologise for the fact that our developers didn't reply in https://trac.torproject.org/projects/tor/ticket/5477 sooner (I was on vacation!), but we aren't yet convinced that this bug is exploitable.

My current tentative understanding of it is as follows:

Without HTTPS Everywhere, a new window with a document like http://www.apple.com always has the apple origin.

With HTTP Everywhere, a new window with that document never loads anything from http://www.apple.com, and therefore remains writable by the page that created it for a brief period of time, until some content is loaded from https://www.apple.com, at which point Apple's origin takes over.
What is the status of this? It's been six months.
(In reply to Brian Smith (:bsmith) from comment #6)
> What is the status of this? It's been six months.

I think Mike Perry (from EFF), as explained here https://trac.torproject.org/projects/tor/ticket/5477, needs to add a patch to Firefox to fix this issue.
I marked his bug blocking this one.
I'm not sure, so someone should check this.
Depends on: 765934
Is it really acceptable to allow this to go on for this long? I am all for eventually fixing the bugs that HTTPS Everywhere depends on to do everything it wants to do correctly, but until then either HTTPS Everywhere needs to fix things itself or it needs to be blocklisted. See also bug 821973.
Component: Security → Blocklisting
Product: Firefox → addons.mozilla.org
Peter, we need you to take immediate action in order to avoid having your add-on blocklisted. Even if this depends on a fix on our side, you need to workaround or disable whatever mechanism is exposing this security hole.
(In reply to Brian Smith (:bsmith) from comment #8)
> Is it really acceptable to allow this to go on for this long? I am all for
> eventually fixing the bugs that HTTPS Everywhere depends on to do everything
> it wants to do correctly, but until then either HTTPS Everywhere needs to
> fix things itself or it needs to be blocklisted. See also bug 821973.

Blocklisting HTTPS Everywhere will cause Firefox users to experience vastly more security vulnerabilities than not blocklisting it.  I advise you against it in the strongest possible terms.

Meanwhile Jorge, are you familiar with the history of bug #765934?  We wrote the patch to fix this bug, but sat around for months (!!!) waiting for a review.  In the mean time, other changes to m-c broke it.  Help untangling all of that is urgently needed.
I'm going to venture to say that allowing users to experience a spoof attack is worse than not having encryption enabled on their websites (most important websites have HTTPS anyway).
(In reply to Peter Eckersley from comment #10)
> Blocklisting HTTPS Everywhere will cause Firefox users to experience vastly
> more security vulnerabilities than not blocklisting it.  I advise you
> against it in the strongest possible terms.

Given that we're okay with the current state of Firefox security (not that there aren't improvements to be made), your add-on is in our perspective causing more harm that good. If we block it, it will be softblocked, meaning that users will have the choice to enable it if they agree with you in terms of cost / benefit.

> Meanwhile Jorge, are you familiar with the history of bug #765934?  We wrote
> the patch to fix this bug, but sat around for months (!!!) waiting for a
> review.  In the mean time, other changes to m-c broke it.  Help untangling
> all of that is urgently needed.

Getting traction for some bugs can be difficult, yes. It's just the way our development process works. I'm sure all the new activity on this bug will bring some additional attention to bug 765934.
(In reply to Tyler Downer [:Tyler] from comment #11)
> I'm going to venture to say that allowing users to experience a spoof attack
> is worse than not having encryption enabled on their websites (most
> important websites have HTTPS anyway).

Well:

1. The spoof attack is a theoretical proof of concept.  We have not seen a demonstration that would actually create a stable spoofed UI.
2. Thousands of sites "have HTTPS anyway" but have not deployed it correctly.  For instance, they fail to flag their authentication cookies as secure or use HSTS (See #642675).  Disabling HTTPS Everywhere will render thousands of these sites vulnerable to Firesheep-style attacks.
By the way, NoScript also shares our redirect machinery. It is almost certainly vulnerable to the same "issue" (which Giorgio did mitigate to get the PoC exploit down to a temporary URL bar flicker - a change we also adopted as Peter indicated in point 1 of comment #13).

But since you're obviously very genuinely concerned with maximum "security" for your users, you probably want to blacklist both extensions...

Or you know, just help us figure out why your recent m-c observer overhaul broke the unit tests we wrote for you along with our patch 4 months ago for the Firefox 17-ESR deadline.

Hope you're having a good Mayan Apocalypse over there! Sure seems like it...
I just tested the PoC with NoScript installed, and the behavior is exactly the same as if it weren't installed.

With HTTPS Everywhere installed, I do see the PoC briefly working before redirecting to apple.com. So, the behavior of both add-ons is certainly different.

Maybe Giorgio can comment on what's different and whether it makes a difference in terms of security.
(In reply to Jorge Villalobos [:jorgev] from comment #15)
> I just tested the PoC with NoScript installed, and the behavior is exactly
> the same as if it weren't installed.
> 
> With HTTPS Everywhere installed, I do see the PoC briefly working before
> redirecting to apple.com. So, the behavior of both add-ons is certainly
> different.
> 
> Maybe Giorgio can comment on what's different and whether it makes a
> difference in terms of security.

With NoScript, one would expect to see the PoC work only if the victim site had set HSTS that NoScript was enforcing.  NoScript -> Options -> Advanced -> HTTPS might let your force that; I haven't tried it though.
(In reply to Peter Eckersley from comment #16)

> With NoScript, one would expect to see the PoC work only if the victim site
> had set HSTS that NoScript was enforcing.  NoScript -> Options -> Advanced
> -> HTTPS might let your force that; I haven't tried it though.

I've just tried, with scripts globally allowed and www.apple.com forced to HTTPS, both with latest stable (NoScript 2.6.4.1) and latest beta (2.6.4.2rc4) on Firefox 17.0.1, and didn't manage to reproduce.
Also tried forcing the whole .apple.com (i.e. apple.com + subdomains), but neither this allowed me to reproduce.

Am I missing anything?

That said, telling what differs between NoScript and HTTPS Everywhere is really difficult (too many moving parts in NoScript), but I recall Mike & Peter removed some little ABE dependencies when they merged my channel replacement machinery, so maybe the culprit is one of these subtractions.
Peter, Mike: has there been any progress here?
Yes, we've tried a whole bunch of things.  Simple work-arounds in script are seeming unlikely [*], but I believe Mike has some strong hypotheses about why m-c changes (probably related to bug #800799 / bug #797684 / bug #769764) broke our patches for bug #765934.  

But work on this has been hampered by the holidays and holiday travel.  We will finally be in the same physical place and able to make more rapid progress on this next week.  

[*] Merging more ABE stuff from NoScript doesn't count as simple ;)
(In reply to Mike Perry from comment #14)
> Or you know, just help us figure out why your recent m-c observer overhaul
> broke the unit tests we wrote for you along with our patch 4 months ago for
> the Firefox 17-ESR deadline.

...

(In reply to Peter Eckersley from comment #19)
> Yes, we've tried a whole bunch of things.  Simple work-arounds in script are
> seeming unlikely [*], but I believe Mike has some strong hypotheses about
> why m-c changes (probably related to bug #800799 / bug #797684 / bug
> #769764) broke our patches for bug #765934.  

In the meantime, let's get the devs from those bugs in here to see if they can offer any easy insight?

(And, if I may be so bold, let's play like we're on the same team here. We can't have addons compromising our base security posture, I think you guys know that. But we also really like addons like noscript and httpse that give our users extra choice, and I'm sorry we made your life more complicated. I hope we can sort it out and not have to block anything, but Brian's right that we've already sat on this for a very long time.)
Mike and I have an all-day hack session scheduled on Monday to work on this.  If any experience necko people would like to join us in person in SF, or via video or IRC, they're most welcome to.  Likely hours are 11am-7pm US Pacific time.
I don't expect bug 765934 to be resolved as soon as we need this bug to be fixed because the developers that are needed for fixing bug 765934 are on the critical path for B2G or other higher-priority things. Also, as I commented in bug 765934, doing the thing that bug 765934 suggests is questionable as far as risk/reward goes; IMO, we should not be adding any new cases of internal redirects if we can avoid them, because it leads to the possibility of code that doesn't expect to be redirected breaking. (The core Firefox Sync code is/was one example.)
No longer depends on: 765934
(In reply to Brian Smith (:bsmith) from comment #22)
> IMO, we should not be adding any
> new cases of internal redirects if we can avoid them, because it leads to
> the possibility of code that doesn't expect to be redirected breaking. (The
> core Firefox Sync code is/was one example.)

The internal redirects are already being performed by extensions, but by using a janky set of incoherent APIs rather than a simple planned one.  Why do you think that the former is less likely to break things than the latter?
I think it's likely that we'll have a fix for bug 765934 soon (at least for the non-e10s case, and that's fine for now).  It's complicated enough that we won't want to backport it further than aurora (if at all), so I don't know what our story should be for blocklisting or not for code that's older than m-c.
1.5 months more have passed and what's the result?
btw, the demo page is now gone, so I can't test if the vulnerability still works with HTTPS Everywhere or was fixed (and if it was - what version of Fx will get the patches).
A fix for bug 765934 has landed in Firefox 20.  Sorry the test page is offline, I will try to find an alternative home for it when I'm back from vacation next week.  We have also tested to confirm that the API in FF 20 fixes this bug (it does).
Sorry, took me a while to reorganise some servers, but there the test is online here:

http://reworld.org/old/bugs/5477-tst.html

For me the bug is gone now that Firefox 20 has been released, and IMO we can close this ticket.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.