- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Tue, 01 Oct 2013 14:51:59 -0700
- To: Glenn Adams <glenn@skynav.com>
- CC: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <524B43FF.2020104@mozilla.com>
On 10/1/2013 1:46 PM, Glenn Adams wrote:
> "Privilege escalation vulnerabilities are common in Firefox, and
> comprise roughly a third of the critical vulnerability advisories. [...]"
>
> 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.
That seems to be a concern about Firefox, not add-ons.
> 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.
The internet in general and the World Wide Web in particular are not a
video service. How does this requirement apply in any way?
> 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,
I'd worry far more about malicious addons than compromised ones. The
former is a reality, but CSP isn't going to help that problem.
> 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.
My eventual plan for Firefox is to let an add-on specify a CSP
whitelist. This lets the add-ons do what the user presumably want them
to do but by default means add-ons will respect CSP. The explicit steps
to override CSP can then be reviewed and won't accidentally introduce
issues. Although perhaps not as wide open as the spec implies I think
that fits with the spirit of the spec ("should not", not "must not").
-Dan Veditz
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 1 October 2013 21:52:33 UTC