Bug 1328762 (CVE-2017-5031)

Invalid read @ libGLESv2.dll!rx::Image11::disassociateStorage() | Assertion failure: !err

RESOLVED FIXED

Status

()

RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: bc, Assigned: jgilbert)

Tracking

(Blocks: 1 bug, 6 keywords)

51 Branch
assertion, crash, csectype-uaf, regression, regressionwindow-wanted, sec-critical
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr45 unaffected, firefox-esr5253+ fixed, firefox53+ fixed, firefox54+ fixed, firefox55 unaffected)

Details

(Whiteboard: [adv-main53.0.2+][adv-esr52.1.1+], crash signature, URL)

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
Windows 7 32bit show a EXCEPTION_ACCESS_VIOLATION_READ crash rated high exploitable on 

https://sketchfab.com/models/7346263a68554cb3b536a872d5868374
https://sketchfab.com/models/9958172a6fd74610922a3a5fcb3e0850

Both Windows 7 and 10 32bit also show OOM crashes so you may need to work at it to get the actual Angle crash.

I also see the following on 32bit Windows.

Assertion failure: !err, at c:/builds/moz2_slave/m-beta-w32-d-00000000000000000/build/src/dom/canvas/WebGLContextDraw.cpp:739

The stacks for the assertions are short, symbol-less and pretty useless.

Nightly/53 Linux 64bit showed a nullptr crash

Operating system: Linux
                  0.0.0 Linux 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 23:10:23 UTC 2016 x86_64
CPU: amd64
     family 6 model 45 stepping 2
     2 CPUs

GPU: UNKNOWN

Crash reason:  SIGSEGV
Crash address: 0x0
Process uptime: not available

Thread 0 (crashed)
 0  libxul.so!mozilla::WebGLTexture::TexImage [WebGLTextureUpload.cpp:45f796204c54 : 1303 + 0x24]
    rax = 0x0000000000000000   rdx = 0x0000000000000000
    rcx = 0x0000000000000b40   rbx = 0x00007f050f1d0000
    rsi = 0x00007f0546f43730   rdi = 0x00007f0538bc5b8a
    rbp = 0x00007ffca2ceae00   rsp = 0x00007ffca2cead50
     r8 = 0x00007f0546f43730    r9 = 0x00007f0548020740
    r10 = 0x0000000000000073   r11 = 0x0000000000000000
    r12 = 0x00007f050f1c9c80   r13 = 0x00007ffca2ceafb5
    r14 = 0x00007ffca2cead88   r15 = 0x00007f050f1935a8
    rip = 0x00007f05368aac97
Group: core-security → gfx-core-security
Keywords: csectype-nullptr
I could not reproduce with Win7 32-bit Firefox Beta (51) or Release (50.0). Given you mention an assert I guess you're running a debug build?

Raymond: any luck getting ASAN Windows builds? If so please try the links in comment 0
Possibly related to bug 1325511? Have no idea if "Buffer11" storage is related to "Image11" storage. Is "11" a thing, or just a version number?
It's DirectX 11, so it's always going to be that (sort of), and could be related to bug 1325511.
needinfo raymond for comment 1
Flags: needinfo?(rforbes)
So far I have not seen a crash. However, we build ASAN windows in 64 bit as 32 bit doesn't really work.
Flags: needinfo?(rforbes)
Hi Bob, are you able to reproduce this anymore?
Flags: needinfo?(bob)
(Reporter)

Comment 7

2 years ago
Yes. I re-submitted the over 100 sketchfab urls and reproduced pretty much the same set of behaviors. This site does cause *lots* of OOM errors on 32bit but for whatever reason *sometimes* it causes us to fall down and...

exploitable high:
rx::Image11::disassociateStorage rx::Image11::redefine rx::TextureD3D_2D::redefineImage rx::TextureD3D_2D::initMipmapImages rx::TextureD3D::generateMipmap EXCEPTION_ACCESS_VIOLATION_READ	0xffffffffe5e5e621

7 times on 32bit Windows 7.

https://sketchfab.com/models/3109e582b2bd4f689ea682a9abca4e41 beta/aurora/nightly

https://sketchfab.com/models/3a6d61475d8349f7b2cd84127d8b2129 beta

https://sketchfab.com/models/434d0a895c31481a8a6fb84adfbec0c1 aurora

plus the standard Assertion failure: !err and WebGL related crashes and assertions.

Note: I tried to spider the site from my Fedora 25 4.10.5 workstation and locked up the user interface pretty hard.
Flags: needinfo?(bob)
(Reporter)

Comment 8

2 years ago
Created attachment 8852723 [details]
example log output
(Reporter)

Comment 9

2 years ago
Created attachment 8852724 [details]
example crash report with eax = 0xe5e5e5e5
Milan, do you know of somebody who could look into this? Thanks.
Flags: needinfo?(milan)
Keywords: csectype-uaf, sec-critical
Tracking for 53 since this is sec-critical.
status-firefox53: --- → affected
status-firefox54: --- → ?
status-firefox55: --- → ?
status-firefox-esr52: --- → ?
tracking-firefox53: --- → +
Jeff, is this covered by any of the outstanding ANGLE patches?
Flags: needinfo?(milan) → needinfo?(jgilbert)
Milan, anyone else who can poke around in ANGLE and have a look here? 
I'll keep this tracked and marked as affected for 53 in case we end up with a 53 dot release.
Flags: needinfo?(milan)
We are updating to ANGLE as we speak, we should check this once we have that update.
Flags: needinfo?(milan)
Flags: needinfo?(jgilbert)
Chatted with Milan, sounds like this change in ANGLE will be riding with 55.
status-firefox53: affected → wontfix
status-firefox54: ? → wontfix
status-firefox55: ? → affected
It seems only bc managed to reproduce. Can you re-test in nightly to verify whether this is indeed fixed by the ANGLE work as Milan suggested, Bob?
Flags: needinfo?(bob)
(Reporter)

Comment 17

2 years ago
I tested the 200+ sketchfab urls on Fedora 25, Ubuntu 16.04 64bit, Windows 7, 10 32bit and 64bit on Beta/54 and Nightly/55.

I found 2 crashes on window 7 32bit beta/54 opt

rx::Image11::disassociateStorage rx::Image11::redefine rx::TextureD3D_2D::redefineImage rx::TextureD3D_2D::initMipmapImages rx::TextureD3D::generateMipmap

That were rated high exploitable. I did not reproduce this on nightly/55 however.

I also saw lots of mozalloc_abort | mozalloc_handle_oom | moz_xmalloc std::_Allocate std::vector<unsigned char, std::allocator<unsigned char> >::_Reallocate rx::d3d11::GenerateInitialTextureData rx::Image11::createStagingTexture 

on beta opt Windows 7 and 10 32bit.

ucrtbase.dll ucrtbase.dll ucrtbase.dll ucrtbase.dll rx::Image11::createStagingTexture

on beta debug and nightly Windows 7 32bit.

and one beta debug windows 7 ucrtbase.dll ucrtbase.dll ucrtbase.dll ucrtbase.dll rx::UniformStorage11::UniformStorage11

I didn't see any other exploitable rated crashes with the sketchfab urls.

Looks like the Angle update resolved this. I'll let you resolve the bug how you like.
Flags: needinfo?(bob)
(Reporter)

Comment 18

2 years ago
Have we been outed by Chrome's fix: https://www.us-cert.gov/ncas/bulletins/SB17-121 	CVE-2017-5031
(In reply to Bob Clary [:bc:] from comment #18)
> Have we been outed by Chrome's fix:
> https://www.us-cert.gov/ncas/bulletins/SB17-121 	CVE-2017-5031

Liz, Daniel, do we need a chemspill or some such?
Flags: needinfo?(lhenry)
Flags: needinfo?(dveditz)
For what it is worth, the Chrome bug is public and has a test case, so somebody could see what that does in Firefox: https://bugs.chromium.org/p/chromium/issues/detail?id=682020
(In reply to Andrew McCreight [:mccr8] from comment #20)
> For what it is worth, the Chrome bug is public and has a test case, so
> somebody could see what that does in Firefox:
> https://bugs.chromium.org/p/chromium/issues/detail?id=682020

Though the patch is in Windows code, so it would require a working Windows ASan build.
We can be ready for chemspill or to include a fix in a dot release, once we have a patch here. 
Do you want to try updating ANGLE, or try to cherry pick a fix ?
Flags: needinfo?(lhenry) → needinfo?(milan)
Started a conversation with :jgilbert, we'll continue it in here.  For cherry picking, it may help us to know which Google bug fixed it, so that it can lead us to a patch, instead of trying to reverse engineer it.
Flags: needinfo?(milan) → needinfo?(jgilbert)
(In reply to Milan Sreckovic [:milan] from comment #23)
> Started a conversation with :jgilbert, we'll continue it in here.  For
> cherry picking, it may help us to know which Google bug fixed it, so that it
> can lead us to a patch, instead of trying to reverse engineer it.

As I posted in comment 20, the Chrome bug for the CVE number Bob posted in comment 18 is here and is public:
  https://bugs.chromium.org/p/chromium/issues/detail?id=682020
Looking at the Chrome bug, Looben Yang says he submitted this to us as bug 1325511, which was fixed back to 52.

Bob, can you see if you can still reproduce this issue? It might be something else.
Flags: needinfo?(bob)
Non-withstanding the CVE numbers that are different, worth a try.
Sounds like we aren't sure if 53/54 are still affected here.
status-firefox53: wontfix → ?
status-firefox54: wontfix → ?
(Assignee)

Comment 28

2 years ago
Our previous fix from bug 1325511 is still in Beta54. I'll take a closer look.

Marking 55 as 'unaffected', 54 as 'affected' based on comment #17. 53 is still 'unknown'.
Assignee: nobody → jgilbert
status-firefox54: ? → affected
status-firefox55: affected → unaffected
Flags: needinfo?(jgilbert)
See Also: → bug 1325511
(Assignee)

Comment 29

2 years ago
I don't like their solution here, but I'm not going to fight upstream about it. Let's just take their fix.
(Assignee)

Comment 30

2 years ago
Created attachment 8864318 [details] [diff] [review]
0001-Bug-1328762-Cherry-pick-ANGLE-a4aaa2de57dc51243da35e.patch

Approval Request Comment
[Feature/Bug causing the regression]: upstream regression
[User impact if declined]: sec-crit
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: Sure. POC repro is posted in the upstream bug.
[List of other uplifts needed for the feature/fix]: beta54, release53, esr52
[Is the change risky?]: no
[Why is the change risky/not risky?]: cherry-pick from upstream
[String changes made/needed]: none
Attachment #8864318 - Flags: approval-mozilla-release?
Attachment #8864318 - Flags: approval-mozilla-esr52?
Attachment #8864318 - Flags: approval-mozilla-beta?
(Reporter)

Comment 31

2 years ago
I wasn't able to reproduce any asan errors on Windows with a current nightly build. Beta is not available.
Flags: needinfo?(bob)
(Assignee)

Comment 32

2 years ago
Comment on attachment 8864318 [details] [diff] [review]
0001-Bug-1328762-Cherry-pick-ANGLE-a4aaa2de57dc51243da35e.patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
no

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Yes, upstream bug is public and includes a repro case.

Which older supported branches are affected by this flaw?
beta54, release53, esr52

If not all supported branches, which bug introduced the flaw?
upstream regression

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
have backports

How likely is this patch to cause regressions; how much testing does it need?
unlikely
Attachment #8864318 - Flags: sec-approval?
status-firefox53: ? → affected
status-firefox-esr52: ? → affected
tracking-firefox54: --- → ?
tracking-firefox-esr52: --- → ?
Alias: CVE-2017-5031
Flags: needinfo?(dveditz)
Comment on attachment 8864318 [details] [diff] [review]
0001-Bug-1328762-Cherry-pick-ANGLE-a4aaa2de57dc51243da35e.patch

Review of attachment 8864318 [details] [diff] [review]:
-----------------------------------------------------------------

sec-approval=dveditz

I'll let release drivers approve for release/ESR-52
Attachment #8864318 - Flags: sec-approval?
Attachment #8864318 - Flags: sec-approval+
Attachment #8864318 - Flags: approval-mozilla-beta?
Attachment #8864318 - Flags: approval-mozilla-beta+
Comment on attachment 8864318 [details] [diff] [review]
0001-Bug-1328762-Cherry-pick-ANGLE-a4aaa2de57dc51243da35e.patch

OK, let's get this on release, beta, and esr52 today. This is the main driver for the 53.0.1 desktop release and for 52.1.1 esr. This can also make the 54 beta 5 build later tonight, I think.
Attachment #8864318 - Flags: approval-mozilla-release?
Attachment #8864318 - Flags: approval-mozilla-release+
Attachment #8864318 - Flags: approval-mozilla-esr52?
Attachment #8864318 - Flags: approval-mozilla-esr52+
https://hg.mozilla.org/releases/mozilla-release/rev/d764f41b23b8

https://hg.mozilla.org/releases/mozilla-esr52/rev/bd4fcdee9a06 (FIREFOX_ESR_52_1_X_RELBRANCH - 52.1.1)
https://hg.mozilla.org/releases/mozilla-esr52/rev/238095c19891 (default - 52.2.0)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox53: affected → fixed
status-firefox-esr52: affected → fixed
Resolution: --- → FIXED
Since bug 1325511 didn't apply to ESR-45 I assume this one does not either.
status-firefox-esr45: --- → unaffected
Keywords: regression, regressionwindow-wanted
Group: gfx-core-security → core-security-release
Is this bad enough we should try to release a new aurora54 build with this fix?
We were unable to reproduce the crash on Windows 7, Windows 10 and Ubuntu 16.04. We tried replicating it using both the instructions from Comment 0 and the test case from Comment 20, with no success.

We cannot confirm if this bug is fixed on 52.1.1esr-build1 or 53.0.2-build1.
tracking-firefox54: ? → +
tracking-firefox-esr52: ? → 53+
(Reporter)

Comment 40

2 years ago
I would just to point out that Looben Yang reported the issue to Chrome on Jan 17 while this bug was reported on Jan 4.
(In reply to Julien Cristau [:jcristau] from comment #38)
> Is this bad enough we should try to release a new aurora54 build with this
> fix?
Flags: needinfo?(rkothari)
Flags: needinfo?(dveditz)
From talking with Dan and Jeff the other day, no, as the vulnerability reported was partially fixed already and what was left wasn't sec-critical.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #41)
> (In reply to Julien Cristau [:jcristau] from comment #38)
> > Is this bad enough we should try to release a new aurora54 build with this
> > fix?

We discussed this at the Dawn project coordination meeting today. Like Liz said the severity doesn't warrant a chemspill situation.
Flags: needinfo?(rkothari)
Flags: needinfo?(dveditz)
(In reply to Bob Clary [:bc:] from comment #40)
> I would just to point out that Looben Yang reported the issue to Chrome on
> Jan 17 while this bug was reported on Jan 4.

He was really reporting bug 1325511 (from December) to Chrome: see bug 1325511 comment 15, 18. Their resulting fix covered this case too whereas ours did not.
Whiteboard: [adv-main53.0.3+][adv-esr52.1.1+]
Whiteboard: [adv-main53.0.3+][adv-esr52.1.1+] → [adv-main53.0.2+][adv-esr52.1.1+]
(Reporter)

Comment 45

2 years ago
Created attachment 8888403 [details]
crash report + log

During a retest of urls which have crashed in Bughunter since July 1, this crash was reproduced on Windows 7 32bit with build rv:56.0 20170719173022 on url:

https://sketchfab.com/models/67b90d3c88e244dc90917f46ef7ff9c5

exploitable rated this as high which fits with Crash address: 0xffffffffe5e5e621 and eax = 0xe5e5e5e5.

I would say this is the same as the original crash and this *isn't* fixed.

This is the only example I've seen so far but the retest is still ongoing.
Flags: needinfo?(dveditz)
(Reporter)

Updated

2 years ago
Blocks: 1382851
See Also: → bug 1382851
(Reporter)

Comment 46

2 years ago
Per conversation with dveditz, I bug 1382851 to track this.
Flags: needinfo?(dveditz)
Group: core-security-release
Keywords: csectype-nullptr
You need to log in before you can comment on or make changes to this bug.