CVE-2024-5535

Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an<br /> empty supported client protocols buffer may cause a crash or memory contents to<br /> be sent to the peer.<br /> <br /> Impact summary: A buffer overread can have a range of potential consequences<br /> such as unexpected application beahviour or a crash. In particular this issue<br /> could result in up to 255 bytes of arbitrary private data from memory being sent<br /> to the peer leading to a loss of confidentiality. However, only applications<br /> that directly call the SSL_select_next_proto function with a 0 length list of<br /> supported client protocols are affected by this issue. This would normally never<br /> be a valid scenario and is typically not under attacker control but may occur by<br /> accident in the case of a configuration or programming error in the calling<br /> application.<br /> <br /> The OpenSSL API function SSL_select_next_proto is typically used by TLS<br /> applications that support ALPN (Application Layer Protocol Negotiation) or NPN<br /> (Next Protocol Negotiation). NPN is older, was never standardised and<br /> is deprecated in favour of ALPN. We believe that ALPN is significantly more<br /> widely deployed than NPN. The SSL_select_next_proto function accepts a list of<br /> protocols from the server and a list of protocols from the client and returns<br /> the first protocol that appears in the server list that also appears in the<br /> client list. In the case of no overlap between the two lists it returns the<br /> first item in the client list. In either case it will signal whether an overlap<br /> between the two lists was found. In the case where SSL_select_next_proto is<br /> called with a zero length client list it fails to notice this condition and<br /> returns the memory immediately following the client list pointer (and reports<br /> that there was no overlap in the lists).<br /> <br /> This function is typically called from a server side application callback for<br /> ALPN or a client side application callback for NPN. In the case of ALPN the list<br /> of protocols supplied by the client is guaranteed by libssl to never be zero in<br /> length. The list of server protocols comes from the application and should never<br /> normally be expected to be of zero length. In this case if the<br /> SSL_select_next_proto function has been called as expected (with the list<br /> supplied by the client passed in the client/client_len parameters), then the<br /> application will not be vulnerable to this issue. If the application has<br /> accidentally been configured with a zero length server list, and has<br /> accidentally passed that zero length server list in the client/client_len<br /> parameters, and has additionally failed to correctly handle a "no overlap"<br /> response (which would normally result in a handshake failure in ALPN) then it<br /> will be vulnerable to this problem.<br /> <br /> In the case of NPN, the protocol permits the client to opportunistically select<br /> a protocol when there is no overlap. OpenSSL returns the first client protocol<br /> in the no overlap case in support of this. The list of client protocols comes<br /> from the application and should never normally be expected to be of zero length.<br /> However if the SSL_select_next_proto function is accidentally called with a<br /> client_len of 0 then an invalid memory pointer will be returned instead. If the<br /> application uses this output as the opportunistic protocol then the loss of<br /> confidentiality will occur.<br /> <br /> This issue has been assessed as Low severity because applications are most<br /> likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not<br /> widely used. It also requires an application configuration or programming error.<br /> Finally, this issue would not typically be under attacker control making active<br /> exploitation unlikely.<br /> <br /> The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.<br /> <br /> Due to the low severity of this issue we are not issuing new releases of<br /> OpenSSL at this time. The fix will be included in the next releases when they<br /> become available.