Closed Bug 1452037 (CVE-2019-11738) Opened 6 years ago Closed 5 years ago

script-src 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=' security policy will whitelist all javascript: URIs

Categories

(Core :: DOM: Security, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 69+ fixed
firefox61 --- wontfix
firefox68 --- wontfix
firefox69 + fixed
firefox70 + fixed

People

(Reporter: jwkbugzilla, Assigned: sstreich)

References

Details

(Keywords: sec-low, Whiteboard: [domsecurity-active][post-critsmash-triage][adv-main69+][adv-esr68.1+])

Attachments

(2 files)

Attached file Proof of concept page
Note: This is likely related to bug 1314567 which I cannot access.

As implemented right now, execution of any javascript: URIs can be allowed using a hash-based source that takes the empty string as input. For example, script-src 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=' is supposed to allow empty <script> tags only but will enable arbitrary javascript: URIs as well. So specifying a source like this weakens CSP protection considerably which is not obvious.

You can reproduce by opening the attached proof of concept page and clicking the link. In Chrome 65 this doesn't do anything, the javascript: URI is blocked by CSP. In Firefox 59.0.2 and Firefox 61.0a1 (2018-04-04) nightly on the other hand the code executes and shows a message saying "clicked."

IMHO the issue is the code here:

> https://dxr.mozilla.org/mozilla-central/rev/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/dom/security/nsCSPContext.cpp#582

If aElementOrContent is neither a string nor an element (nullptr in this case) this code will leave content variable uninitialized (empty) but perform matching hash sources nevertheless.

I can see two ways how this can have a security impact:

1) A website might specify this script source assuming that it is innocuous (an empty script cannot do any harm). Not sure whether any real-world websites actually do this.

2) WebExtensions aren't allowed to specify unsafe-inline in their CSP for security reasons, meaning in particular that they aren't allowed to use javascript: URIs. This issue allows weakening the CSP protection nevertheless.
Flags: sec-bounty?
I'm not that concerned about the first scenario, but bypassing the WebExtensions CSP is bad :)
CCing ckerschbaumer for this CSP bypass.
Component: DOM → DOM: Security
Assignee: nobody → ckerschb
Keywords: sec-low
Priority: -- → P2
Whiteboard: [domsecurity-active]
Status: NEW → ASSIGNED
Group: core-security → dom-core-security
Flags: sec-bounty? → sec-bounty-
Assignee: ckerschb → streich.mobile
Keywords: checkin-needed
Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Please nominate this for Beta & ESR68 approval when you get a chance.

Flags: needinfo?(streich.mobile)
Flags: in-testsuite+

Comment on attachment 9072981 [details]
Bug 1452037 - Fix Whitelisting of javascript-uris with csp hash r=ckerschb

Beta/Release Uplift Approval Request

  • User impact if declined: The user is vulnerable to a csp-bypass, if the page owner did
    set "script-src <someHash>"
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is adding one new codepath in the csp-hash validation:
  • if no script is given to calculate a hash on, we're blocking the script.
    This is only the case for javascript uris.
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: If a page has set "script-src 'sha256-<someHash>' firefox currently allows
    a script if it fails to get a sample to calculate its hash.
    This allows any uri with "javascript:<code>" and and opens up a vector to bypass csp.
  • User impact if declined: The user is vulnerable to a csp-bypass.
  • Fix Landed on Version: Nightly 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is adding one new codepath in the csp-hash validation:
  • if no script is given to calculate a hash on, we're blocking the script.
    This is only the case for javascript uris.
  • String or UUID changes made by this patch:
Flags: needinfo?(streich.mobile)
Attachment #9072981 - Flags: approval-mozilla-esr68?
Attachment #9072981 - Flags: approval-mozilla-beta?

Comment on attachment 9072981 [details]
Bug 1452037 - Fix Whitelisting of javascript-uris with csp hash r=ckerschb

Low-risk csp bypass fix with automated tests. Approved for 69.0b6 and 68.1esr.

Attachment #9072981 - Flags: approval-mozilla-esr68?
Attachment #9072981 - Flags: approval-mozilla-esr68+
Attachment #9072981 - Flags: approval-mozilla-beta?
Attachment #9072981 - Flags: approval-mozilla-beta+
Flags: qe-verify-
Whiteboard: [domsecurity-active] → [domsecurity-active][post-critsmash-triage]
Alias: CVE-2019-11738
Whiteboard: [domsecurity-active][post-critsmash-triage] → [domsecurity-active][post-critsmash-triage][adv-main68+][adv-esr68.1+]
Whiteboard: [domsecurity-active][post-critsmash-triage][adv-main68+][adv-esr68.1+] → [domsecurity-active][post-critsmash-triage][adv-main69+][adv-esr68.1+]
Flags: sec-bounty-hof+
Group: core-security-release
Regressions: 1544705
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: