[Pkg-openssl-devel] Bug#1074487: openssl: CVE-2024-5535

[Salvatore Bonaccorso]

Source: openssl
Version: 3.2.2-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: carnil at debian.org, Debian Security Team <team at security.debian.org>

Hi,

The following vulnerability was published for openssl.

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


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5535
    https://www.cve.org/CVERecord?id=CVE-2024-5535
[1] https://www.openssl.org/news/secadv/20240627.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore