Closed Bug 1670913 Opened 4 years ago Closed 4 years ago

DOM Sanitizer API should parse into a throw-away "loaded as data" document

Categories

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

defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 --- wontfix
firefox83 --- disabled
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: hsivonen, Assigned: freddy)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, sec-moderate, Whiteboard: [domsecurity-active][post-critsmash-triage][adv-main90-])

Attachments

(1 file)

Currently, dom/security/sanitizer/Sanitizer.cpp uses a DocumentFragment whose owner is the document of the script global.

To avoid initiating fetches for img/audio/etc. src if the node gets removed by the sanitizer, the DocumentFragment used as parsing target should belong to a Document that has its "loaded as data" bit set.

See Also: → CVE-2020-26956

The relevant Web-exposed API is preffed off, but the same problem applies elsewhere, too. Let's keep this bug hidden as long as the related bugs are.

I can take it, but I'm going to have questions down the line. Thanks for filing, Henri!

Assignee: nobody → fbraun
Status: NEW → ASSIGNED

Set release status flags based on info from the regressing bug 1652481

(In reply to Frederik Braun [:freddy] from comment #2)

I can take it, but I'm going to have questions down the line. Thanks for filing, Henri!

Bug 1666300 part 2 provides a function that will be of use here.

Severity: -- → S4
Priority: -- → P2
Whiteboard: [domsecurity-active]
Group: core-security → dom-core-security
Keywords: sec-moderate

Masato Kinugawa (now in CC) found the same thing.
The Sanitizer API will make requests when parsing markup with external resources and really shouldn't.
E.g., (new Sanitizer()).sanitize("<img src='https://example.com'></img>")

Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
Flags: in-testsuite+

The patch landed in nightly and beta is affected.
:freddy, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(fbraun)

It's a disabled configuration and we're explicitly asking for folks to test on Nightly. I don't think the uplift is justified.
I'm wondering if a status of "disabled" is better than "wontfix" for the general analyses? Both apply here and I'm taking the bots recommendation.

Flags: needinfo?(fbraun)

Could this be manualy verified? If yes, please help us with some specific steps or a testcase.

Flags: qe-verify?
Flags: needinfo?(fbraun)
Whiteboard: [domsecurity-active] → [domsecurity-active][post-critsmash-triage]

No need, the patch comes with an automated test.

Flags: needinfo?(fbraun)
Flags: qe-verify? → qe-verify-
Whiteboard: [domsecurity-active][post-critsmash-triage] → [domsecurity-active][post-critsmash-triage][adv-main90+]

Actually, if this is disabled in release we don't need an advisory.

Whiteboard: [domsecurity-active][post-critsmash-triage][adv-main90+] → [domsecurity-active][post-critsmash-triage][adv-main90-]
Group: core-security-release
Has Regression Range: --- → yes
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: