Closed Bug 1433571 Opened 7 years ago Closed 5 years ago

Crash in memset | sftk_DestroySessionObjectData

Categories

(NSS :: Libraries, defect, P3)

Product:
NSS
Component:
Libraries
Platform:
All
Windows
Type:
defect

Tracking

(firefox-esr52 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix

People

(Reporter: philipp, Unassigned)

References

Details

(Keywords: crash, csectype-uaf, sec-high, Whiteboard: [sec-triage-backlog] )

Crash Data

This bug was filed from the Socorro interface and is report bp-2cc5f544-302c-4e4d-95ae-def5a0180125. ============================================================= Top 10 frames of crashing thread: 0 vcruntime140.dll memset f:\dd\vctools\crt\vcruntime\src\string\i386\memset.asm:164 1 softokn3.dll sftk_DestroySessionObjectData security/nss/lib/softoken/pkcs11u.c:1040 2 softokn3.dll sftk_DestroyObject security/nss/lib/softoken/pkcs11u.c:1073 3 softokn3.dll sftk_FreeObject security/nss/lib/softoken/pkcs11u.c:1144 4 softokn3.dll NSC_DestroyObject security/nss/lib/softoken/pkcs11c.c:273 5 nss3.dll PK11_FreeSymKey security/nss/lib/pk11wrap/pk11skey.c:189 6 nss3.dll ssl3_CleanupKeyMaterial security/nss/lib/ssl/ssl3con.c:1505 7 nss3.dll ssl3_DestroyCipherSpec security/nss/lib/ssl/ssl3con.c:1550 8 nss3.dll ssl3_DestroySSL3Info security/nss/lib/ssl/ssl3con.c:13250 9 nss3.dll nss3.dll@0x339f ============================================================= this is a low volume crash on all versions of windows that has been present for a while already, but a high share of reports are showing a UAF situation.
Assignee: nobody → nobody
Group: core-security → crypto-core-security
Component: Security: PSM → Libraries
Keywords: csectype-uaf, sec-high
Product: Core → NSS
Version: Trunk → other
Tim, any ideas of what's the cause of these crashes?
Flags: needinfo?(ttaubert)
We think that those might be rare races/crashes that happen on shutdown. They should have been fixed by bug 1417680 which landed in Fx 60. Let's keep an eye out for that signature in 60+.
Flags: needinfo?(ttaubert)
Priority: -- → P3
This seems to go on. Tim, can you help us figure out what else there is we could do? https://crash-stats.mozilla.com/report/index/eb2d6ae5-af32-411d-a44b-652d90180430
Flags: needinfo?(ttaubert)
Hard to say what's going on here... it seems very hard to trigger though. I see only 27 reports in our database.
Flags: needinfo?(ttaubert)
Whiteboard: [sec-triage-backlog]
Marking 'stalled' as there is no motion and no one available to really dig into this right now.
Keywords: stalled

This is most likely also due to improper refcounting on destruction like Bug 1508776. All sftk types are similarly constructed.

QA Contact: jjones
See Also: → CVE-2019-11756

Now that we've solved Bug 1508776 I am more sure that this is a much-the-same issue, but I haven't yet ascertained if the same solution will apply. I'll be thinking on it.

JC: can we close this bug worksforme now? Although clearly a UAF, most of the ongoing crashes are in ESR-52 -- the stranded WinXP/Vista folks. The bug is still present in ESR-60 and in the last 6 months two people hit the crash on Fx 61. No crashes in anything more recent than that. Something fixed it, but it wasn't bug 1508776 since it looks like that didn't land until ~Fx70.

Flags: needinfo?(jjones)

Good plan. Works For Me.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(jjones)
Resolution: --- → WORKSFORME

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled

Removing employee no longer with company from CC list of private bugs.

Group: crypto-core-security
You need to log in before you can comment on or make changes to this bug.