Closed Bug 1246567 Opened 8 years ago Closed 8 years ago

NULL out xSS and xES after PK11_FreeSymKey

Categories

(NSS :: Libraries, defect)

3.18
defect
Not set
normal

Tracking

(firefox44 unaffected, firefox45 unaffected, firefox46 unaffected, firefox47 unaffected)

RESOLVED FIXED
Future
Tracking Status
firefox44 --- unaffected
firefox45 --- unaffected
firefox46 --- unaffected
firefox47 --- unaffected

People

(Reporter: ekr, Assigned: ekr)

Details

(Keywords: csectype-uaf, sec-moderate)

Attachments

(1 file)

      No description provided.
MT, this is a likely UAF but it only occurs in the TLS 1.3 code path.
Attachment #8716860 - Flags: review?(martin.thomson)
Attachment #8716860 - Flags: review?(martin.thomson) → review+
Comment on attachment 8716860 [details] [diff] [review]
0001-NULL-xSS-and-xES-after-call-to-PK11_SymKeyFree.patch

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

Wasn't sure whether you CC'ed me to get another opinion or to just let me know. In any case, LGTM.
Attachment #8716860 - Flags: review+
Dan, Wan-Teh. This is a memory error, but it's in an experimental version of NSS that is off by default in Firefox. Any reason not to just land it?
Flags: needinfo?(wtc)
Flags: needinfo?(dveditz)
Comment on attachment 8716860 [details] [diff] [review]
0001-NULL-xSS-and-xES-after-call-to-PK11_SymKeyFree.patch

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

r=wtc. It is fine to check this in.

::: lib/ssl/tls13con.c
@@ +1209,5 @@
>  loser:
>      PK11_FreeSymKey(ss->ssl3.hs.xSS);
>      PK11_FreeSymKey(ss->ssl3.hs.xES);
> +    ss->ssl3.hs.xSS = NULL;
> +    ss->ssl3.hs.xES = NULL;

Nit: you may want to put them in this order:

    PK11_FreeSymKey(ss->ssl3.hs.xSS);
    ss->ssl3.hs.xSS = NULL;
    PK11_FreeSymKey(ss->ssl3.hs.xES);
    ss->ssl3.hs.xES = NULL;
Attachment #8716860 - Flags: review+
(In reply to Eric Rescorla (:ekr) from comment #4)
> Dan, Wan-Teh. This is a memory error, but it's in an experimental version of
> NSS that is off by default in Firefox. Any reason not to just land it?

"by default"? If it's just a pref switch we should change the status flag to "disabled" instead of "unaffected" -- but either way sure, go ahead and land it if the NSS tree is open
Flags: needinfo?(wtc)
Flags: needinfo?(dveditz)
:dveditz, this is off in the sense that it can't be turned on.  I guess that makes "by default" moot :)
mt: actually it sort of can be. It's not compiled off in Firefox, and while you can set the variables in about:config, I'm not sure that it will actually negotiate 1.3 if you do that because a lot of changes in PSM are needed.
Did we forget to resolve this? Was it left open intentionally?
Assignee: nobody → ekr
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Future
Group: crypto-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: