As per: http://tools.ietf.org/html/rfc5077#section-3.3:

"The client MUST NOT treat the ticket as valid until it has verified the server's Finished message."

This bug affects the case illustrated in figure 2 of RFC 5077, "Message Flow for Abbreviated Handshake Using New Session Ticket," where a NewSessionTicket message is sent during a session resumption, replacing the session ticket for a session already stored in the cache. That session may already be in use by other connections.

It appear there are race conditions (TOCTOU, potentially use-after-free) to lack of locking around reads and updates of the sessionTicket field of sslSessionIDStr. For example, these races can happen when thread A is trying to resume a session concurrently with thread B that has already started resuming session that same session, and where thread B has received a NewSessionTicket extension that will cause it to update the sessionTicket field of the sid that thread A is trying to read. This may cause a use-after-free when ssl3_SetSIDSessionTicket calls SECITEM_FreeItem to free the session ticket data when ssl3_SendSessionTicketXtn is trying to read it. There are probably other similar problems.


Acknowledgements:

Red Hat would like to thank the Mozilla project for reporting this issue. Upstream acknowledges Brian Smith as the original reporter of this issue.