Closed Bug 1937097 (CVE-2025-4082) Opened 1 year ago Closed 1 year ago

Mac OS X Firefox WebGL shader attribute type OOB read in gleRunVertexSubmitImmediate

Categories

(Core :: Graphics: CanvasWebGL, defect, P1)

defect

Tracking

()

VERIFIED FIXED
139 Branch
Tracking Status
firefox-esr115 138+ verified
firefox-esr128 138+ verified
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- wontfix
firefox137 --- wontfix
firefox138 + verified
firefox139 --- verified

People

(Reporter: pore45214, Assigned: jgilbert)

References

Details

(Keywords: csectype-bounds, reporter-external, sec-high, Whiteboard: [client-bounty-form][adv-main138+][adv-esr115.23+][adv-esr128.10+])

Crash Data

Attachments

(4 files, 1 external file, 3 obsolete files)

Attached file crash_minimized.html โ€”

Steps to reproduce the problem

  1. run firefox on Mac OS X
  2. Open crash_minimized.html
  3. Crash

Vulnerability

I found a vulnerability via drawArrays in webgl which ends up in a wild OOB read in gleRunVertexSubmitImmediate called from
gleDrawArraysOrElements_ExecCore.

  if ( (v25 & 0x200000) != 0 )
        {
          if ( (v25 & 0xBC000) != 0 || (v173 = -1, (*a6 & 0x1000000000LL) != 0) )
          {
            if ( v28 > 0xF )
              v44 = 32 * v28 + 8176;
            else
              v44 = 16 * v28 + 8432;
            v173 = v44;
          }
        }
        v55 = v25 >> 40;
        v56 = *a6;
        if ( (~*(_DWORD *)a6 & 0x700) != 0 )
        {
          v57 = (const __m128i *)(*(_QWORD *)(v194 + 8LL * v28) + v184 * v55); // [1]
        }
        else
        {
          v57 = (const __m128i *)((char *)v189 + (int)v55 - v171); // [2]
          v171 = v55;
        }
        v189 = v57;
 case 6:                       // crash case
                    if ( (v26 & 0x1000000) != 0 )
                    {
                      a11 = *(__m128 *)v57; // [3]
                      LODWORD(v32) = 6;
                    }
  • [1] Alternatively, get a pointer from [2], which can be controlled by the drawArrays argument.
  • And [3] will read the pointer without any verification, resulting in an OOB read.

The vulnerability may affect sandbox escape as the Browser Process crashes.

Version: Firefox 135.0a1
Type of crash: Browser Process

Flags: sec-bounty?

Credit: un3xploitable && GF

I don't know this code at all, but I do see GLContext::AfterGLCall_Debug in the stack so I'm not sure we'll run this code outside of a debug build (when MOZ_GL_DEBUG_BUILD is set).

Group: firefox-core-security → gfx-core-security
Component: Security → Graphics: CanvasWebGL
Product: Firefox → Core

bp-b7fda0c6-3c2b-4651-ac09-624a00241217

Crashes in Release (133) and ESR 128.5

Duplicate of this bug: 1937294

Same testcase as bug 1937294. Both credit "Un3xploitable"; are "GF" and "p0her" the same, or are there three people involved?

The crashing address comes right out of the testcase (times 0x10). I'm not sure what this could do for an attacker... Assuming they knew a valid and interesting address in the parent process it looks like this data could get drawn into the canvas and then potentially interpreted by the attacker?

Crash Signature: [@ gleRunVertexSubmitImmediate ]
Keywords: csectype-bounds

The bug has a crash signature, thus the bug will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
No longer duplicate of this bug: 1937294
See Also: → 1937294

Andrew un-duped them because there are some differences. We'll leave it to Kelsey to let us know if those are relevant or if the underlying bug is the same.

Flags: needinfo?(jgilbert)
See Also: → 1938184
See Also: → 1938194
Keywords: sec-high

The testcase is basically just:

  program1 = gl1.createProgram();
  gl1.attachShader(program1, vShader1);
  gl1.attachShader(program1, fShader1);
  gl1.linkProgram(program1);
  gl1.useProgram(program1);

  try { gl1.vertexAttribDivisor(0, gl1.SYNC_FLAGS); } catch (e) { console.log(e.message); }
  try { gl1.drawArrays(gl1.LINES, 0x4342414, 3); } catch (e) { console.log(e.message); }

  window.close();

It looks like DoFakeVertexAttrib0 will in some cases modify vertex attrib 0 state (e.g. gl->fVertexAttribDivisor(0, 0);) but then later in the function returns early without restoring state, which causes the callsites to not restore vertex attrib 0 state via DoVertexAttrib(0).

Assignee: nobody → jgilbert
Severity: -- → S2
Status: NEW → ASSIGNED
Flags: needinfo?(jgilbert)
Priority: -- → P1
Attached file crash_minimized2.html โ€”

Adds some <html> tags and status printing, and without window.close().

Attachment #9446718 - Attachment is obsolete: true
Duplicate of this bug: 1937294
Duplicate of this bug: 1938184
Duplicate of this bug: 1938194
Duplicate of this bug: 1939225
Duplicate of this bug: 1939228

I'm going to guess that this affects all branches but adjust as appropriate.

I'm removing bugs from the "see also" that have been duped to this bug, to make things clearer. If they end up getting unduped in the future, we'll want to re-add them.

I am still working on the test, since I want to be more exhaustive than usual here.

Still working on the test, sorry!

Any patch commit is uploaded?

Any update?

Kelsey has just gotten the test to a point where it can exercise formats and some of the attributes. She is already finding bugs to be fixed because of it. We're making progress.

Flags: needinfo?(pore45214)
Attachment #9458963 - Attachment is obsolete: true

Could I get the patch of this bug?

Flags: needinfo?(pore45214)

Comment on attachment 9474254 [details]
Bug 1937097 - Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size.

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Moderate difficulty to reverse-engineer a crash from the patch, but I don't think this is an easy vector to leverage into an exploit.
  • 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all, flags are correct
  • 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?: easy
  • How likely is this patch to cause regressions; how much testing does it need?: Low-to-moderate risk: I have run my prototype extensive fetch test on this on the affected platform, and I feel like I have a good handle on the what and why of this, but also this is just a risky area, and there's a chance that some site somewhere breaks on some other machine.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: No
Attachment #9474254 - Flags: sec-approval?

Comment on attachment 9474254 [details]
Bug 1937097 - Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-high
  • User impact if declined: sec-high, and in some cases incorrect rendering, but nothing known
  • Fix Landed on Version: none
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Low-to-moderate risk: I have run my prototype extensive fetch test on this on the affected platform, and I feel like I have a good handle on the what and why of this, but also this is just a risky area, and there's a chance that some site somewhere breaks on some other machine.
Attachment #9474254 - Flags: approval-mozilla-esr128?
Attachment #9474254 - Flags: approval-mozilla-esr115?

Comment on attachment 9474254 [details]
Bug 1937097 - Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size.

Approved to land, let's get it in Nightly to bake before uplifting.

Attachment #9474254 - Flags: sec-approval? → sec-approval+
Pushed by jgilbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a5e85f7bba49 Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size. r=gfx-reviewers,lsalzman
Group: gfx-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch

The patch landed in nightly and beta is affected.
:jgilbert, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(jgilbert)

We are awarding a sec high bounty for this bug. Because duplicate bug 1937294 was filed within our collision window the bounty will be split between the two bugs.

Flags: sec-bounty? → sec-bounty+

:jgilbert This has no uplift request for beta, but I assume we still want this in 138?
It has baked in nightly for about two weeks.

Comment on attachment 9474254 [details]
Bug 1937097 - Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size.

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Sec-high. Already uplifted to ESR, probably intended to be in current Beta train.
  • Is this code covered by automated tests?: No
  • 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):
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9474254 - Flags: approval-mozilla-beta?

Comment on attachment 9474254 [details]
Bug 1937097 - Use MakeScopeExit for WebGLContextDraw workarounds, and track fake-attrib0 initialized vs alloc size.

Approved for 138.0b9
Approved for 115.23esr
Approved for 128.10esr

Attachment #9474254 - Flags: approval-mozilla-esr128?
Attachment #9474254 - Flags: approval-mozilla-esr128+
Attachment #9474254 - Flags: approval-mozilla-esr115?
Attachment #9474254 - Flags: approval-mozilla-esr115+
Attachment #9474254 - Flags: approval-mozilla-beta?
Attachment #9474254 - Flags: approval-mozilla-beta+
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+
QA Whiteboard: [post-critsmash-triage] → [post-critsmash-triage] [qa-triaged]

Reproduced the crash on Firefox 135.0a1 (2024-12-13) on macOS 15.4.1 by following the STR from Comment 0 and both the crash_minimized poc files.

The issue is fixed on Firefox 115.23.0esr, Firefox 128.10.0esr, Firefox 138.0 and Firefox 139.0a1 on the same system.

QA Whiteboard: [post-critsmash-triage] [qa-triaged] → [post-critsmash-triage]
Whiteboard: [client-bounty-form] → [client-bounty-form][adv-main138+]
Whiteboard: [client-bounty-form][adv-main138+] → [client-bounty-form][adv-main138+][adv-main115.23+]
Whiteboard: [client-bounty-form][adv-main138+][adv-main115.23+] → [client-bounty-form][adv-main138+][adv-esr115.23+]
Whiteboard: [client-bounty-form][adv-main138+][adv-esr115.23+] → [client-bounty-form][adv-main138+][adv-esr115.23+][adv-esr128.23+]
Whiteboard: [client-bounty-form][adv-main138+][adv-esr115.23+][adv-esr128.23+] → [client-bounty-form][adv-main138+][adv-esr115.23+][adv-esr128.10+]
Attached file advisory.txt (obsolete) โ€”
Attached file advisory.txt โ€”
Attachment #9480687 - Attachment is obsolete: true
Flags: needinfo?(jgilbert)
Group: core-security-release
Alias: CVE-2025-4082
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: