UK Government's documentation on Firefox security

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gijs Kruitbosch ("Hannibal")
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gervase Markham
In reply to this post by 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gijs Kruitbosch ("Hannibal")
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:bar@.../" 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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gervase Markham
In reply to this post by 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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Chris Hofmann-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Chris Hofmann-2
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 <[hidden email]> 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
>
> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>>
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Francois Marier
In reply to this post by Chris Hofmann-2
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gervase Markham
In reply to this post by Chris Hofmann-2
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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: UK Government's documentation on Firefox security

Gervase Markham
In reply to this post by 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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security