Re: [webappsec] POLL: Getting CSP 1.1 to LCWD

On Tue, Oct 1, 2013 at 2:01 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On 9/30/2013 5:39 PM, Glenn Adams wrote:
> > On Mon, Sep 30, 2013 at 5:23 PM, Brad Hill <hillbrad@gmail.com
> > <mailto:hillbrad@gmail.com>> wrote:
> >
> >     Glenn has declined to raise his
> >     suggestions on this list after several invitations to do so, but he
> >     gave a high-level set of proposals attached to this bug:
> >
> >     https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357
> >
> > I have laid out the problem in detail and proposed a number of possible
> > solutions in the text of that bug. Doing it again here would just be
> > repeating myself.
>
> Bugzilla is a terrible discussion forum, it is a bug tracking app. The
> bug can track what we decide to do about your objections but is not
> suited to back-and-forth about a topic, and especially doesn't handle
> branching conversations. It's designed for a straight-line problem =>
> (diagnosis => fix => test)* cycle.
>
> The call is also not a great place for a lengthy discussion because we
> often have a lot to cover and not everyone can make it, the earth being
> round and all. What we usually do is reference list discussions and have
> brief consensus-taking on whether the list discussion had reached a
> conclusion.
>
> If the objections are not discussed here on the list then you might as
> well not have even made them.
>

We seemed to have started a thread here. So let's see where it goes.


>
> At the moment Firefox actually does what you want, because the spec'd
> behavior will take work not because we agree with your objections. The
> problems the Firefox behavior raises:
>

Thanks for mentioning that, and raising the following points.


>
> * sites using reporting get overwhelmed with error reports that are not
> attacks due to attempted add-on injections. Twitter reported this was an
> unexpectedly large issue for them at one point.
>

Agreed. I had also thought of this, and that if add-on injections are
disabled, then error reports probably should be disabled.


>
> * sites using reporting can fingerprint users based on their unique
> combination of add-ons
>

Agreed. I had also thought of this, and this is another point in favor of
disabling error reports caused by disabled add-on injections.



>
> * user-desired mash-up functionality breaks. Sometimes the site in
> question really doesn't want their content modified but many times it's
> just collateral damage
>

Just like typical password managers now ask the end user whether to Always
Allow, Allow Once, or Don't Allow reuse of cached credentials, I envision
that a UA would want to provide a similar UI requesting the user to make a
decision about whether to accept or deny a request to disable third-party
injections. For example, an end user might explicitly authorize the UA to
ignore requests to disable injections. The user could be asked to authorize
this for all add-ons at once, or on a per-add-on basis.

In describing such a UI, I only intend to hint at possibilities, some level
of which could be documented in CSP itself.


>
> * due to the above users disable CSP globally making them less safe
> everywhere
>

I agree that this is a good argument against allow web pages to disable
add-ons without further end user input. However, I believe that a middle
ground is possible that enables disabling injections upon content author
request when the end user doesn't otherwise override this request. Such an
approach would better serve both the naive user and the content author.


>
> * due to the above some _add-ons_ disable CSP globally, making users
> less safe everywhere without them even knowing. This violates the
> policies for reviewed add-ons hosted on addons.mozilla.org but users can
> get add-ons elsewhere.
>

More flexible mechanisms and policies in this area, such as described
above, may decrease the likelihood of this scenario. I'd like to understand
a little better how add-ons disable CSP in this fashion: does it involve
script injection or some other API exposed to the add-on (e.g., the ability
to rewrite HTTP response headers or HTTP response entity).


>
> Your bug seems worried about addons being exploited but we really
> haven't seen any evidence of that (vulnerabilities, yes; exploits, no).
> I'm sure it's a viable vector for a targeted attack but the bad guys are
> mostly going after plugins (hit all the browsers) or the browsers
> themselves (only part of the market but still a large number of
> victims). Addons that have a small fraction of a fraction of the market
> are just not a target.
>

In my bug report, I cited two length studies [1][2].

[1] http://www.eecg.toronto.edu/~ashvin/publications/securing-web-browsers.pdf
[2] http://qspace.library.queensu.ca/bitstream/1974/7560/1/Barua_Anton_201209_MSc.pdf

The first of these [1] states (highlight added):

"Privilege escalation vulnerabilities are common in Firefox, and comprise
roughly a third of the critical vulnerability advisories. They arise from
unsafe extension behaviors or bugs in the Firefox security mechanisms that
regulate interactions between trusted native or extension scripts and
untrusted web page scripts. These vulnerabilities have appeared regularly
in every version of the browser and exist even in the latest versions. This
is despite continuing effort from a dedicated team of security developers
that have progressively improved the browser security model."

I can't comment on the age of this report or whether the same concerns
remain active, but it is sufficient to cause me to be concerned about this
as an attack vector.

In my commenting here, I am representing Cox, who, as a commercial video
service provider, is required to meet regulatory requirements about
presenting Emergency Alert Messages to end users while they are actively
using this service. Failure to do everything reasonably possible to present
an Emergency Alert could have liability consequences.

It seems reasonable on our reading of CSP that it do a better job of
reducing exposure to attacks from compromised add-on script injection,
which could have at least or more negative consequences for the user and/or
the author than the interests of the add-on creator, who, through accident
or intent, may have permitted or caused compromise.


>
> We have seen entirely malicious add-ons and they are a worry, but those
> are usually installed through other malware vectors and simply use the
> add-on hooks for convenience. If those didn't exist there are plenty of
> other ways to compromise executables.
>

Again, I'm attempting to find a better balance than that suggested by
current CSP specification text, which states "a CSP policy *should
not* interfere
with the operation of user-supplied scripts such as third-party user-agent
add-ons". I believe this is too open-ended and that reasonable technical
options exist to better protect both end user and content author.


>
> -Dan Veditz
>
>