Closed Bug 1794292 (CVE-2023-29531) Opened 2 years ago Closed 2 years ago

Firefox WebGL glvmInterpretFPTransformFour Memory Corruption Vulnerability

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Version:
Firefox 105
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
113 Branch
Tracking Flags:
Tracking Status
firefox-esr102 112+ fixed
firefox110 --- wontfix
firefox111 - wontfix
firefox112 + fixed
firefox113 + fixed

People

(Reporter: d4ni31, Assigned: jgilbert, NeedInfo)

References

(Depends on 1 open bug)

Details

(4 keywords, Whiteboard: [post-critsmash-triage][adv-main112+][adv-esr102.10+])

Attachments

(10 files, 4 obsolete files)

poc.html
2.47 KB, text/html
Details
5 results for Address Sanitizer
52.27 KB, text/plain
Details
debug crash stack
8.64 KB, text/plain
Details
Firefox Linux on VirtualBox ASAN
6.50 KB, text/plain
Details
asan.txt
31.82 KB, text/plain
Details
Bug 1794292 - [esr102] [ANGLE] cherry-pick init-gl-point-size.
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr102+
Details | Review
Bug 1794292 - [esr102] Use init-gl-point-size on mac.
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr102+
Details | Review
Bug 1794292 - [ANGLE] cherry-pick init-gl-point-size.
48 bytes, text/x-phabricator-request
diannaS
: approval-mozilla-beta+
Details | Review
Bug 1794292 - Use init-gl-point-size on mac.
48 bytes, text/x-phabricator-request
diannaS
: approval-mozilla-beta+
Details | Review
advisory.txt
290 bytes, text/plain
Details
Attached file poc.html —

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

Steps to reproduce:

Title

  • Firefox WebGL glvmInterpretFPTransformFour OOB Access Vulnerability

Summary

  • A OOB Access vulnerability exists in the WebGL glvmInterpretFPTransformFour
  • The browser process crashes when triggering this bug.

Test environment

  • Product : Mozilla Firefox 105.0.3
  • OS : macOS Monterey 12.6 (M1 Pro ARM)

Root Cause Analysis

* thread #25, name = 'CanvasRenderer', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=2, address=0x1715efff8)
  frame #0: 0x00000001ade070cc libsystem_pthread.dylib`___chkstk_darwin + 60
libsystem_pthread.dylib`:
->  0x1ade070cc <+60>: ldur   x11, [x11, #-0x8]
  0x1ade070d0 <+64>: mov    x10, sp
  0x1ade070d4 <+68>: cmp    x9, #0x1, lsl #12         ; =0x1000
  0x1ade070d8 <+72>: b.lo   0x1ade070f0               ; <+96>
Target 0: (firefox) stopped.
(lldb) bt
* thread #25, name = 'CanvasRenderer', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=2, address=0x1715efff8)
* frame #0: 0x00000001ade070cc libsystem_pthread.dylib`___chkstk_darwin + 60
  frame #1: 0x000000020f692db4 libGLProgrammability.dylib`glvmInterpretFPTransformFour + 424
  frame #2: 0x000000020f913b88 GLRendererFloat`gldLLVMFPTransformFallback + 444
  frame #3: 0x000000020f915cb8 GLRendererFloat`gldLLVMVecPointRender + 6940
  frame #4: 0x000000020f90e5c0 GLRendererFloat`gldRenderPoints + 76
  frame #5: 0x000000020f8e0524 GLEngine`gleLLVMVecPrimPointRender + 1684
  frame #6: 0x000000020f83b88c GLEngine`glDrawArraysInstanced_STD_GL3Exec + 1296
  frame #7: 0x000000020f83acd8 GLEngine`glDrawArrays_UnpackThread + 48
  frame #8: 0x000000020f87689c GLEngine`gleCmdProcessor + 116
  frame #9: 0x00000001adc481b4 libdispatch.dylib`_dispatch_client_callout + 20
  frame #10: 0x00000001adc57414 libdispatch.dylib`_dispatch_lane_barrier_sync_invoke_and_complete + 56
  frame #11: 0x000000020f7e2ac8 GLEngine`glFlush_ExecThread + 32
  frame #12: 0x000000011106ac50 XUL`___lldb_unnamed_symbol52768 + 40
  frame #13: 0x00000001114e90c8 XUL`___lldb_unnamed_symbol63264 + 2252
  frame #14: 0x00000001146fd0a4 XUL`___lldb_unnamed_symbol207810 + 980
  frame #15: 0x0000000113c48764 XUL`___lldb_unnamed_symbol166963 + 312
  frame #16: 0x0000000110e907e8 XUL`___lldb_unnamed_symbol49031 + 756
  frame #17: 0x0000000110e91a24 XUL`___lldb_unnamed_symbol49039 + 168
  frame #18: 0x0000000110c15b4c XUL`___lldb_unnamed_symbol41826 + 4308
  frame #19: 0x0000000110e945d0 XUL`___lldb_unnamed_symbol49067 + 476
  frame #20: 0x0000000110e5ceb8 XUL`___lldb_unnamed_symbol48460 + 80
  frame #21: 0x0000000110c0ea24 XUL`___lldb_unnamed_symbol41796 + 288
  frame #22: 0x0000000100f46fa8 libnss3.dylib`___lldb_unnamed_symbol2250 + 260
  frame #23: 0x00000001ade0c26c libsystem_pthread.dylib`_pthread_start + 148
(lldb) mem read 0x1715efff8
error: memory read failed for 0x1715efe00

  • If you debug at the point where the crash occurred, you can see that the crash occurred in OpenGLMT.

  • This bug is an Out-Of-Bounds Access vulnerability that occurs in WebGL's handling of the drawElements command.

Proof-of-Concept

  • Please check the attached file!

Reproduce

  • open a poc.html in Firefox
  • Wait a few seconds.

CREDIT Information

  • Dohyun Lee (@l33d0hyun) of SSD Labs

Actual results:

.

Expected results:

.

## Address Sanitizer
Attached file delete (obsolete) —
## Address Sanitizer
Attachment #9297761 - Attachment description: OK → delete

I had a similar problem with Google Chrome. This is a Security Issue and needs a fix. I'll link the case ID of a similar case

https://bugs.chromium.org/p/chromium/issues/detail?id=1314383

Summary: Firefox WebGL glvmInterpretFPTransformFour OOB Access Vulnerability → Firefox WebGL glvmInterpretFPTransformFour Bad-Free (Heap Corruption) Vulnerability

ASAN was tested on Linux running on VMware. Some crashes occurred in vmwgfx_dri.so, but some crashes occur in Mozilla Firefox. Check out 5 ASAN results on #C3

Windows does not appear to be affected by this vulnerability. Only macOS and Linux seem to be affected

This may be related to Use-After-Free or Double Free.

Summary modify:
Firefox WebGL glvmInterpretFPTransformFour OOB Access Vulnerability → Firefox WebGL glvmInterpretFPTransformFour Bad-Free (Heap Corruption) Vulnerability

Add Mozilla Security team

Flags: needinfo?(dveditz)
Group: firefox-core-security → gfx-core-security
Component: Untriaged → Graphics
Product: Firefox → Core
Component: Graphics → Graphics: CanvasWebGL
Flags: needinfo?(dveditz)

I marked comment 3 as "obsolete" so it would be hidden. The contents are in the attachment, and it was taking up a lot of room in this bug.

Thanks Andrew!

Attached file debug crash stack —

Here's the crash stack I get in a debug build. It is hitting a DOM thread safety assertion, but it looks like that's just some weird fallout from AppleIntelKBLGraphicsGLDriver hitting a fatal error and bailing out in a weird way.

There's also this in the log, which is not a sort of error I've seen before:
LLVM ERROR: OCL IGC-Internal-ERRORERROR!!!: Non-OCL is not supposed to reach here!

Hi Andrew,

Could you please check comment #4? A case similar to this bug has also occurred in Google Chrome. It would be good to refer to

Attachment #9297761 - Attachment is obsolete: true

This is an ASAN log that occurs in Linux running in VirtualBox.
I think it's the same case as the problem with Google Chrome.

Root Cause Analysis (Update)

This vulnerability has the following flow:
Call the erase function in [1] and delete objects[i] in [2]. In [3], you can see that the texture's destructor calls the cleanup function. Finally, in [4], a crash occurs in the process of free(buf);.

This crash is caused by an attempt to free an invalid pointer named Buf.

void DeleteTexture(GLuint n) {
  if (n && ctx->textures.erase(n)) {		// [1]
    for (size_t i = 0; i < MAX_TEXTURE_UNITS; i++) {
      ctx->texture_units[i].unlink(n);
    }
  }
}

[1] https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/gl.cc#1862

  bool erase(size_t i) {
    if (i < size && objects[i]) {
      on_erase(objects[i], nullptr);
      delete objects[i];		// [2]
      objects[i] = nullptr;
      if (i < first_free) first_free = i;
      return true;
    }
    return false;
  }

  O** begin() const { return objects; }
  O** end() const { return &objects[size]; }
};

[2] https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/gl.cc#731

~Texture() { cleanup(); }		// [3]

[3] https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/gl.cc#544

  void cleanup() {
    assert(!locked);  // Locked textures shouldn't be destroyed
    if (buf) {
      // If we need to toggle SHOULD_FREE state, ensure that buf is nulled out,
      // regardless of whether we internally allocated it. This will prevent us
      // from wrongly treating buf as having been internally allocated for when
      // we go to realloc if it actually was externally allocted.
      if (should_free()) {
        free(buf);		// [4]
      }
      buf = nullptr;
      buf_size = 0;
      buf_bpp = 0;
      buf_stride = 0;
    }
    disable_delayed_clear();
  }

[4] https://searchfox.org/mozilla-central/source/gfx/wr/swgl/src/gl.cc#534

comment #15:
I think it's the same case as the problem with Google Chrome. -> The same type of vulnerability that occurred in Google Chrome, but in a different location.

Regarding comment 16, SWGL would not be implicated in this bug as the testcase uses WebGL, and WebGL never uses SWGL.

As far as the trace in comment 15, the testcase does not create textures at all, so it wouldn't lead to the aforementioned problem in any case. The testcase does an uncomplicated update of the WebGL canvas, which WebRender will display using SWGL.

As WebRender will use SWGL (which is completely software and doesn't use any hardware resources), whereas WebGL will use HW OpenGL (i.e. Mesa, macOS's GL implementation, etc.) there is no actual way these two different libraries can interact.

It seems more like, since the testcase just repeatedly creates new shaders in a setTimeout loop, that we're just causing a species of OOM here with the spamming of WebGL commands exhausting memory and this later showing up as the strange SWGL trace in comment 15.

Now, macOS doesn't actually use SWGL for WebRender at the moment, so the fact that something strange (but different) happens there without SWGL points more to the OOM theory.

Kelsey, thoughts?

Flags: needinfo?(jgilbert)

Hi Lee,

Removing the setTimeout from the testcase has the same problem.
Additionally, if you debug this crash, you can see that it is EXC_BAD_ACCESS, not OOM caused by exhausting memory.

* thread #26, name = 'CanvasRenderer', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=2, address=0x16e8a7ff8)
    frame #0: 0x00000001ade070cc libsystem_pthread.dylib___chkstk_darwin + 60
libsystem_pthread.dylib:
->  0x1ade070cc <+60>: ldur   x11, [x11, #-0x8]
    0x1ade070d0 <+64>: mov    x10, sp
    0x1ade070d4 <+68>: cmp    x9, #0x1, lsl #12         ; =0x1000
    0x1ade070d8 <+72>: b.lo   0x1ade070f0               ; <+96>
(lldb) mem read 0x000000016e8a8000-0x8
error: memory read failed for 0x16e8a7e00

The point where the crash occurred in lldb is [x11-0x8], which is determined to refer to an invalid address.

(In reply to DoHyun Lee from comment #14)

Could you please check comment #4? A case similar to this bug has also occurred in Google Chrome. It would be good to refer to

That is a different bug entirely. We do use ANGLE, but we don't use any of the GPU parts of it nor the vk:: (vulcan) code specifically.

Hi dveditz,

So I mentioned that it could be a similar bug! The bad-free type is the first bug I've ever seen. However, the call stack is similar, so I put a reference.

rating based on the evidence it might be heap corruption, but there's also a chance this is OOM whackage that has corrupted our tracing tools. Needs a closer look from the GFX folks

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, sec-high, testcase

Recently changed to a sec-high, asking for re-triage and a closer look to determine if it's truly a sec-high and actionable.

Blocks: gfx-triage

The Chrome/ANGLE change to fix this is the vulkan backend which we don't use. So it seems like there may be issues in multiple places

I'm not able to repro this with the poc in comment #0 on Ubuntu 22.04 LTS with a pure AMD machine (Ryzen 9 5950X, Radeon RX 6700 XT) using mozregression from ff95 to current nightly, is there a more specific config setting needed to repro?

Assignee: nobody → bwerth

I agree that it looks like likely multiple issues here. I'm going to focus on the Mac issue posted in the original post.

The stacks from Mac remind me of bug 1773874, where we have crashes during codegen, due to large array allocations in webgl shaders.
In this case, the testcase has:

void main( void ) 
{
	const int numColors = 9000;
	vec3 colors[numColors];

That's 349000=108,000B, though generally vec3 is padded to vec4, so 144,000B likely.
In 1773874 I found that there's a threshold around 32KiB below which the crashes went away.
This doesn't have exactly the same symptoms, but that does jump out at me.

There is this line too:

LLVM ERROR: OCL IGC-Internal-ERRORERROR!!!: Non-OCL is not supposed to reach here!

LLVM seems like it sometimes calls OpenCL "OCL", so yeah I think the system shader compiler is exploding.

(In reply to Brad Werth [:bradwerth] from comment #26)

Just reproduced on macOS with this crash report.

0 	libsystem_pthread.dylib 	___chkstk_darwin 		context
1 	libGLProgrammability.dylib 	glvmInterpretFPTransformFour 		cfi
2 	GLRendererFloat 	gldLLVMFPTransformFallback 		cfi
3 	GLRendererFloat 	gldLLVMVecPointRender 		cfi
4 	GLRendererFloat 	gldRenderPoints 		cfi
5 	GLEngine 	gleLLVMVecPrimPointRender 		cfi
6 	GLEngine 	glDrawElementsInstancedBaseVertex_STD_GL3Exec 		cfi
7 	GLEngine 	glDrawElements_UnpackThread 		cfi
8 	GLEngine 	gleCmdProcessor 		cfi
9 	libdispatch.dylib 	_dispatch_client_callout 		cfi
10 	libdispatch.dylib 	_dispatch_lane_barrier_sync_invoke_and_complete 		cfi
11 	GLEngine 	glGenTextures_ExecThread 		cfi
12 	XUL 	mozilla::gl::GLContext::raw_fGenTextures(int, unsigned int*) 	gfx/gl/GLContext.h:3851 	cfi
13 	XUL 	mozilla::gl::Texture::Create(mozilla::gl::GLContext&) 	gfx/gl/GLContext.h:3844 	inlined

___chkstk_darwin is the stack overflow protection kicking in.
The stack here is super interesting, and leads me to believe that the driver might be running an (llvm) interpreter fallback for point rendering here.

Also, the testcase is hitting our fake-vertex-0-array pass, or maybe it should be and it's not working.
The DrawElements is asking to draw two points from the index buffer [167, 213, ...], but the vertex shader has no attribs, no writes to gl_PointSize [1], so there's a couple things up there too.

I want to see if I can repro.

[1]: The WebGL WG decided that shaders that don't write to gl_PointSize are not supposed to render GL_POINTS anymore, but we haven't merged that change to the spec yet: https://github.com/KhronosGroup/WebGL/pull/3370

Flags: needinfo?(jgilbert)

We should try to enact the PointSize-must-be-written requirement, and see if that fixes it.
Or I guess trying the testcase with writing to PointSize, and see if it repros the same.

Assignee: bwerth → jgilbert
Severity: -- → S2
Attached file asan.txt —

Symbolized crash report from Ubuntu 22.04.

Assignee: jgilbert → egubler

I'm working on this.

Assignee: egubler → jgilbert
Depends on: 1803715

I believe I can conveniently fix this by pushing on a change to the webgl spec that's been languishing for a year, and just land it in Firefox.
I will try a patched version of nightly on a mac tomorrow.

Are there any patch plans for this issue?

Yes, I'm working on the spec side right this moment.

(+Ken from Chrome WebGL)

What's the status on this, Kelsey?

Flags: needinfo?(jgilbert)

ping ^jgilbert
When will there be an update on this case?

Hello?

Flags: needinfo?(jgilbert)
Flags: sec-bounty?

Can anyone please reply.

There seems to be a patch from "Depends on: 1803715".
ref : https://phabricator.services.mozilla.com/D163667

But still no response here. The patch didn't even apply.
When can I expect a reply on this? It's already been 4 months.

I'd like to add a disclosure deadline to prevent this from happening.

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 2023-05-06.

Hi, sorry about these delays.
I believe this is an issue in the macOS opengl driver implementation in this case, and we are running into their issue here.
We hoped we could figure out a spec workaround for this, such that we could just forbid this case. However, the WebGL WG isn't sure that the spec change we feel comfortable making in this area would prevent this issue.
Unfortunately, the fix required is pretty intricate:
In the case of draws that don't write gl_PointSize, when asked to draw POINTS, recompile the program with gl_PointSize set to some value, and from there, mirror all uniform settings to both internal programs.
We can't simply no-op all such calls, because this breaks transform feedback cases, including CTS tests, which makes it likely that it will affect content in the wild. Therefore we have to do this harder, riskier thing.

Okay, thank you for the comments.

Update - Kelsey will be looking at potential ways to address this next week.

Hi Kelsey,

When I tested with Firefox Nightly 112.0a1 you sent, I was able to confirm that this vulnerability was patched.
No crash with Firefox!

Flags: needinfo?(dlehgus1023)

Now the next thing is to do a stable release of this?
Please change the status for this!

Status: RESOLVED FIXED

Thank you for your hard work fixing this bug!

Additionally, can I get a CVE ID when this vulnerability becomes a stable release?

Flags: needinfo?(jgilbert)

Issue 1773874 seems to have been patched along with this as well.

Thanks!

The theory is:

  • The driver is running an (llvm?) interpreter fallback/work-sharer for point rendering here.
  • That implementation is not robust when asked to render points when gl_PointSize was not set.
  • Always injecting gl_PointSize initialization will prevent hitting this issue in the driver for POINTS draws.
  • The driver is likely tolerant of gl_PointSize being written even if we later draw with e.g. TRIANGLES instead of POINTS.
Flags: needinfo?(jgilbert)

Comment on attachment 9319782 [details]
Bug 1794292 - Unconditionally init gl_PointSize on Mac.

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Hard, though it's suspect, but really hard to tell why this is being done from the patch.
    There is mention in the patch that this is for working around driver issues with gl_PointSize unwritten then POINTS drawn, but not why this might cause a sec issue.
  • 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?: Easy to make.
  • How likely is this patch to cause regressions; how much testing does it need?: Unlikely, if it passes CI.
    I have triggered CI tests for my build here: https://treeherder.mozilla.org/jobs?repo=try&revision=325049c13598ab892a07512fa119bf6b135b46fd
  • Is Android affected?: No
Attachment #9319782 - Flags: sec-approval?
status-firefox110: --- → wontfix
status-firefox111: --- → affected
status-firefox112: --- → affected
status-firefox-esr102: --- → affected
OS: Unspecified → macOS

Comment on attachment 9319782 [details]
Bug 1794292 - Unconditionally init gl_PointSize on Mac.

Approved to request uplift and land

Attachment #9319782 - Flags: sec-approval? → sec-approval+
Flags: in-testsuite?

:jgilbert the final 111 beta builds on 2023-03-02. Next week is RC week.
This needs to land if it's going to make it for the 111 cycle.

Flags: needinfo?(jgilbert)

Sorry, uplift got kinda complicated with the ANGLE backout, so we're slipping 111 then.

Flags: needinfo?(jgilbert)

Hi,

Will a patch for this arrive in firefox 112?

(In reply to DoHyun Lee from comment #53)

Will a patch for this arrive in firefox 112?

That's the intention, yes.

Hi !
How long does it take to reach Stable?

DoHyun, we are currently working on getting this patch ready for uplift to Fx112, which is in Beta right now. IF we can achieve that, this fix will reach Release (which I think is what you mean by "Stable") sometime around April 11th.

Attachment #9319782 - Attachment is obsolete: true
Attachment #9326132 - Attachment is obsolete: true
Attachment #9326133 - Attachment is obsolete: true
Attachment #9326132 - Attachment is obsolete: false
Attachment #9326133 - Attachment is obsolete: false

[ANGLE] cherry-pick init-gl-point-size. r=gfx-reviewers,bradwerth
https://hg.mozilla.org/mozilla-central/rev/de9c5e6187cf
Use init-gl-point-size on mac. r=gfx-reviewers,bradwerth
https://hg.mozilla.org/mozilla-central/rev/06133fd6e358
apply code formatting via Lando
https://hg.mozilla.org/mozilla-central/rev/f4f1d9ae75f9

Group: gfx-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox113: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch

Thanks!

Please use the credits below once this vulnerability is patched in stable and assigned a CVE ID.
CREDIT: Dohyun Lee (@l33d0hyun) of SSD Secure Disclosure Labs

Summary: Firefox WebGL glvmInterpretFPTransformFour Bad-Free (Heap Corruption) Vulnerability → Firefox WebGL glvmInterpretFPTransformFour Memory Corruption Vulnerability

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-firefox112 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jgilbert)
Attachment #9326132 - Attachment description: Bug 1794292 - [ANGLE] cherry-pick init-gl-point-size. → Bug 1794292 - [beta] [ANGLE] cherry-pick init-gl-point-size.
Attachment #9326133 - Attachment description: Bug 1794292 - Use init-gl-point-size on mac. → Bug 1794292 - [beta] Use init-gl-point-size on mac.

Comment on attachment 9326121 [details]
Bug 1794292 - Use init-gl-point-size on mac.

Beta/Release Uplift Approval Request

  • User impact if declined: sec-high due to gpu driver bug on mac
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Load the POC testcase on Mac+Intel
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Medium-low. We are adding an extra injected line into every webgl shader we compile with this change. I believe the spec doesn't guarantee that what we're doing here is safe, but we're on Mac, which has fairly homogeneous drivers, and it Seems Fine (tm). Also passes CI still.

Alternatives would be very tricky tracking and handling on our side to carefully detect when this case might occur, and compile a second version of the shader to use in this bad case, and then needing to coordinate this shadow-shader with the real shader as its settings get updated. This would be a much riskier change.

  • String changes made/needed: none
  • Is Android affected?: No

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 due to gpu driver bug on mac
  • Fix Landed on Version: 113
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Medium-low. We are adding an extra injected line into every webgl shader we compile with this change. I believe the spec doesn't guarantee that what we're doing here is safe, but we're on Mac, which has fairly homogeneous drivers, and it Seems Fine (tm). Also passes CI still.

Alternatives would be very tricky tracking and handling on our side to carefully detect when this case might occur, and compile a second version of the shader to use in this bad case, and then needing to coordinate this shadow-shader with the real shader as its settings get updated. This would be a much riskier change.

Flags: needinfo?(jgilbert)
Attachment #9326121 - Flags: approval-mozilla-esr102?
Attachment #9326121 - Flags: approval-mozilla-beta?
Attachment #9326120 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9326120 [details]
Bug 1794292 - [ANGLE] cherry-pick init-gl-point-size.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined:
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
Attachment #9326120 - Flags: approval-mozilla-esr102?
Attachment #9326116 - Flags: approval-mozilla-esr102?
Attachment #9326117 - Flags: approval-mozilla-esr102?
Attachment #9326132 - Flags: approval-mozilla-esr102?
Attachment #9326133 - Flags: approval-mozilla-esr102?
Attachment #9326116 - Flags: approval-mozilla-esr102?

Comment on attachment 9326116 [details]
Bug 1794292 - [esr102] [ANGLE] cherry-pick init-gl-point-size.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined:
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
Attachment #9326116 - Flags: approval-mozilla-esr102?
Attachment #9326120 - Flags: approval-mozilla-esr102?

Comment on attachment 9326121 [details]
Bug 1794292 - Use init-gl-point-size on mac.

Beta/Release Uplift Approval Request

  • User impact if declined:
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • 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?: Yes
Attachment #9326121 - Flags: approval-mozilla-esr102?
Attachment #9326132 - Flags: approval-mozilla-esr102?
Attachment #9326132 - Attachment is obsolete: true
Attachment #9326133 - Flags: approval-mozilla-esr102?
Attachment #9326133 - Attachment is obsolete: true

I have a question for you. When this vulnerability occurred, the firefox browser process crashed. I think this is a part that can affect the sandbox. What do you think?

Flags: needinfo?(jgilbert)

No, the sandbox is fine. Crashes aren't all vulns.
Honestly I'm not totally sure this is worse than a sec-dos, because I think ___chkstk_darwin might generally be a safe crash (like always-null derefs), but I don't want to stress about it either way.
I'm not sure you could build a vuln with this issue.

Flags: needinfo?(jgilbert)

Comment on attachment 9326120 [details]
Bug 1794292 - [ANGLE] cherry-pick init-gl-point-size.

Approved for 112.0rc1

Attachment #9326120 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9326121 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9326116 [details]
Bug 1794292 - [esr102] [ANGLE] cherry-pick init-gl-point-size.

Approved for 102.10esr.

Attachment #9326116 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+
Attachment #9326117 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+
QA Whiteboard: [qa-triaged]

Seems like the browser keeps crashing instantly for me while loading the poc.html file into Firefox 112.0b9 and Firefox 113.0a1 (2023-04-02) on macOS 13.3 (Intel system). One thing that I noticed is that if I keep the macbook connected to the external display (forces the AMD gpu to work) it will not crash with the poc even on the affected build (107.0a1). If the display is disconnected and the Intel gpu is used, the crash occurs instantly when loading the poc file.

This is the report that I get after the crash: https://crash-stats.mozilla.org/report/index/ad6aad01-1378-407e-9c45-073210230403#tab-details. Any idea why is this happening ?

Flags: needinfo?(jgilbert)

Yes, that's bug 1773874.

Flags: needinfo?(jgilbert)

We tried reproducing/verifying the initial issue but had no luck in doing so on two different systems:

  1. Macbook Pro 16" 2019 Intel - macOS 13.3
  1. Apple M1 mac Mini - macOS 13.2

Dohyun, could you please verify the fix on Nightly, RC and ESR builds? Thank you!

Flags: qe-verify+
Flags: needinfo?(jgilbert)
Flags: needinfo?(dohyunl)
Whiteboard: [post-critsmash-triage]

Are the angle changes going to be upstreamed?

Flags: sec-bounty? → sec-bounty+
See Also: → CVE-2023-4582
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main112+]
Whiteboard: [post-critsmash-triage][adv-main112+] → [post-critsmash-triage][adv-main112+][adv-esr102.10+]
Attached file advisory.txt —

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

I agree that it looks like likely multiple issues here. I'm going to focus on the Mac issue posted in the original post.

Also, I wanted to follow up and see if the other issues references got their own bug reports.

Hi tom,

Can you use the credit below?
CREDIT : Dohyun Lee (@l33d0hyun) of SecuriTeam Secure Disclosure Labs

Alias: CVE-2023-29531
See Also: → CVE-2023-6856
Flags: needinfo?(jgilbert)
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: