545335 - ensure we have pinned HSTS entries for sites that are whitelisted for personas installation (addons.mozilla.org)

Status: RESOLVED WONTFIX

(addons.mozilla.org :: Security, defect)

Description

[Matt McCutchen]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100122 Fedora/3.6.1-1.fc13 Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a2pre) Gecko/20100209 Minefield/3.7a2pre

Firefox lets any site with install permission (listed in Preferences -> Security -> Warn me when sites try to install add-ons: Exceptions) preview personas automatically without user consent.  By default, this list includes getpersonas.com and addons.mozilla.org, regardless of SSL.  That means a network attacker can change my browser chrome arbitrarily by redirecting me to a spoofed http://getpersonas.com or http://addons.mozilla.org : not good.

I suggest restricting the automatic persona preview feature to SSL sites and correspondingly changing getpersonas.com to use SSL.

Reproducible: Always

Steps to Reproduce:
The automatic persona preview feature can be seen at http://getpersonas.com .  I don't care to write out steps for an actual attack.



A workaround for security-conscious users is to use NoScript to force HTTPS on all sites with install permission.

Comment 1

[Jesse Ruderman]

More specifically, the *default whitelist* should only consist of https sites.  I'm fine with letting users whitelist other sites; I don't think many users will.

Comment 2

[Ryan Doherty (:rdoherty)]

Looping in mrz, if we do this getpersonas.com's CDN will have to serve everything over SSL.

Comment 3

[matthew zeier [:mrz]]

Cost prohibitive to do SSL with the CDN. 

Can you, in code, punt SSL views to a different hostname and non-SSL views to CDN?

Comment 4

[Jesse Ruderman]

There won't be any non-SSL views if we fix this correctly.

Comment 5

[Johnathan Nightingale [:johnath]]

(In reply to comment #3)
> Cost prohibitive to do SSL with the CDN. 
> 
> Can you, in code, punt SSL views to a different hostname and non-SSL views to
> CDN?

I think this attack is relatively low-impact - nuisance personas previews/installs in MitM scenarios - but even if we decide that it needs to be fixed, I think the image content on the CDN could be http. The concern here is about a site masquerading as getpersonas/amo and using that as a launch point - if you go to the real getpersonas, and install a persona, but the images delivered are MitM'd to be something you don't want - click the undo button.

Does that change your calculus at all, mrz? I'm not pushing hard for SSL here, like I say, I think it's a real, but relatively low-impact attack, but if "SSL for getpersonas web content, straight http for CDN-backed image storage" is a lot easier to manage than "SSL everywhere" then it might be a useful middle ground?

Comment 6

[Reed Loden [:reed]]

imho, getpersonas.com should really just be treated like addons.mozilla.org -- full SSL for everything

Comment 7

[Johnathan Nightingale [:johnath]]

(In reply to comment #6)
> imho, getpersonas.com should really just be treated like addons.mozilla.org --
> full SSL for everything

Well, I mean, if we're just writing cheques, so would I. And I do think we should expect to get there eventually, as we have with AMO.

But my suggestion is aimed at solving the proximate issue here. If the getpersonas pages are served over https, and if we only whitelist the https sites, then a MitM attack needs a user to be trying on personas to succeed (by subverting the http calls to the CDN). That's still an attack, and we should look for ways to mitigate it, no doubt.

But right now, with http trusted, a MitM doesn't need to wait - they can 302 your next pageload to any http site over to a fake getpersonas with content that immediately triggers an install of their choosing. That's a bigger hole, and one that I think we should plug soon - sooner perhaps than we can sort out SSL protection of the entire CDN.

Do you disagree, there?

Comment 8

[Ryan Doherty (:rdoherty)]

Few comments:

* getpersonas.com will be moved over to AMO completely, most likely next quarter
* I'm against using SSL mainly for performance reasons (all our static content is currently served via our CDN, which makes getpersonas.com really fast)
* But I do agree that serving getpersonas.com over SSL is the right thing to do

There are a bunch of various bugs about ssl/non-ssl functionality for getpersonas.com open. My opinion is to create a new bug for requiring SSL for all of getpersonas.com and duping the rest.

Comment 10

[timeless]

rhoderty: status update? afaict you commented in Feb, it's now mid Aug, Q2 came and went.

Comment 11

[Ryan Doherty (:rdoherty)]

(In reply to comment #10)
> rhoderty: status update? afaict you commented in Feb, it's now mid Aug, Q2 came
> and went.

getpersonas.com supports ssl, requiring it client side is a Firefox configuration change. wfm to change the whitelist entry, once that happens we can flip to ssl required on the website side.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

A better approach to fixing this is probably just to ensure that we have static HSTS pinned entries for any persona-installing site we have whitelisted.

David/Brian, is there a bug tracking this for Mozilla properties? I don't see anything Mozilla-related in nsSTSPreloadList.inc.

Comment 13

[Reed Loden [:reed]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #12)
> A better approach to fixing this is probably just to ensure that we have
> static HSTS pinned entries for any persona-installing site we have
> whitelisted.
> 
> David/Brian, is there a bug tracking this for Mozilla properties? I don't
> see anything Mozilla-related in nsSTSPreloadList.inc.

getpersonas.com doesn't send any security-related HTTP headers at all, and AMO sends HSTS with max-age of 2592000, which is way under the minimum required (18 weeks) to be listed in the preload list. Fix those problems first. :)

Comment 14

[:Cykesiopka]

getpersonas.com was removed from the xpinstall whitelist in Bug 861101 (and it redirects to AMO now anyways).

AMO isn't statically pinned yet, but it now sends a HSTS header with a max-age of 31536000 (1 year).

Comment 15

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Presumably there's a reason we haven't preloaded AMO, but to confirm that I'm passing this over there to see if this is a WONTFIX.