Closed Bug 733521 Opened 13 years ago Closed 12 years ago

SSL3 handshake lock not held when necessary in ssl3_GatherCompleteHandshake

Categories

(NSS :: Libraries, defect, P2)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: briansmith, Assigned: briansmith)

References

Details

Attachments

(2 files, 1 obsolete file)

http://mxr.mozilla.org/security/source/security/nss/lib/ssl/ssl3gthr.c#207 207 /* Treat an empty msgState like a NULL msgState. (Most of the time 208 * when ssl3_HandleHandshake returns SECWouldBlock, it leaves 209 * behind a non-NULL but zero-length msgState). 210 * Test: async_cert_restart_server_sends_hello_request_first_in_separate_record 211 */ 212 if (ss->ssl3.hs.msgState.buf != NULL) { 213 if (ss->ssl3.hs.msgState.len == 0) { 214 ss->ssl3.hs.msgState.buf = NULL; 215 } 216 } 217 218 if (ss->ssl3.hs.msgState.buf != NULL) { 219 /* ssl3_HandleHandshake previously returned SECWouldBlock and the 220 * as-yet-unprocessed plaintext of that previous handshake record. 221 * We need to process it now before we overwrite it with the next 222 * handshake record. 223 */ 224 rv = ssl3_HandleRecord(ss, NULL, &ss->gs.buf); It seems like the accessed to ss->ssl3.hs.msgState should be protected by the SSL3 handshake lock. ssl3_RestartHandshakeAfterCertReq has the same problem. This is a problem that was identified by Wan-Teh and EKR.
Assignee: nobody → bsmith
Status: NEW → ASSIGNED
Attachment #745475 - Flags: review?(wtc)
Attachment #745475 - Attachment is patch: true
Attachment #745475 - Attachment mime type: text/x-patch → text/plain
Comment on attachment 745475 [details] [diff] [review] Hold lock across all uses of ssl3.hs in ssl3_GatherCompleteHandshake Review of attachment 745475 [details] [diff] [review]: ----------------------------------------------------------------- r=wtc. ::: lib/ssl/ssl3gthr.c @@ +286,1 @@ > /* Without this, we may end up wrongly reporting Do you know what "this" refers to? It seems to refer to the ss->ssl3.hs.restartTarget == NULL test. If so, I suggest moving this comment after ssl_GetSSL3HandshakeLock(ss), and also changing "this" to "this check" or "this test". @@ +294,3 @@ > if (rv != SECSuccess) { > PORT_SetError(PR_WOULD_BLOCK_ERROR); > + ssl_ReleaseSSL3HandshakeLock(ss); Call PORT_SetError() after releasing the lock. We should do as little work as possible while holding a lock to avoid lock contention.
Attachment #745475 - Flags: review?(wtc) → review+
Comment on attachment 745475 [details] [diff] [review] Hold lock across all uses of ssl3.hs in ssl3_GatherCompleteHandshake https://hg.mozilla.org/projects/nss/rev/753e9555853d Thanks for the review. I made the changes you suggested in this changeset.
Attachment #745475 - Flags: checked-in+
Besides the changes you suggested, I found that there are further clarifications that should be made.
Attachment #745613 - Flags: review?(wtc)
Comment on attachment 745615 [details] [diff] [review] Clarify logic in ssl3_GatherCompleteHandshake regarding async. cert verification Review of attachment 745615 [details] [diff] [review]: ----------------------------------------------------------------- r=wtc. ::: lib/ssl/ssl3gthr.c @@ +304,4 @@ > if (ss->ssl3.hs.msgState.len == 0) { > ss->ssl3.hs.msgState.buf = NULL; > + } else { > + handleRecordNow = PR_TRUE; We can also just test ss->ssl3.hs.msgState.len != 0 and leave a (buf=non-null, len=0) combination unchanged.
Attachment #745615 - Flags: review?(wtc) → review+
Comment on attachment 745615 [details] [diff] [review] Clarify logic in ssl3_GatherCompleteHandshake regarding async. cert verification (In reply to Wan-Teh Chang from comment #6) > Comment on attachment 745615 [details] [diff] [review] > Clarify logic in ssl3_GatherCompleteHandshake regarding async. cert > verification > > Review of attachment 745615 [details] [diff] [review]: > ----------------------------------------------------------------- > > r=wtc. > > ::: lib/ssl/ssl3gthr.c > @@ +304,4 @@ > > if (ss->ssl3.hs.msgState.len == 0) { > > ss->ssl3.hs.msgState.buf = NULL; > > + } else { > > + handleRecordNow = PR_TRUE; > > We can also just test ss->ssl3.hs.msgState.len != 0 and > leave a (buf=non-null, len=0) combination unchanged. Thanks for the review Wan-Teh. I think your suggested change makes sense, but I did not make that change because it would have taken too much time to convince myself that it is definitely OK. http://hg.mozilla.org/projects/nss/rev/cf3b9b27172e
Attachment #745615 - Flags: checked-in+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Priority: -- → P2
Target Milestone: --- → 3.15
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: