OpenSSL have published a security advisory. Here's how it affects BoringSSL:
| CVE | Summary | Severity in OpenSSL | Impact to BoringSSL |
|---|---|---|---|
| CVE-2024-5535 | SSL_select_next_proto buffer overread | Low | See discussion below. Fixed in c1d9ac02. |
This issue concerns fragile and, in OpenSSL, underdocumented, preconditions in the NPN and ALPN helper function, SSL_select_next_proto. If called with invalid inputs, notably an empty final argument, the function may crash or return an out-of-bounds buffer to the caller. This was fixed in BoringSSL on June 5, 2024 in commit c1d9ac02514a138129872a036e3f8a1074dcb8bd.
Typical uses of SSL_select_next_proto are not affected. Applications are affected if they pass in an invalid peer or supported parameter. That is, either:
peer and supported was not a valid encoded NPN/ALPN protocol list.supported was emptyWe are not aware of any instance of the first condition, but older versions of some applications met the second condition. In this case, the application may crash or, if it outputs the “opportunistic” protocol (see below) when the function returns OPENSSL_NPN_NO_OVERLAP, may leak private data. Outputting this protocol is common for NPN but rare for its successor, ALPN.
SSL_select_next_proto is a helper function for implementing protocol selection. It was originally added for NPN, and then reused for its successor, ALPN. It is expected to be used in the application’s protocol selection callbacks, set by SSL_CTX_set_next_proto_select_cb and SSL_CTX_set_alpn_select_cb, respectively. The function takes two protocol preference lists, peer and supported, each encoded as a byte string, and selects a protocol out of the intersection. If there is no intersection, it returns a special OPENSSL_NPN_NO_OVERLAP value and then returns the first protocol in supported as an NPN “opportunistic” protocol. It is not expected to be returned in ALPN, where a protocol mismatch should terminate the connection. But, as these are arbitrary callbacks, callers may implement arbitrary selection policies.
(In OpenSSL, the parameters are named server and client, after the original NPN semantics. We use different names in BoringSSL to reflect NPN and ALPN’s reversed roles. In NPN, the client picks a protocol based on the server list. In ALPN, the server picks a protocol based on the client list. This ensures the “opportunistic” protocol is picked out of the calling application’s supported list.)
This function has two preconditions which the caller must satisfy:
peer and supported must both be valid encoding of NPN/ALPN protocol lists.supported must not be empty; the function otherwise cannot return an opportunistic protocol. (Callers that support no protocols are not enabling NPN/ALPN at all, and thus do not need this function.)In the original implementation, these preconditions were unchecked, with memory errors when violated. In particular, if supported is empty (the second precondition), the opportunistic protocol may point to an out-of-bounds buffer. Outputting that opportunistic protocol, common in NPN, may then leak sensitive information.
BoringSSL documented both preconditions, but OpenSSL did not document that supported must not be empty. We are aware of some older versions of calling applications which could both violate this second precondition and also output the opportunistic protocol. Those applications may then leak private data in some cases.
The fix removes this fragility. While callers are still expected to heed the preconditions for SSL_select_next_proto to function properly, a violation will only cause it to cleanly return OPENSSL_NPN_NO_OVERLAP and an empty opportunistic protocol.