Closed Bug 1735265 (CVE-2022-28286) Opened 1 year ago Closed 11 months ago

Firefox incorrectly draws outside of iframe.

Categories

(Core :: Web Painting, defect, P1)

Firefox 93
defect

Tracking

()

VERIFIED FIXED
100 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 99+ verified
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 + verified
firefox100 + verified

People

(Reporter: prada960808, Assigned: mikokm)

References

(Regression)

Details

(Keywords: csectype-spoof, regression, sec-low, Whiteboard: [adv-main99+][adv-esr91.8+])

Attachments

(9 files, 2 obsolete files)

Attached file parent.html (obsolete) —

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36

Steps to reproduce:

  1. open 'parent.html' on Firefox 93.
  2. load 'child.html' by executing Js code
    set_frame('./child.html');

Actual results:

The content in iframe is drawn outside of iframe even if 'child.html' is loaded from a local server.

Expected results:

The content in iframe should not be drawn outside of iframe.

Attached file child.html (obsolete) —
Attached image ref_image.png
Attached file test.html
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Regressed by: 1691875

A layout change caused this but this is a graphics/displaylist issue afaict. Miko, any chance you could take a look?

Component: Layout → Web Painting
Flags: needinfo?(mikokm)

Is this a security issue?
It seems this can cover the content of the main frame from the iframe so that the user cannot see the website properly.

Looking into this.

Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Flags: needinfo?(mikokm)
Attached file parent.html
Attachment #9245388 - Attachment is obsolete: true
Attachment #9245389 - Attachment is obsolete: true
Attached file child.html

Attached simplified testcases.

It seems that <colgroup> creates a table width sized background item that extends beyond the body bounds when the overflow is hidden. This seems to only happen when the corresponding <th> element has a stacking context or layer inducing style such as filter or will-change: transform (but surprisingly opacity does not work).

The severity field is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(matt.woodrow)
Severity: -- → S2
Flags: needinfo?(matt.woodrow)
Priority: -- → P3
Attached file dl.txt

Display list dump.

It seems that TableBackgroundColor item ends up outside of the transform item, despite having will-change: transform set.

Depends on D129681

The reporter requested that we consider this issue for the security bug bounty.

What are the limits or restrictions on what can be drawn on the framing page?

Group: gfx-core-security
Flags: sec-bounty?
Flags: needinfo?(mikokm)

(In reply to Daniel Veditz [:dveditz] from comment #15)

The reporter requested that we consider this issue for the security bug bounty.

What are the limits or restrictions on what can be drawn on the framing page?

Consider a parent document with an iframe pointing to a child document that contains a table.
When a table header cell has stacking context inducing properties, its colum and column group backgrounds might be incorrectly clipped. If the table is large enough, these backgrounds can cover elements outside of the parent documents iframe bounds.

I was able to construct a testcase that fully covers the parent document in red. Browser chrome is unaffected.

Flags: needinfo?(mikokm)

I assume a background image could be used as well? That makes the possibilities more interesting, but as an attack you'd still have to get your potential victim to frame you, and then hope there was something critical you could "erase" by covering it up or "replace" with an image that somehow fooled the viewer into interpreting things differently.

When CSS background-image is used in element "colgroup", you can cover and replace the web contents with the image.
You can also place that image by applying the CSS width, height, left and top to the table element.

Attached file poc.html

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Not easily, it would require knowledge of how Gecko handles clipping and table backgrounds.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
  • Which older supported branches are affected by this flaw?: All
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: The code changed in the patch was recently (FF92) moved to a different file, but the fix would be the same.
  • How likely is this patch to cause regressions; how much testing does it need?: Unlikely to cause regressions.
Attachment #9248040 - Flags: sec-approval?
Attachment #9248041 - Flags: sec-approval?

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

sec-low does not require sec-approval, you can land the patch and test as normal.

Attachment #9248040 - Flags: sec-approval?
Attachment #9248041 - Flags: sec-approval?
Flags: needinfo?(mikokm)

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:miko, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(mstange.moz)
Flags: needinfo?(mikokm)
Flags: needinfo?(mstange.moz)
Flags: needinfo?(mikokm)

I think this was originally regressed by bug 1409114.

Regressed by: 1409114
No longer regressed by: 1691875
See Also: → 1760823

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

Group: gfx-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

Please nominate this for Beta/ESR approval when you get a chance.

Flags: needinfo?(mikokm)

Changing the priority to P1 as the bug is tracked by a release manager for the current beta.
See Triage for Bugzilla for more information.
If you disagree, please discuss with a release manager.

Priority: P3 → P1

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

Beta/Release Uplift Approval Request

  • User impact if declined: Table cell contents can overflow table bounds
  • 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 simple and includes a test. Additionally, this table structure is probably relatively rare.
  • String changes made/needed:
Flags: needinfo?(mikokm)
Attachment #9248040 - Flags: approval-mozilla-beta?
Attachment #9248041 - Flags: approval-mozilla-beta?

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

Approved for 99.0b8. Thanks.

Attachment #9248040 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9248041 [details]
Bug 1735265 - Part 2: Add test r=mstange

Approved for 99.0b8. Thanks.

Attachment #9248041 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange
https://hg.mozilla.org/releases/mozilla-beta/rev/e3a76df996b6
Part 2: Add test r=mstange
https://hg.mozilla.org/releases/mozilla-beta/rev/97b3e77ec5a7

Do we want this on ESR also?

Flags: needinfo?(mikokm)
Flags: in-testsuite+

(In reply to Ryan VanderMeulen [:RyanVM] from comment #33)

Do we want this on ESR also?

I cannot comment about the security implications, but I think this is quite safe to uplift.

Flags: needinfo?(mikokm)

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Low risk patch that fixes a sec-low issue.
  • User impact if declined: Table cell contents can overflow table bounds. Probably not a common issue in normal web content but has some security implications.
  • Fix Landed on Version: 100
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is simple and includes a test.
Attachment #9248040 - Flags: approval-mozilla-esr91?
Attachment #9248041 - Flags: approval-mozilla-esr91?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

I was able to reproduce this issue on my machine Win 10x64 on Nightly 95.0a1. I confirm the fix on Firefox 99.0b8 and Nightly 100.0a1

Status: RESOLVED → VERIFIED

Comment on attachment 9248040 [details]
Bug 1735265 - Part 1: Set clip on background items for table cols and colgroups, when the table cell has captured clip r=mstange

Thanks for the verification. Approved for 91.8esr.

Attachment #9248040 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9248041 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Whiteboard: [adv-main99+]
Attached file advisory.txt
Whiteboard: [adv-main99+] → [adv-main99+][adv-esr91.8+]
Alias: CVE-2022-28286

Verified fixed on Fx 91.8esr on Win 10x64. Reproduced on 91.6.1esr.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Flags: sec-bounty? → sec-bounty+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.