1826002 - (CVE-2023-37201) Use-after-free on freebl3!SHA256_Update_Native at sha256-x86.c on OOM

Status: VERIFIED FIXED

(Core :: WebRTC, defect)

Description

[Irvan Kurniawan (:sourc7)]

Attachment: testcase1.html

On Firefox 32-bit after filling memory around 2700mb, then call new RTCPeerConnection() and new Worker the tab able to crash at ACCESS_VIOLATION_READ on SHA256_Update_Native at sha256-x86.c on address 0xe5e5e5e5, the address can be changed dynamically to e.g. 0xe5eff000, 0xe5f0000, 0xe6901000, and more.

The testcase is currently intermittent, it commonly crash at mozalloc_abort breakpoint rather than SHA256_Update_Native, I'll post update when I found more reliable testcase.

After spent some time debugging through WinDbg, on the stack PeerConnectionImpl::SetCertificate(mozilla::dom::RTCCertificate& aCertificate) the aCertificate->mCertificate sub-variable e.g. extensions, emailAddr, keyUsage, derCert, and more value is already set at 0xe5e5e5e5, then that mCertificate is passed to SHA256_Update_Native causing the ACCESS_VIOLATION_READ.

When looking at RTCCertificate.cpp code, it looks like the code is called from another thread, on the WebCryptoTask::Run() there are code comment "// Run heavy crypto operations on the thread pool, off the original thread.".

I then add printf to print address of mCertificate from RTCCertificate!SignCertificate and PeerConnectionImpl::SetCertificate to match the address, when calling simple function new RTCPeerConnection() both mCertificate address is match, but when visiting the testcase which do repeatedly in loop, the mCertificate address is out of sync, it looks like the RTCCertificate is generate too excessive mCertificate, then older mCertificate is freed, after that the PeerConnectionImpl::SetCertificate is still taking the old (freed) mCertificate address rather than fresh mCertificate which causing the use-after-free.

Tested on:

• Firefox 113.0a1 (2023-04-01) (32-bit)
• Firefox 111.0.1 (32-bit)

Steps to reproduce:

1. Open Firefox 32-bit
2. Visit attached testcase1.html on HTTPS site
3. After a while the tabs is crashed
4. Analyze the crash dump

If Firefox crash at EXCEPTION_BREAKPOINT, try again until it crashes at EXCEPTION_ACCESS_VIOLATION.

Comment 1

[Irvan Kurniawan (:sourc7)]

Attachment: minidump_0xe5e5e5e5.txt

Comment 2

[Irvan Kurniawan (:sourc7)]

Attachment: minidump_0x61313736.txt

Comment 3

[Daniel Veditz [:dveditz]]

We're going to try to reproduce in an instrumented build and figure out whether to blame NSS or WebRTC. The testcase is relying on OOM situations which would make it hard to create a reliable exploit out of. We can raise the severity if we figure out how to do that

Comment 4

[Tyson Smith [:tsmith]]

I haven't been able to trigger the issue locally with a 32-bit ASan build on Linux. Unfortunately all I've been able to trigger are OOMs.

Comment 5

[Irvan Kurniawan (:sourc7)]

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

figure out whether to blame NSS or WebRTC.

I've added some logging code to my Firefox, on RTCCertificate.cpp which responsible to generate new RTC client certificate and dtlsidentity.cpp which use the generated client certificate then pass this to HASH_HashBuf.

On single call of new RTCPeerConnection() function, the dtlsidentity.cpp is using the properly generated certificate (mCertificate address generated by RTCCertificate.cpp is same as cert address used by dtlsidentity.cpp) the log is as follow:

1 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: 05350810
2 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 330
3 dtlsidentity.cpp->ComputeFingerprint cert address -> 05350810
4 dtlsidentity.cpp->ComputeFingerprint cert->derCert.len 330

After the RTCCertificate generate the certificate then dtlsidentity directly uses the generated mCertificate

However when running the testcase, it can be seen that dtlsidentity.cpp is using the old (freed) mCertificate as the following summary (full log can be seen at attachment uaf-rtccertificate-dtlsidentity-log.txt):

1 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: 05351010
2 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 331
3 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: 05351810
4 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 330
5 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: 0AFA9010
6 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 331
...
232 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: FFE6D010 <- freed address 
233 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 330 <- len is 330
...
345 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: FFEDD810
346 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 329
347 RTCCertificate.cpp->SignCertificate() Address of mCertificate object: FFEDF010
348 dtlsidentity.cpp->ComputeFingerprint cert address -> FFE6D010 <- use of freed address
349 dtlsidentity.cpp->ComputeFingerprint cert->derCert.len -437918235 <- len from freed address how minus
350 RTCCertificate.cpp->SignCertificate() mCertificate->derCert.len = 329

From line 1 in this case the RTCCertificate generate a lot of certificate, but when dtlsidentity not yet using the mCertificate, the RTCCertificate keep generating the mCertificate.

On line 348 it show that the dtlsidentity is using mCertificate from line 232 which has been freed, the value of cert->derCert.len is showing minus value -437918235 (instead of 330) which indicate the UAF.

If I added new logging code e.g. cert->emailAddr below of logging the cert->derCert.len it also able to trigger the UAF.

Comment 6

[Irvan Kurniawan (:sourc7)]

Attachment: logging.patch

Comment 7

[Irvan Kurniawan (:sourc7)]

Attachment: rtccertificate-dtlsidentity-uaf-log.txt

Comment 8

[Irvan Kurniawan (:sourc7)]

The reason RTCCertificate re-generate certificates, when dtlsidentity has not used it, probably because RTCCertificate is running on another thread than dtlsidentity.

Comment 9

[Irvan Kurniawan (:sourc7)]

I've found more reliable testcase than the testcase1.html, but still testing across my machine to confirm is more reliable on them, I will attach that later.

I also able to reproduce this on Linux OS and Firefox ESR 102.9.0esr (32-bit), when run this on mozregression I able to reproduce this since build 2020-02-14.

I tried to compile Firefox build_date 2020-02-14 on Windows 11 to find out the regression, but latest Windows clang-cl (from mach bootstrap) is causing error on older build, try to find out older clang-cl (2020) from Mozilla archive, but couldn't find one. Fortunately I also reproduced this on Linux OS, compiling old Firefox looks easier on Linux, which I have done before, I'll try compile older version on Linux to find out the regression.

Comment 10

[Irvan Kurniawan (:sourc7)]

(In reply to Irvan Kurniawan (:sourc7) from comment #9)

when run this on mozregression I able to reproduce this since build 2020-02-14.

On Linux OS I was also able to reproduce this on build 2019-12-18, and looks like still possible on earlier date builds, looks like UAF is possible since the code has been committed.

I'll share more reliable testcase instead.

Comment 11

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

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

For more information, please visit auto_nag documentation.

Comment 12

[Byron Campen [:bwc]]

I'm having no luck reproducing this either with an ASan build. Any progress on the more reliable testcase you're working on?

Comment 13

[Irvan Kurniawan (:sourc7)]

(In reply to Byron Campen [:bwc] from comment #12)

I'm having no luck reproducing this either with an ASan build. Any progress on the more reliable testcase you're working on?

I do get the more reliable testcase, when running the testcase for 20 times, the success rate is about 40% - 50% to hit the UAF, but I've tested that on Firefox Nightly, after next Firefox Nightly update the success rate is drop to 20% - 30%. The trick is adding slowdown code or DOM code above new RTCPeerConnection() able to increase the success rate.

It looks like it is also reproducible on Firefox on Windows 64-bit, I able to get following UAF crash stack:

r10 = 0x00000fff1e06c9fe        r11 = 0x5401401401504104        r12 = 0x0000000000000086
r13 = 0x0000000000000378        r14 = 0x0000020dbb982000        r15 = 0x0000000000000128
 r8 = 0x000000f0c89fe3a8         r9 = 0x0000020dbb982000        rax = 0x0000000000000000
rbp = 0x0000000000000195        rbx = 0x0000000000000128        rcx = 0xe5e5e5e5e5e5e5e5
rdi = 0xe5e5e5e5e5e5e5e5        rdx = 0x000002103b45b790        rip = 0x00007ff8f4d3dd77
rsi = 0x000002103b45b790        rsp = 0x000000f0c89fe170
OS|Windows NT|10.0.22621
CPU|amd64|family 6 model 183 stepping 1|32
Crash|EXCEPTION_ACCESS_VIOLATION_READ|0xe5e5e5e5e5e5e61d|0
0|0|nss3.dll|nssCertificate_Destroy(NSSCertificateStr*)|hg:hg.mozilla.org/mozilla-central:security/nss/lib/pki/certificate.c:25209607dc0b253635ead03eff51fdc10a62e659|97|0x17
0|1|xul.dll|mozilla::dom::RTCCertificate::~RTCCertificate()|hg:hg.mozilla.org/mozilla-central:dom/media/webrtc/RTCCertificate.h:25209607dc0b253635ead03eff51fdc10a62e659|79|0x15
0|2|xul.dll|mozilla::dom::RTCCertificate::cycleCollection::DeleteCycleCollectable(void*)|hg:hg.mozilla.org/mozilla-central:dom/media/webrtc/RTCCertificate.h:25209607dc0b253635ead03eff51fdc10a62e659|47|0xf
0|3|xul.dll|nsPurpleBuffer::VisitEntries<SnowWhiteKiller>(SnowWhiteKiller&)|hg:hg.mozilla.org/mozilla-central:xpcom/base/nsCycleCollector.cpp:25209607dc0b253635ead03eff51fdc10a62e659|969|0xca9
0|4|xul.dll|nsCycleCollector::FreeSnowWhiteWithBudget(js::SliceBudget&)|hg:hg.mozilla.org/mozilla-central:xpcom/base/nsCycleCollector.cpp:25209607dc0b253635ead03eff51fdc10a62e659|2679|0x11f
WARNING: Hit stack size output limit!

And following nss3.dll crash stack:

r10 = 0x0000000000000116        r11 = 0x00007ffaeccb1b61        r12 = 0x0000000000000000
r13 = 0x00000244e457a0d0        r14 = 0x00000247a47d7cc8        r15 = 0x0000000000000000
 r8 = 0x0000000000000000         r9 = 0x000000ca3f83f060        rax = 0x0000000000000006
rbp = 0x0000000000000116        rbx = 0x00000000000000ef        rcx = 0x00000000000000c8
rdi = 0x0000000000000000        rdx = 0x00007ffae3bd4a44        rip = 0x00007ffae3bd3670
rsi = 0x0000000000000000        rsp = 0x000000ca3f83f030
OS|Windows NT|10.0.22621
CPU|amd64|family 6 model 183 stepping 1|16
Crash|EXCEPTION_ACCESS_VIOLATION_READ|0x0000000000000008|8
8|0|nss3.dll|sgn_NewContext(<unnamed-tag>, SECItemStr*, SECKEYPrivateKeyStr*)|hg:hg.mozilla.org/mozilla-central:security/nss/lib/cryptohi/secsign.c:faf51404785d5440c5ce9b38d9b5828f8f1cd5df|55|0x50
8|1|nss3.dll|sec_SignData(SECItemStr*, unsigned char const*, int, SECKEYPrivateKeyStr*, <unnamed-tag>, SECItemStr*)|hg:hg.mozilla.org/mozilla-central:security/nss/lib/cryptohi/secsign.c:faf51404785d5440c5ce9b38d9b5828f8f1cd5df|312|0x22
8|2|nss3.dll|sec_DerSignData(PLArenaPool*, SECItemStr*, unsigned char const*, int, SECKEYPrivateKeyStr*, <unnamed-tag>, SECItemStr*)|hg:hg.mozilla.org/mozilla-central:security/nss/lib/cryptohi/secsign.c:faf51404785d5440c5ce9b38d9b5828f8f1cd5df|428|0x78
8|3|nss3.dll|SEC_DerSignData(PLArenaPool*, SECItemStr*, unsigned char const*, int, SECKEYPrivateKeyStr*, <unnamed-tag>)|hg:hg.mozilla.org/mozilla-central:security/nss/lib/cryptohi/secsign.c:faf51404785d5440c5ce9b38d9b5828f8f1cd5df|456|0x25
8|4|xul.dll||||
WARNING: Hit stack size output limit!

I'll try reproduce more on Firefox ASAN 64-bit, hopefully able to get the UAF stack trace.

Comment 14

[Irvan Kurniawan (:sourc7)]

Attachment: minidump_uaf_64bit.txt

It possible to hit the UAF on SHA256_Update_Native and AV_WRITE NSC_GenerateKeyPair -> ECDH_Derive on Firefox Nightly 115.0a1 (2023-05-26) (64-bit).

Comment 15

[Irvan Kurniawan (:sourc7)]

Attachment: minidump_ECDH_Derive_memcpy.txt

Comment 16

[Irvan Kurniawan (:sourc7)]

Ok great! I finally found the use-after-free root cause, the free is occurred on NSS code, then RTCCertificate.cpp pass the freed certificate to dtlsidentity.cpp. I'll post more detail soon!

Comment 17

[Irvan Kurniawan (:sourc7)]

When user run JS new RTCPeerConnection() function, the RTCCertificate.cpp will run GenerateRTCCertificateTask::GenerateCertificate() and GenerateRTCCertificateTask::SignCertificate().

After that, RTCCertificate.cpp will call GenerateRTCCertificateTask::Resolve() to CERT_DupCertificate using generated certificate from GenerateCertificate() and SignCertificate(), then after it duplicated, it will pass the certificate to webrtc/jsapi/PeerConnectionImpl.cpp PeerConnectionImpl::SetCertificate and webrtc/transport/dtlsidentity.cpp DtlsIdentity::ComputeFingerprint.

When GenerateRTCCertificateTask::Resolve() run CERT_DupCertificate(mCertificate.get()) it will go to STAN_GetNSSCertificate(CERTCertificate *cc) -> nssPKIObject_Create -> PR_NewMonitor()

On OOM scenario, when PR_NewMonitor() run mon = PR_NEWZAP(PRMonitor); the mon will be set to NULL, causing to run PR_SetError(PR_OUT_OF_MEMORY_ERROR, 0); and return NULL;

On the nssPKIObject_Create as PR_OUT_OF_MEMORY_ERROR it will run goto loser; then free certificate arena with nssArena_Release(arena, mark);

On the STAN_GetNSSCertificate(CERTCertificate *cc) the pkiob will set to NULL causing to free the certificate arena with nssArena_Destroy(arena); and return NULL;

After that, the CERT_DupCertificate will return the certificate with freed arena, then GenerateRTCCertificateTask::Resolve will pass the certificate with freed arena to PeerConnectionImpl::SetCertificate and DtlsIdentity::ComputeFingerprint causing the use-after-free.

Comment 18

[Irvan Kurniawan (:sourc7)]

Attachment: nssarena_destroy_trigger_uaf.diff

To trigger same UAF scenario as comment 17, we can add the following code to pki3hack.c:

diff --git a/security/nss/lib/pki/pki3hack.c b/security/nss/lib/pki/pki3hack.c
index 5556cd17695f..5d6271120924 100644
--- a/security/nss/lib/pki/pki3hack.c
+++ b/security/nss/lib/pki/pki3hack.c
@@ -1047,6 +1047,8 @@ STAN_GetNSSCertificate(CERTCertificate *cc)
     NSSITEM_FROM_SECITEM(&c->encoding, &cc->derCert);
     c->type = NSSCertificateType_PKIX;
     pkiob = nssPKIObject_Create(arena, NULL, cc->dbhandle, NULL, nssPKIMonitor);
+    nssArena_Destroy(arena);
+    return NULL;
     if (!pkiob) {
         nssArena_Destroy(arena);
         return NULL;

After Firefox was compiled (more useful with AddressSanitizer enabled), go to https://www.example.com, then open web console (Ctrl+Shift+K), after that type new RTCPeerConnection() then press enter.

Comment 19

[Irvan Kurniawan (:sourc7)]

Attachment: asan-heap-uaf-read-8.txt

Comment 20

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

This is an NSS bug, then, but note that the webRTC code should be audited for places where the result of CERT_DupCertificate isn't null-checked.

Comment 21

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Discussed this with the team. There are NSS issues here, but the most expedient fix for Firefox will be to change how we're using CERT_CreateCertificate in this code.

Comment 22

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Does this patch address the issue for you?
https://hg.mozilla.org/try/rev/f5b661d1ed080c63e48cadb8650259841fc5e221

Comment 23

[Irvan Kurniawan (:sourc7)]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #22)

Does this patch address the issue for you?
https://hg.mozilla.org/try/rev/f5b661d1ed080c63e48cadb8650259841fc5e221

Thanks for the patch! I've applied the patch on my Firefox 32-bit local build on Windows 11 and Arch Linux, after Firefox 32-bit was build, I then try with various new RTCPeerConnection() testcase repeatedly multiple times, I confirm I no longer receive crash on SHA256_Update_Native.

Comment 24

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Attachment: Bug 1826002 - use decoded certificates r?jschanck!

Comment 25

[Ryan VanderMeulen [:RyanVM]]

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

Looks like this grafts cleanly to Beta and most of the way to ESR102 (though it would probably be good to sanity check that one).

Comment 26

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

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

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

For more information, please visit BugBot documentation.

Comment 27

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Comment on attachment 9338295 [details]
Bug 1826002 - use decoded certificates r?jschanck!

Beta/Release Uplift Approval Request

• User impact if declined: UAF under high memory pressure conditions.
• 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): The changes in the patch are minimal; the only real difference is the use of an NSS function that is already widely used (CERT_NewTempCertificate). This should be safe.
• String changes made/needed: none
• Is Android affected?: Yes

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Though this is a sec-moderate and is unlikely to be reliably exploitable, it is a UAF and the fix is fairly straightforward.
• User impact if declined: UAF under high memory pressure conditions.
• Fix Landed on Version: 116
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The changes in the patch are minimal; the only real difference is the use of an NSS function that is already widely used (CERT_NewTempCertificate). This should be safe.

Comment 28

[Donal Meehan [:dmeehan]]

Comment on attachment 9338295 [details]
Bug 1826002 - use decoded certificates r?jschanck!

Approved for 115.0b5.

Comment 29

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1617cf9288b5

Comment 30

[Daniel Veditz [:dveditz]]

25-50% reliability for the PoC (comment 13), not to mention working on 64-bit, is good enough to prove my sec-moderate was too low

Comment 31

[Camelia Badau [:cbadau], Desktop QA]

Noticed in Comment 27, that Manual QE is needed for verifying this. Can we use the STR from the Description and the attached "testcase1.html" for our verification? Or is there another testcase available that we should use?

Comment 32

[Donal Meehan [:dmeehan]]

:keeler could you attach a patch based on esr102?

Comment 33

[Irvan Kurniawan (:sourc7)]

Attachment: testcase2.html

(In reply to Camelia Badau [:cbadau], Desktop QA from comment #31)

Noticed in Comment 27, that Manual QE is needed for verifying this. Can we use the STR from the Description and the attached "testcase1.html" for our verification? Or is there another testcase available that we should use?

The current attached testcase1.html is using new Worker to help fill the memory, on latest Firefox it now hitting JS assertion and worker limit assertion.

On new attached testcase2.html it's now using retry fill method and no longer using new Worker to fill the memory, however the success rate is not 100% to hit access-violation on SHA256, so we can use FFPuppet to automate retry the testcase2.html, when run 20x on my i5-1035G1 I able to get 9x success, 11x failure (about 45% success rate), on my other machine it only get 5x success, however I think it's enough for QE testing to prove the fix.

Steps to reproduce:

1. Run pip install ffpuppet in PowerShell
2. Download attached testcase2.html
3. Make new directory and enter the directory
4. Type for ($i = 1; $i -le 20; $i++) { python -m ffpuppet "[firefox path]" -u "[path to testcase file]" } on PowerShell
5. Change [firefox path] to Firefox 32-bit path i.e. C:/Program Files (x86)/Firefox/firefox.exe
6. Change [path to testcase file] to testcase2.html path i.e. C:/tmp/testcase2.html
7. Run the command
8. After the command is completed, find "SHA256" text in the folder
9. If "SHA256" text is found, then the Firefox build is affected

Comment 34

[Bogdan Maris, Desktop QA]

(In reply to Irvan Kurniawan (:sourc7) from comment #33)

Created attachment 9340705 [details]
testcase2.html

(In reply to Camelia Badau [:cbadau], Desktop QA from comment #31)

Noticed in Comment 27, that Manual QE is needed for verifying this. Can we use the STR from the Description and the attached "testcase1.html" for our verification? Or is there another testcase available that we should use?

The current attached testcase1.html is using new Worker to help fill the memory, on latest Firefox it now hitting JS assertion and worker limit assertion.

On new attached testcase2.html it's now using retry fill method and no longer using new Worker to fill the memory, however the success rate is not 100% to hit access-violation on SHA256, so we can use FFPuppet to automate retry the testcase2.html, when run 20x on my i5-1035G1 I able to get 9x success, 11x failure (about 45% success rate), on my other machine it only get 5x success, however I think it's enough for QE testing to prove the fix.

Steps to reproduce:

1. Run pip install ffpuppet in PowerShell
2. Download attached testcase2.html
3. Make new directory and enter the directory
4. Type for ($i = 1; $i -le 20; $i++) { python -m ffpuppet "[firefox path]" -u "[path to testcase file]" } on PowerShell
5. Change [firefox path] to Firefox 32-bit path i.e. C:/Program Files (x86)/Firefox/firefox.exe
6. Change [path to testcase file] to testcase2.html path i.e. C:/tmp/testcase2.html
7. Run the command
8. After the command is completed, find "SHA256" text in the folder
9. If "SHA256" text is found, then the Firefox build is affected

Using the old Nightly build from 2023-06-03 (32bit), the testcase2.html and the steps provided here I can't seem to see SHA256 anywhere in the directory where the logs are created and nothing inside the logs as well. I tested on both Windows 11 on a VM and Windows 10 on a real machine. Any thoughts?

Here is the content of a log file that has more info in it then the rest:

out of memory: 0x0000000000000188 bytes requested
[ERROR viaduct::backend::ffi] Missing HTTP status
[Parent 21040, IPC I/O Parent] WARNING: DuplicateHandle failed for handle 0 in TransferHandles: file /builds/worker/checkouts/gecko/ipc/chromium/src/chrome/common/ipc_channel_win.cc:787
[ERROR viaduct::backend::ffi] Missing HTTP status
[ERROR viaduct::backend::ffi] Missing HTTP status
[ffpuppet] Reason code: ALERT

Note that I do see similar log files and directory names and all with the last Nightly from today as well. Also I having an AMD Ryzen 7 2700x CPU on the machine not an intel as you said, not sure if this is relevant or not.

Comment 35

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Attachment: patch for esr102

Comment 36

[Irvan Kurniawan (:sourc7)]

Attachment: testcase3.html

(In reply to Bogdan Maris, Desktop QA from comment #34)

Using the old Nightly build from 2023-06-03 (32bit), the testcase2.html and the steps provided here I can't seem to see SHA256 anywhere in the directory where the logs are created and nothing inside the logs as well. I tested on both Windows 11 on a VM and Windows 10 on a real machine. Any thoughts?

Ok, I've tried reproduce testcase2.html on Firefox Nightly 2023-06-03 (32bit), I download it from https://ftp.mozilla.org/pub/firefox/nightly/2023/06/2023-06-03-09-24-55-mozilla-central/firefox-115.0a1.en-US.win32.installer.exe, then I extracted the .exe and rename the updater.exe to updater.exe.bak to prevent automatic update, tried to reproduce this, but I also unable to see "SHA256" on the logs folder.

Then I reduced the max fill memory on testcase2.html from 3753500000 to 3700000000, I attached the modified testcase as testcase3.html, now I able to see "SHA256" on the logs folder, I've tested this works on AMD Ryzen 7 5700G, Intel i5-1035G1, and Intel i9-13900K on Windows 11.

Comment 37

[Donal Meehan [:dmeehan]]

Comment on attachment 9338295 [details]
Bug 1826002 - use decoded certificates r?jschanck!

Approved for 102.13esr.

Comment 38

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/a053c9cb7874

Comment 39

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 40

[Bogdan Maris, Desktop QA]

(In reply to Irvan Kurniawan (:sourc7) from comment #36)

Created attachment 9341108 [details]
testcase3.html

(In reply to Bogdan Maris, Desktop QA from comment #34)

Using the old Nightly build from 2023-06-03 (32bit), the testcase2.html and the steps provided here I can't seem to see SHA256 anywhere in the directory where the logs are created and nothing inside the logs as well. I tested on both Windows 11 on a VM and Windows 10 on a real machine. Any thoughts?

Ok, I've tried reproduce testcase2.html on Firefox Nightly 2023-06-03 (32bit), I download it from https://ftp.mozilla.org/pub/firefox/nightly/2023/06/2023-06-03-09-24-55-mozilla-central/firefox-115.0a1.en-US.win32.installer.exe, then I extracted the .exe and rename the updater.exe to updater.exe.bak to prevent automatic update, tried to reproduce this, but I also unable to see "SHA256" on the logs folder.

Then I reduced the max fill memory on testcase2.html from 3753500000 to 3700000000, I attached the modified testcase as testcase3.html, now I able to see "SHA256" on the logs folder, I've tested this works on AMD Ryzen 7 5700G, Intel i5-1035G1, and Intel i9-13900K on Windows 11.

Thanks for your reply and for the additional info. Unfortunately I still can't see SHA256 anywhere using the exact build that you posted above and the testcase3.html file. I tried on 3 different PCs, two of them Windows 10 (Intel Core i5-3470 and AMD FX(tm)-8320) and one Windows 11 (AMD Ryzen 5 3450U).

Since I can't seem to reproduce this on older builds, would you mind verifying if this is fixed on a few builds for us?
115.0 RC - https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe
116.0a1 Nightly - https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe

I would ask to try on 102.13 esr but we don't have a build yet, I will let you know when we do and will ask you to check that as well if you don't mind.

Comment 41

[Irvan Kurniawan (:sourc7)]

(In reply to Bogdan Maris, Desktop QA from comment #40)

Thanks for your reply and for the additional info. Unfortunately I still can't see SHA256 anywhere using the exact build that you posted above and the testcase3.html file. I tried on 3 different PCs, two of them Windows 10 (Intel Core i5-3470 and AMD FX(tm)-8320) and one Windows 11 (AMD Ryzen 5 3450U).

Since I can't seem to reproduce this on older builds, would you mind verifying if this is fixed on a few builds for us?
115.0 RC - https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe
116.0a1 Nightly - https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe

Ok, I've tried reproduce this recently using testcase3.html on Firefox Nightly 2023-06-03 (32bit) on Intel i9-13900k, I able to see "SHA256" on the logs folder (log_minidump_00.txt).

I've downloaded Firefox 115.0 RC from https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe and 116.0a1 Nightly from https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe, then extracted the directory, try STR on Comment 36 using both testcase2.html and testcase3.html, I still unable to see "SHA256" on the logs directory.

I would ask to try on 102.13 esr but we don't have a build yet, I will let you know when we do and will ask you to check that as well if you don't mind.

Ok, just set needinfo request on me, I'll test once the new ESR build is available.

Comment 42

[Irvan Kurniawan (:sourc7)]

(In reply to Irvan Kurniawan (:sourc7) from comment #41)

Ok, I've tried reproduce this recently using testcase3.html on Firefox Nightly 2023-06-03 (32bit) on Intel i9-13900k, I able to see "SHA256" on the logs folder (log_minidump_00.txt).

I've downloaded Firefox 115.0 RC from https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe and 116.0a1 Nightly from https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe, then extracted the directory, try STR on Comment 36 using both testcase2.html and testcase3.html, I still unable to see "SHA256" on the logs directory.

I would ask to try on 102.13 esr but we don't have a build yet, I will let you know when we do and will ask you to check that as well if you don't mind.

Ok, just set needinfo request on me, I'll test once the new ESR build is available.

Sorry typo, I mean STR on Comment 33 (not Comment 36)

Comment 43

[Bogdan Maris, Desktop QA]

(In reply to Irvan Kurniawan (:sourc7) from comment #41)

(In reply to Bogdan Maris, Desktop QA from comment #40)

Thanks for your reply and for the additional info. Unfortunately I still can't see SHA256 anywhere using the exact build that you posted above and the testcase3.html file. I tried on 3 different PCs, two of them Windows 10 (Intel Core i5-3470 and AMD FX(tm)-8320) and one Windows 11 (AMD Ryzen 5 3450U).

Since I can't seem to reproduce this on older builds, would you mind verifying if this is fixed on a few builds for us?
115.0 RC - https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe
116.0a1 Nightly - https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe

Ok, I've tried reproduce this recently using testcase3.html on Firefox Nightly 2023-06-03 (32bit) on Intel i9-13900k, I able to see "SHA256" on the logs folder (log_minidump_00.txt).

I've downloaded Firefox 115.0 RC from https://archive.mozilla.org/pub/firefox/candidates/115.0-candidates/build1/win32/en-US/Firefox%20Setup%20115.0.exe and 116.0a1 Nightly from https://archive.mozilla.org/pub/firefox/nightly/2023/06/2023-06-27-21-45-48-mozilla-central/firefox-116.0a1.en-US.win32.installer.exe, then extracted the directory, try STR on Comment 36 using both testcase2.html and testcase3.html, I still unable to see "SHA256" on the logs directory.

I would ask to try on 102.13 esr but we don't have a build yet, I will let you know when we do and will ask you to check that as well if you don't mind.

Ok, just set needinfo request on me, I'll test once the new ESR build is available.

Thanks you very much. I'll go ahead and mark as verified both Nightly and RC based on the above.

Comment 44

[Bogdan Maris, Desktop QA]

102.13esr build is up if you don't mind giving it a quick testing - https://archive.mozilla.org/pub/firefox/candidates/102.13.0esr-candidates/build1/win32/en-US/Firefox%20Setup%20102.13.0esr.exe

Comment 45

[Irvan Kurniawan (:sourc7)]

(In reply to Bogdan Maris, Desktop QA from comment #44)

102.13esr build is up if you don't mind giving it a quick testing - https://archive.mozilla.org/pub/firefox/candidates/102.13.0esr-candidates/build1/win32/en-US/Firefox%20Setup%20102.13.0esr.exe

Ok, I just tested it on Firefox 102.12.0esr (32-bit), on the testcase3.html I lowered max fill memory from 3700000000 to 3680000000, I able to find "SHA256" string on the logs folder.

After that I downloaded Firefox 102.13esr (32-bit) from https://archive.mozilla.org/pub/firefox/candidates/102.13.0esr-candidates/build1/win32/en-US/Firefox%20Setup%20102.13.0esr.exe then retest with same testcase as above, repeated multiple times (more than 20x times), I still unable to see "SHA256" string on the logs folder.

Comment 46

[Bogdan Maris, Desktop QA]

(In reply to Irvan Kurniawan (:sourc7) from comment #45)

(In reply to Bogdan Maris, Desktop QA from comment #44)

102.13esr build is up if you don't mind giving it a quick testing - https://archive.mozilla.org/pub/firefox/candidates/102.13.0esr-candidates/build1/win32/en-US/Firefox%20Setup%20102.13.0esr.exe

Ok, I just tested it on Firefox 102.12.0esr (32-bit), on the testcase3.html I lowered max fill memory from 3700000000 to 3680000000, I able to find "SHA256" string on the logs folder.

After that I downloaded Firefox 102.13esr (32-bit) from https://archive.mozilla.org/pub/firefox/candidates/102.13.0esr-candidates/build1/win32/en-US/Firefox%20Setup%20102.13.0esr.exe then retest with same testcase as above, repeated multiple times (more than 20x times), I still unable to see "SHA256" string on the logs folder.

Thanks again for testing this. I'll go ahead and mark this bug as verified fixed.