The version of OpenSSL installed on the remote host is prior to 3.2.3. It is, therefore, affected by a vulnerability as referenced in the 3.2.3 advisory.

  - 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. Found by Joseph Birr-Pixton. Thanks to David Benjamin     (Google). Fix developed by Matt Caswell. Fixed in OpenSSL 1.1.1za (premium support) (Affected since     1.1.1). (CVE-2024-5535)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by a vulnerability as referenced in the SUSE-SU-2024:3019-1 advisory.

    - CVE-2024-5535: Fixed a buffer overread in function SSL_select_next_proto() with an empty supported     client protocols buffer (bsc#1227138)

    Other fixes:
    - Build with no-afalgeng (bsc#1226463)

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 8 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2024:7846 advisory.

    OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS)     protocols, as well as a full-strength general-purpose cryptography library.

    Security Fix(es):

    * openssl: SSL_select_next_proto buffer overread (CVE-2024-5535)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by a vulnerability as referenced in the SUSE-SU-2024:3119-1 advisory.

    - CVE-2024-5535: Fixed a buffer overread in function SSL_select_next_proto() with an empty supported     client protocols buffer (bsc#1227138, bsc#1227227)

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 1.0.2zk. It is, therefore, affected by a vulnerability as referenced in the 1.0.2zk advisory.

  - 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. Found by Joseph Birr-Pixton. Thanks to David Benjamin     (Google). Fix developed by Matt Caswell. Fixed in OpenSSL 1.1.1za (premium support) (Affected since     1.1.1). (CVE-2024-5535)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 3.1.7. It is, therefore, affected by a vulnerability as referenced in the 3.1.7 advisory.

  - 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. Found by Joseph Birr-Pixton. Thanks to David Benjamin     (Google). Fix developed by Matt Caswell. Fixed in OpenSSL 3.3.2 (Affected since 3.3.0). (CVE-2024-5535)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the openssl-3.2.2-4.el9 build changelog.

  - SSL_select_next_proto buffer overread (CVE-2024-5535)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2024-677 advisory.

    Issue summary: Checking excessively long DSA keys or parameters may be veryslow.

    Impact summary: Applications that use the functions EVP_PKEY_param_check()or EVP_PKEY_public_check() to     check a DSA public key or DSA parameters mayexperience long delays. Where the key or parameters that are     being checkedhave been obtained from an untrusted source this may lead to a Denial ofService.

    The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() performvarious checks on DSA parameters.
    Some of those computations take a long timeif the modulus (`p` parameter) is too large.

    Trying to use a very large modulus is slow and OpenSSL will not allow usingpublic keys with a modulus     which is over 10,000 bits in length for signatureverification. However the key and parameter check     functions do not limitthe modulus size when performing the checks.

    An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()and supplies a key or     parameters obtained from an untrusted source could bevulnerable to a Denial of Service attack.

    These functions are not called by OpenSSL itself on untrusted DSA keys soonly applications that directly     call these functions may be vulnerable.

    Also vulnerable are the OpenSSL pkey and pkeyparam command line applicationswhen using the `-check`     option.

    The OpenSSL SSL/TLS implementation is not affected by this issue.

    The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. (CVE-2024-4603)

    openssl: Use After Free with SSL_free_buffers (CVE-2024-4741)

    Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client     protocols buffer may cause a crash or memory contents tobe sent to the peer.

    Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application     beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data     from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat     directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are     affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker     control but may occur byaccident in the case of a configuration or programming error in the     callingapplication.

    The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN     (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never     standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed     than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of     protocols from the client and returnsthe first protocol that appears in the server list that also appears     in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client     list. In either case it will signal whether an overlapbetween the two lists was found. In the case where     SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns     the memory immediately following the client list pointer (and reportsthat there was no overlap in the     lists).

    This function is typically called from a server side application callback forALPN or a client side     application callback for NPN. In the case of ALPN the listof protocols supplied by the client is     guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application     and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto     function has been called as expected (with the listsupplied by the client passed in the client/client_len     parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally     been configured with a zero length server list, and hasaccidentally passed that zero length server list in     the client/client_lenparameters, and has additionally failed to correctly handle a no overlapresponse     (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.

    In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no     overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of     client protocols comesfrom 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 aclient_len of 0 then an     invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic     protocol then the loss ofconfidentiality will occur.

    This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they     are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration     or programming error.Finally, this issue would not typically be under attacker control making     activeexploitation 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 ofOpenSSL at this time. The fix will     be included in the next releases when theybecome available. (CVE-2024-5535)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 11 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-3942 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-3942-2                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                         Sean Whitton     November 03, 2024                             https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : openssl     Version        : 1.1.1w-0+deb11u2     CVE ID         : CVE-2023-5678 CVE-2024-0727 CVE-2024-2511 CVE-2024-4741                      CVE-2024-5535 CVE-2024-9143     Debian Bug     : 1055473 1061582 1068658 1072113 1074487 1085378

    The previous update to openssl for Debian bullseye LTS was uploaded     with an incorrect version number.  As a result, the apt tool would not     select the updated package for installation on otherwise up-to-date     bullseye systems.  This has now been corrected.

    For Debian 11 bullseye, this problem has been fixed in version     1.1.1w-0+deb11u2.

    We recommend that you upgrade your openssl packages.

    For the detailed security status of openssl please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/openssl

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Published	Updated	Severity
201081	OpenSSL 3.2.0 < 3.2.3 Vulnerability	Nessus	Web Servers	6/27/2024	10/7/2024	critical
206252	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : openssl-3 (SUSE-SU-2024:3019-1)	Nessus	SuSE Local Security Checks	8/28/2024	8/28/2024	critical
208438	RHEL 8 : openssl (RHSA-2024:7846)	Nessus	Red Hat Local Security Checks	10/9/2024	10/9/2024	critical
206585	SUSE SLES15 / openSUSE 15 Security Update : openssl-1_0_0 (SUSE-SU-2024:3119-1)	Nessus	SuSE Local Security Checks	9/4/2024	9/6/2024	critical
201086	OpenSSL 1.0.2 < 1.0.2zk Vulnerability	Nessus	Web Servers	6/27/2024	10/7/2024	critical
201082	OpenSSL 3.1.0 < 3.1.7 Vulnerability	Nessus	Web Servers	6/27/2024	10/7/2024	critical
206293	CentOS 9 : openssl-3.2.2-4.el9	Nessus	CentOS Local Security Checks	8/28/2024	8/28/2024	critical
205110	Amazon Linux 2023 : openssl, openssl-devel, openssl-libs (ALAS2023-2024-677)	Nessus	Amazon Linux Local Security Checks	8/6/2024	9/6/2024	critical
209978	Debian dla-3942 : libcrypto1.1-udeb - security update	Nessus	Debian Local Security Checks	10/31/2024	11/7/2024	high

Detections

Analytics

Plugins Search

critical

critical

critical

critical

critical

critical

critical

critical

high