Closed Bug 1644790 (CVE-2022-46873) Opened 4 years ago Closed 2 years ago

Firefox 63+ CSP Hashes Allow Inline Event Handler Script Execution without 'unsafe-hashes' specified

Categories

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

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
108 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- wontfix
firefox107 --- wontfix
firefox108 --- verified

People

(Reporter: pete, Assigned: tschuster)

References

(
URL
)

Details

(Keywords: sec-moderate, Whiteboard: [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?][post-critsmash-triage][adv-main108+])

Attachments

(2 files)

testcase.html
(deleted), text/html
Details
advisory.txt
(deleted), text/plain
Details

According to the CSP Level 2 Specification "If 'unsafe-inline' is not in the list" ... "Whenever the user agent would execute an inline script from an inline event handler, instead the user agent MUST NOT execute script, and MUST report a violation." https://www.w3.org/TR/CSP2/#allowed-script-sources however FireFox 62 and below followed the spec, but starting with FireFox 63 it ignores this restriction.

The change in the code that allowed this appears to be here:
https://searchfox.org/mozilla-central/diff/5fff1762ada26b04519cf8ed24489ca1b0f73c2f/dom/security/nsCSPContext.cpp#551-566

Given a CSP policy: default-src 'none';script-src 'sha256-vmevK1pwVutIOH96hxUOXymyXdR2hSlZRAu8QWiW3dw='; and the markup: <body onload="alert('attr');"> the hash matches: "alert('attr');" it will allow execution of the script. You can see an example of this in the test page: https://www.petefreitag.com/test/csp-hash-bug.html

Again, according to the CSP Level 2 spec it should only allow a valid hash or a valid nonce on "a script element". So, it should only allow it in the form: <script>alert('attr');</script> not in an inline event handler.

The CSP Level 3 spec added a CSP source list keyword 'unsafe-hashes' which provides a way to allow execution of inline script event handlers. A bug is already filed to track implementation of unsafe-hashes: https://bugzilla.mozilla.org/show_bug.cgi?id=1343950

It appears that the best way to fix this security issue would be to implement 'unsafe-hashes'. Anyone attempting to use a hash on an inline script event handler would find that it fails to execute in Chrome without adding 'unsafe-hashes', so I would not imagine any legitimate use cases would rely on the current behavior.

Flags: sec-bounty?
Group: firefox-core-security → dom-core-security
Component: Security → DOM: Security
Product: Firefox → Core
Group: core-security
Summary: Firefox 63+ CSP Hashes are allowed to Execute on inline scripts → Firefox 63+ CSP Hashes Allow Inline Event Handler Script Execution

Fixing security groups.

Group: core-security
Type: task → defect
Severity: -- → S3
Status: UNCONFIRMED → NEW
Depends on: csp-unsafe-hashes
Ever confirmed: true
Keywords: sec-moderate
Priority: -- → P3
Summary: Firefox 63+ CSP Hashes Allow Inline Event Handler Script Execution → Firefox 63+ CSP Hashes Allow Inline Event Handler Script Execution without 'unsafe-hashes' specified
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?]
Flags: sec-bounty? → sec-bounty+
Attachment #9192034 - Attachment description: pete@foundeo.com,750,2020-06-10,,2020-12-08,true,,, → pete@foundeo.com,750,2020-06-10,,2020-12-08,true,Pete Freitag / Foundeo Inc.,,https://foundeo.com/

Christoph, please review the severity of this and find an assignee.

Flags: needinfo?(ckerschb)

Hey Dan, we have not implemented unsafe-hashes and i don't think we are going to. FWIW, we would have Bug 1343950 on file for implementing it. Given that, is this still a sec-moderate? Or put differently, anything else we could do with this bug? Or does it go back into the backlog?

Flags: needinfo?(ckerschb) → needinfo?(dveditz)
Blocks: 1788864
Depends on: 1797070

The test case is not accessible anymore, but bug 1797070 should fix this. With that bug fixed we only use hashes of attributes after unsafe-hashes is specified in the CSP. However with unsafe-hashes being disabled by default that means there is no way of using hashes for attributes.

No longer depends on: 1797070
Depends on: 1797070

We might also consider unhiding this bug, considering while probably not widely known, I have seen at least one reference to this: https://csplite.com/csp/test173/#bug_ff_unsafe-hashes_event_handler. (I think I remember one other that I can't find right now)

Attached file testcase.html (deleted) —

As expected this was fixed by bug 1797070. While the test page in comment 0 is not accessible anymore, I recreated it based on the description.

In Nightly we don't execute the script, but we still do in Firefox release.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Assignee: nobody → tschuster
Group: dom-core-security → core-security-release
status-firefox107: --- → wontfix
status-firefox108: --- → fixed
status-firefox-esr102: --- → wontfix
Target Milestone: --- → 108 Branch

Tom, could we manualy

Flags: qe-verify+
Whiteboard: [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?] → [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?][post-critsmash-triage]

(In reply to Brindusa Tot[:brindusat] from comment #8)

Tom, could we manualy

Seems like something got lost here. 🙂

Flags: needinfo?(brindusa.tot)

(In reply to :Gijs (he/him) from comment #9)

(In reply to Brindusa Tot[:brindusat] from comment #8)

Tom, could we manualy

Seems like something got lost here. 🙂

Yes, seems that something got lost! I suppose my question here was: could we manually verify this with testcase from comment 7? Should we do some more verification on this issue?

Flags: needinfo?(brindusa.tot) → needinfo?(tschuster)
Attachment #9303266 - Attachment filename: file_1644790.txt → file_1644790.html
Attachment #9303266 - Attachment mime type: text/plain → text/html
Flags: needinfo?(tschuster)

You can verify this using the attachment. In a fixed version nothing should happen and in an unfixed version you should see an alert with the message "attr".

I have reproduced the alert message described in the above comment, using testcase.html from comment 7 with an affected Nightly build (2022-11-01) on Win 10 x64.

The issue is verified as fixed on latest Beta 108.0b9 across platforms: Win 10 x64, macOS 11 and Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
status-firefox108: fixed → verified
Flags: qe-verify+
Whiteboard: [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?][post-critsmash-triage] → [domsecurity-backlog][reporter-external] [client-bounty-form] [verif?][post-critsmash-triage][adv-main108+]
Attached file advisory.txt (deleted) —
Alias: CVE-2022-46873
Regressions: 1805948

Unhiding given comment 6, that we have published the advisory now, and that people are discovering sites broken by this fix

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: