UK Government's documentation on Firefox security

[Gervase Markham]

The UK government's National Technical Authority for Information
Assurance (CESG), which is part of GCHQ, publishes[0] documentation on
how to configure and secure each of the major browsers, and what
security shortcomings it considers them to have. The document (called
"End User Devices Platform Security Guidance") for Firefox is here:

https://www.gov.uk/government/publications/browser-security-guidance-mozilla-firefox/browser-security-guidance-mozilla-firefox

It was published at the end of November last year, so parts are out of
date, but it gives the following Significant Risks when using Firefox in
a government/enterprise context. Perhaps these are things we should
consider fixing, as they are likely to be issues for other governments
and enterprises as well, and some seem easy to add a pref for?


1) Mixed content blocking can be overridden on a per-page basis

-- Can we add a pref to disable this?

2) No support for certificate pinning

-- This was https://bugzilla.mozilla.org/show_bug.cgi?id=787133,
checked in before they published the document, but it hadn't
made it to production. So this one's done.

3) No sandboxing (for web content or plugins)

-- This is e10s

4) Can't disable addon installation, and addons can be silently evil

-- Can we add a pref to disable this?

5) Safe Browsing warnings are bypassable

-- Can we add a pref to disable this?

6) Can't disable Basic/Digest Auth over HTTP

-- UNCO bug about warning:
https://bugzilla.mozilla.org/show_bug.cgi?id=1185145
UNCO bug about turning off altogether:
https://bugzilla.mozilla.org/show_bug.cgi?id=966754

7) No notification if browser updates fail

8) No separation between Internet and Intranet pages

8b) no built-in XSS protection

8c) old and vulnerable plugins needed in an Intranet can be invoked by
Internet content

-- My understanding is that making this distinction accurately is Hard.
Is that true? What does IE do?

9) No security event logging


Gerv

[0] https://www.gov.uk/government/collections/browser-security-guidance

[Gijs Kruitbosch]

On 02/11/2015 15:50, Gervase Markham wrote:
> 4) Can't disable addon installation, and addons can be silently evil
>
> -- Can we add a pref to disable this?

There are already several prefs (in about:config) that could be used for
this.

I think it is unlikely that we would clutter up the
already-too-comprehensive about:preferences with UI-based prefs for
this, also because they would be footguns.

> 5) Safe Browsing warnings are bypassable
>
> -- Can we add a pref to disable this?

I don't really understand what the point of such a pref would be. Surely
then the user would first flip the pref and then bypass the safebrowsing
warning?

Generally I am a little surprised at the "users might do stupid things"
category of feedback here. I am generally skeptical that "make it a
pref" is a sensible solution for that problem. Users "stupidly" mess
with prefs they shouldn't be messing with *all the time*. Ironically,
the add-on one is a fine example of this (we now rely on the default
theme add-on being installed, and you can currently turn this off, which
will make your browser UI... less usable, shall we say).

> 6) Can't disable Basic/Digest Auth over HTTP
>
> -- UNCO bug about warning:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1185145

Note that we already warn about sending the credentials if not done
through the prompt.

> UNCO bug about turning off altogether:
> https://bugzilla.mozilla.org/show_bug.cgi?id=966754

It'd probably be worth speaking to Tanvi about this.

> 7) No notification if browser updates fail

You can turn on a pref for this on stable (app.update.badge). It's on by
default in Nightly and Developer Edition.

> 8) No separation between Internet and Intranet pages
>
> 8b) no built-in XSS protection
>
> 8c) old and vulnerable plugins needed in an Intranet can be invoked by
> Internet content

This is not true anymore? At least, not without considerable
jumping-through-hoops by the user, and soon NPAPI will be essentially
completely dead.

> -- My understanding is that making this distinction accurately is Hard.
> Is that true? What does IE do?

I'm assuming you are talking about XSS and Internet vs. Intranet? I
don't know what IE does, but if I had to guess, I'd assume that they
would treat domains that resolve to IP addresses that are in the
reserved ranges as "intranet" and everything else as "internet".

As for XSS, we do support CSP headers, which do help.

> 9) No security event logging

What is a "security event" ?

~ Gijs

[Gervase Markham]

On 02/11/15 16:10, Gijs Kruitbosch wrote:
> I don't really understand what the point of such a pref would be. Surely
> then the user would first flip the pref and then bypass the safebrowsing
> warning?

The document explains how you can lock preferences in an enterprise
scenario. I assume we still support that?

>> 6) Can't disable Basic/Digest Auth over HTTP
>>
>> -- UNCO bug about warning:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1185145
>
> Note that we already warn about sending the credentials if not done
> through the prompt.

We warn on every transmission of credentials over HTTP?

>> 9) No security event logging
>
> What is a "security event" ?

The document says:

"Firefox does not provide any built-in mechanism for logging events for
enterprise analysis. It is therefore not possible to determine whether
installations adhere to security policies, nor alert on security events
such as on-screen security warnings or browser crashes"

Gerv

[Gijs Kruitbosch]

On 03/11/2015 11:39, Gervase Markham wrote:
> On 02/11/15 16:10, Gijs Kruitbosch wrote:

>> I don't really understand what the point of such a pref would be. Surely
>> then the user would first flip the pref and then bypass the safebrowsing
>> warning?

> The document explains how you can lock preferences in an enterprise
> scenario. I assume we still support that?

Yes.

>>> 6) Can't disable Basic/Digest Auth over HTTP
>>>
>>> -- UNCO bug about warning:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1185145
>> Note that we already warn about sending the credentials if not done
>> through the prompt.

> We warn on every transmission of credentials over HTTP?

No, but if you put e.g. "http://foo:b...@mozilla.org/" in the URL bar,
you will get a warning that you're transmitting credentials to a site
that does not require any. I'm not 100% sure what the criteria are for
that prompt.

>>> 9) No security event logging
>> What is a "security event" ?

> The document says:
>
> "Firefox does not provide any built-in mechanism for logging events for
> enterprise analysis. It is therefore not possible to determine whether
> installations adhere to security policies,

This is a particularly vague way of describing what they want. Security
policy varies from organization to organization, as would the requisite
logging. It would seem hard if not impossible to strike the right
balance between not logging anything and logging too much detail... I'm
aware Windows logs things, and IME a lot of what it logs is not useful,
and when there is a problem for which such logs would be useful (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1089188 ) they are too
superficial to actually be useful.

IOW, I am not convinced it makes sense to add this as a feature, beyond
the obvious NSPR and NSS logging which we already have.

~ Gijs

[Gervase Markham]

On 03/11/15 11:50, Gijs Kruitbosch wrote:
> IOW, I am not convinced it makes sense to add this as a feature, beyond
> the obvious NSPR and NSS logging which we already have.

On this point (number 9), I agree. But I think some of the others are
worth doing.

Gerv

[Chris Hofmann]

on

8) No separation between Internet and Intranet pages

and

8c) old and vulnerable plugins needed in an Intranet can be invoked by
Internet content

These both seem to be writing of requirements based on Microsoft's security
zone feature.
That feature is typical MS marketing from the 90's where you have a set of
capabilities
that can be used to reduce security, and they marketed and FUD'ed there way
to convince
folks this was a 'security feature.'

The complexity of taking 22 features, and trying to implement and
administer each of those
across different behaviors in 4 differently defined 'security zones' has
led to more security
problems that it has solved. If there is evidence and research that the
security
zone feature in IE is widely, or effectively, used then we ought consider
it, but
I suspect its actually the reverse. In fact Firefox's first significant
bump in marketshare
in 2004 was due to a privilege elevation bug in the IE security zone
feature that led to
download of a remote plugin and execution of code without user
intervention or knowledge
that logged and forwarded keystrokes on banking sites back to the
attacker's server.

As Gijs mentioned we have ways to block plugins, and we should encourage
enterprises
to particpate in the blocking scheme if they know of vulnerable plugins.

-chofmann

On Tue, Nov 3, 2015 at 8:43 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 03/11/15 11:50, Gijs Kruitbosch wrote:

> > IOW, I am not convinced it makes sense to add this as a feature, beyond
> > the obvious NSPR and NSS logging which we already have.
>

> On this point (number 9), I agree. But I think some of the others are
> worth doing.
>
> Gerv
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

[Chris Hofmann]

It also looks like

8b) no built-in XSS protection

is https://bugzilla.mozilla.org/show_bug.cgi?id=528661

another possible case of some risk of a 'good security idea' that fails to
deliver
in implementation and administration.

If this is better supported by CSP then we might have met the 'built in'
checkbox,
or if the requirement is broadened to include possible addons then we meet
it via
no-script and several other addons that are more aggressive in their
blocking
at the possible cost of some usability.

-chofmann

On Tue, Nov 3, 2015 at 9:14 AM, Chris Hofmann <chof...@mozilla.com> wrote:

>
> on

> 8) No separation between Internet and Intranet pages
>

> and

>
> 8c) old and vulnerable plugins needed in an Intranet can be invoked by
> Internet content
>

>> > IOW, I am not convinced it makes sense to add this as a feature, beyond
>> > the obvious NSPR and NSS logging which we already have.
>>

[Francois Marier]

On 03/11/15 09:30 AM, Chris Hofmann wrote:
> It also looks like
>
> 8b) no built-in XSS protection
>
> is https://bugzilla.mozilla.org/show_bug.cgi?id=528661
>
> another possible case of some risk of a 'good security idea' that fails to
> deliver
> in implementation and administration.

The SecEng team has a blog post coming up soon about that particular
feature.

Francois

[Ben Bucksch]

Gervase Markham wrote on 02.11.2015 16:49:

> 7) No notification if browser updates fail

This is interesting. That means updates are vulnerable to a downgrade
attack. This should be fixed for everybody.

> 4) Can't disable addon installation, and addons can be silently evil
>
> -- Can we add a pref to disable this?

That would be xpinstall.enabled = false , I think

> 5) Safe Browsing warnings are bypassable
>
> -- Can we add a pref to disable this?

Why should Google be the final authority on what gov users in the UK can
see?

This could easily be implemented as extension. Same for some other
points in the list.
BTW: A number of enterprises already use extensions to customize Firefox
to their needs. Killing extensions would break all that.

> 6) Can't disable Basic/Digest Auth over HTTP
>
> -- UNCO bug about warning:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1185145
> UNCO bug about turning off altogether:
> https://bugzilla.mozilla.org/show_bug.cgi?id=966754

Ditto. There are legitimate uses for this.

> 8) No separation between Internet and Intranet pages
>
>

> -- My understanding is that making this distinction accurately is Hard.
> Is that true? What does IE do?

MSIE configures this in Internet settings. The admin manually configures
what constitutes "Intranet".

> 8c) old and vulnerable plugins needed in an Intranet can be invoked by
> Internet content

Here, they are contradicting themselves. If they don't trust their own
network enough to allow Basic Auth via HTTP even in the lowest security
case, then they can't trust their Intranet to run vulnerable (!) plugins
that would root all the client machines.

Apparently, they care about settings and theoretical features, but not
about fixing known-vulnerable software. Typical "features over security"
mindset. This request is a nice hint for government hackers in which
area they let their guard down. Sorry for the rant, but I've seen too
many government agencies see run Firefox 7 or so.

Ben

[Robert Strong]

On Wed, Nov 18, 2015 at 2:28 PM, Ben Bucksch <ben.buck...@beonex.com>
wrote:

> Gervase Markham wrote on 02.11.2015 16:49:
>

> 7) No notification if browser updates fail
>>
>

> This is interesting. That means updates are vulnerable to a downgrade
> attack. This should be fixed for everybody.
>

It would be interesting to know how they accomplished this. The one case I
can think of is when we wait up to 10 consecutive failures to contact the
update server before notifying the user.

Robert

>
> 4) Can't disable addon installation, and addons can be silently evil
>>
>> -- Can we add a pref to disable this?
>>
>

> That would be xpinstall.enabled = false , I think
>

> 5) Safe Browsing warnings are bypassable
>>
>> -- Can we add a pref to disable this?
>>
>

> Why should Google be the final authority on what gov users in the UK can
> see?
>
> This could easily be implemented as extension. Same for some other points
> in the list.
> BTW: A number of enterprises already use extensions to customize Firefox
> to their needs. Killing extensions would break all that.
>

> 6) Can't disable Basic/Digest Auth over HTTP
>>
>> -- UNCO bug about warning:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1185145
>> UNCO bug about turning off altogether:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=966754
>>
>

> Ditto. There are legitimate uses for this.
>

> 8) No separation between Internet and Intranet pages
>>
>>

>> -- My understanding is that making this distinction accurately is Hard.
>> Is that true? What does IE do?
>>
>

> MSIE configures this in Internet settings. The admin manually configures
> what constitutes "Intranet".
>

> 8c) old and vulnerable plugins needed in an Intranet can be invoked by
>> Internet content
>>
>

> Here, they are contradicting themselves. If they don't trust their own
> network enough to allow Basic Auth via HTTP even in the lowest security
> case, then they can't trust their Intranet to run vulnerable (!) plugins
> that would root all the client machines.
>
> Apparently, they care about settings and theoretical features, but not
> about fixing known-vulnerable software. Typical "features over security"
> mindset. This request is a nice hint for government hackers in which area
> they let their guard down. Sorry for the rant, but I've seen too many
> government agencies see run Firefox 7 or so.
>
> Ben
>

[Francois Marier]

On 02/11/15 07:50 AM, Gervase Markham wrote:
> 5) Safe Browsing warnings are bypassable
>
> -- Can we add a pref to disable this?

The following pref is now available in Nightly (bug #1226490):

browser.safebrowsing.allowOverride

Set it to false and the warnings cannot be ignored.

Francois

[Gervase Markham]

On 04/11/15 05:33, Francois Marier wrote:
> The SecEng team has a blog post coming up soon about that particular
> feature.

Did this happen yet? :-)

Gerv

[Gervase Markham]

On 02/11/15 15:50, Gervase Markham wrote:
> The UK government's National Technical Authority for Information
> Assurance (CESG), which is part of GCHQ, publishes[0] documentation on
> how to configure and secure each of the major browsers, and what
> security shortcomings it considers them to have. The document (called
> "End User Devices Platform Security Guidance") for Firefox is here:

I just sent a summary of this thread to the feedback email address for
this document. Thanks to everyone who participated :-)

Gerv