ISHACK AI BOT

Gentoo Linux: CVE-2024-38472: Apache HTTPD: Multiple Vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/01/2024 Created 10/01/2024 Added 09/30/2024 Modified 11/21/2024 Description SSRF in Apache HTTP Server on Windows allows to potentially leak NTLM hashes to a malicious server via SSRF and malicious requests or content Users are recommended to upgrade to version 2.4.60 which fixes this issue. Note: Existing configurations that access UNC paths will have to configure new directive "UNCList" to allow access during request processing. Solution(s) gentoo-linux-upgrade-www-servers-apache References https://attackerkb.com/topics/cve-2024-38472 CVE - 2024-38472 202409-31

Gentoo Linux: CVE-2024-38473: Apache HTTPD: Multiple Vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/01/2024 Created 10/01/2024 Added 09/30/2024 Modified 09/30/2024 Description Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows request URLs with incorrect encoding to be sent to backend services, potentially bypassing authentication via crafted requests. Users are recommended to upgrade to version 2.4.60, which fixes this issue. Solution(s) gentoo-linux-upgrade-www-servers-apache References https://attackerkb.com/topics/cve-2024-38473 CVE - 2024-38473 202409-31

Alpine Linux: CVE-2024-6387: Race Condition Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/01/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period. Solution(s) alpine-linux-upgrade-openssh References https://attackerkb.com/topics/cve-2024-6387 CVE - 2024-6387 https://security.alpinelinux.org/vuln/CVE-2024-6387

Alpine Linux: CVE-2024-39573: Improper Input Validation Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/01/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/01/2024 Description Potential SSRF in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to cause unsafe RewriteRules to unexpectedly setup URL's to be handled by mod_proxy. Users are recommended to upgrade to version 2.4.60, which fixes this issue. Solution(s) alpine-linux-upgrade-apache2 References https://attackerkb.com/topics/cve-2024-39573 CVE - 2024-39573 https://security.alpinelinux.org/vuln/CVE-2024-39573

Oracle Linux: CVE-2024-37298: ELSA-2024-5258:container-tools:ol8 security update (IMPORTANT) (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 06/30/2024 Created 10/18/2024 Added 10/16/2024 Modified 12/01/2024 Description gorilla/schema converts structs to and from form values. Prior to version 1.4.1 Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. Any use of `schema.Decoder.Decode()` on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. Version 1.4.1 contains a patch for the issue. A flaw was found in the gorilla/schema package. Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. Any use of `schema.Decoder.Decode()` on a struct with arrays of other structs could trigger memory exhaustion and lead to a denial of service. Solution(s) oracle-linux-upgrade-podman oracle-linux-upgrade-podman-docker oracle-linux-upgrade-podman-plugins oracle-linux-upgrade-podman-remote oracle-linux-upgrade-podman-tests References https://attackerkb.com/topics/cve-2024-37298 CVE - 2024-37298 ELSA-2024-5258 ELSA-2024-6194

Alpine Linux: CVE-2024-34703: Vulnerability in Multiple Components Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 06/30/2024 Created 10/12/2024 Added 10/10/2024 Modified 10/10/2024 Description Botan is a C++ cryptography library. X.509 certificates can identify elliptic curves using either an object identifier or using explicit encoding of the parameters. Prior to versions 3.3.0 and 2.19.4, an attacker could present an ECDSA X.509 certificate using explicit encoding where the parameters are very large. The proof of concept used a 16Kbit prime for this purpose. When parsing, the parameter is checked to be prime, causing excessive computation. This was patched in 2.19.4 and 3.3.0 to allow the prime parameter of the elliptic curve to be at most 521 bits. No known workarounds are available. Note that support for explicit encoding of elliptic curve parameters is deprecated in Botan. Solution(s) alpine-linux-upgrade-botan References https://attackerkb.com/topics/cve-2024-34703 CVE - 2024-34703 https://security.alpinelinux.org/vuln/CVE-2024-34703

SUSE: CVE-2024-34703: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/30/2024 Created 07/15/2024 Added 07/15/2024 Modified 07/17/2024 Description Botan is a C++ cryptography library. X.509 certificates can identify elliptic curves using either an object identifier or using explicit encoding of the parameters. Prior to versions 3.3.0 and 2.19.4, an attacker could present an ECDSA X.509 certificate using explicit encoding where the parameters are very large. The proof of concept used a 16Kbit prime for this purpose. When parsing, the parameter is checked to be prime, causing excessive computation. This was patched in 2.19.4 and 3.3.0 to allow the prime parameter of the elliptic curve to be at most 521 bits. No known workarounds are available. Note that support for explicit encoding of elliptic curve parameters is deprecated in Botan. Solution(s) suse-upgrade-botan suse-upgrade-botan-doc suse-upgrade-libbotan-2-19 suse-upgrade-libbotan-2-19-32bit suse-upgrade-libbotan-2-19-64bit suse-upgrade-libbotan-devel suse-upgrade-libbotan-devel-32bit suse-upgrade-libbotan-devel-64bit suse-upgrade-mozillathunderbird suse-upgrade-mozillathunderbird-translations-common suse-upgrade-mozillathunderbird-translations-other suse-upgrade-python3-botan References https://attackerkb.com/topics/cve-2024-34703 CVE - 2024-34703

Microsoft Edge Chromium: CVE-2024-34122 Severity 7 CVSS (AV:L/AC:M/Au:N/C:C/I:C/A:C) Published 06/28/2024 Created 06/28/2024 Added 06/28/2024 Modified 01/28/2025 Description Acrobat for Edge versions 126.0.2592.68 and earlier are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-34122 CVE - 2024-34122 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-34122

Amazon Linux 2023: CVE-2024-38525: Important priority package update for ecs-service-connect-agent Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 06/28/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description dd-trace-cpp is the Datadog distributed tracing for C++. When the library fails to extract trace context due to malformed unicode, it logs the list of audited headers and their values using the `nlohmann` JSON library. However, due to the way the JSON library is invoked, it throws an uncaught exception, which results in a crash. This vulnerability has been patched in version 0.2.2. Solution(s) amazon-linux-2023-upgrade-ecs-service-connect-agent References https://attackerkb.com/topics/cve-2024-38525 CVE - 2024-38525 https://alas.aws.amazon.com/AL2023/ALAS-2024-655.html

Huawei EulerOS: CVE-2024-5535: openssl security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 01/23/2025 Added 01/21/2025 Modified 01/21/2025 Description 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. Solution(s) huawei-euleros-2_0_sp8-upgrade-openssl huawei-euleros-2_0_sp8-upgrade-openssl-devel huawei-euleros-2_0_sp8-upgrade-openssl-libs huawei-euleros-2_0_sp8-upgrade-openssl-perl References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 EulerOS-SA-2025-1126

Gentoo Linux: CVE-2024-22232: Salt: Multiple Vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 12/10/2024 Added 12/09/2024 Modified 12/09/2024 Description A specially crafted url can be created which leads to a directory traversal in the salt file server. A malicious user can read an arbitrary file from a Salt master’s filesystem. Solution(s) gentoo-linux-upgrade-app-admin-salt References https://attackerkb.com/topics/cve-2024-22232 CVE - 2024-22232 202412-09

Amazon Linux 2023: CVE-2024-37371: Medium priority package update for krb5 Severity 7 CVSS (AV:N/AC:L/Au:S/C:N/I:N/A:C) Published 06/27/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields. A vulnerability was found in Kerberos. This flaw is due to an issue with message token handling. Solution(s) amazon-linux-2023-upgrade-krb5-debuginfo amazon-linux-2023-upgrade-krb5-debugsource amazon-linux-2023-upgrade-krb5-devel amazon-linux-2023-upgrade-krb5-libs amazon-linux-2023-upgrade-krb5-libs-debuginfo amazon-linux-2023-upgrade-krb5-pkinit amazon-linux-2023-upgrade-krb5-pkinit-debuginfo amazon-linux-2023-upgrade-krb5-server amazon-linux-2023-upgrade-krb5-server-debuginfo amazon-linux-2023-upgrade-krb5-server-ldap amazon-linux-2023-upgrade-krb5-server-ldap-debuginfo amazon-linux-2023-upgrade-krb5-workstation amazon-linux-2023-upgrade-krb5-workstation-debuginfo amazon-linux-2023-upgrade-libkadm5 amazon-linux-2023-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-37371 CVE - 2024-37371 https://alas.aws.amazon.com/AL2023/ALAS-2024-688.html

Alma Linux: CVE-2024-5535: Low: openssl security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 10/12/2024 Added 10/11/2024 Modified 11/21/2024 Description 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. Solution(s) alma-upgrade-openssl alma-upgrade-openssl-devel alma-upgrade-openssl-libs alma-upgrade-openssl-perl References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 https://errata.almalinux.org/8/ALSA-2024-7848.html https://errata.almalinux.org/9/ALSA-2024-9333.html

SUSE: CVE-2024-24792: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 07/30/2024 Added 07/29/2024 Modified 07/29/2024 Description Parsing a corrupt or malicious image with invalid color indices can cause a panic. Solution(s) suse-upgrade-kbfs suse-upgrade-kbfs-git suse-upgrade-kbfs-tool suse-upgrade-keybase-client References https://attackerkb.com/topics/cve-2024-24792 CVE - 2024-24792

Rocky Linux: CVE-2024-5535: openssl (RLSA-2024-7848) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 11/05/2024 Added 11/04/2024 Modified 11/18/2024 Description 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. Solution(s) rocky-upgrade-openssl rocky-upgrade-openssl-debuginfo rocky-upgrade-openssl-debugsource rocky-upgrade-openssl-devel rocky-upgrade-openssl-libs rocky-upgrade-openssl-libs-debuginfo rocky-upgrade-openssl-perl References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 https://errata.rockylinux.org/RLSA-2024:7848

Ubuntu: USN-6937-1 (CVE-2024-5535): OpenSSL vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 08/02/2024 Added 08/01/2024 Modified 10/23/2024 Description 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. Solution(s) ubuntu-upgrade-libssl1-1 ubuntu-upgrade-libssl3 ubuntu-upgrade-libssl3t64 References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 USN-6937-1

Oracle Linux: CVE-2024-5535: ELSA-2024-7848:openssl security update (LOW) (Multiple Advisories) Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 06/27/2024 Created 11/13/2024 Added 10/16/2024 Modified 01/23/2025 Description 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. A flaw was found in OpenSSL. Affected versions of this package are vulnerable to Information Exposure through the SSL_select_next_proto function. This flaw allows an attacker to cause unexpected application behavior or a crash by exploiting the buffer overread condition when the function is called with a zero-length client list. This issue is only exploitable if the application is misconfigured to use a zero-length server list and mishandles the 'no overlap' response in ALPN or uses the output as the opportunistic protocol in NPN. Solution(s) oracle-linux-upgrade-openssl oracle-linux-upgrade-openssl-devel oracle-linux-upgrade-openssl-fips-provider oracle-linux-upgrade-openssl-fips-provider-so oracle-linux-upgrade-openssl-libs oracle-linux-upgrade-openssl-perl oracle-linux-upgrade-openssl-static References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 ELSA-2024-7848 ELSA-2024-12786 ELSA-2024-9333

Amazon Linux 2023: CVE-2024-5535: Medium priority package update for openssl Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 06/27/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description 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. A flaw was found in OpenSSL. Affected versions of this package are vulnerable to Information Exposure through the SSL_select_next_proto function. This flaw allows an attacker to cause unexpected application behavior or a crash by exploiting the buffer overread condition when the function is called with a zero-length client list. This issue is only exploitable if the application is misconfigured to use a zero-length server list and mishandles the 'no overlap' response in ALPN or uses the output as the opportunistic protocol in NPN. Solution(s) amazon-linux-2023-upgrade-openssl amazon-linux-2023-upgrade-openssl-debuginfo amazon-linux-2023-upgrade-openssl-debugsource amazon-linux-2023-upgrade-openssl-devel amazon-linux-2023-upgrade-openssl-libs amazon-linux-2023-upgrade-openssl-libs-debuginfo amazon-linux-2023-upgrade-openssl-perl amazon-linux-2023-upgrade-openssl-snapsafe-libs amazon-linux-2023-upgrade-openssl-snapsafe-libs-debuginfo References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 https://alas.aws.amazon.com/AL2023/ALAS-2024-677.html

Alpine Linux: CVE-2024-22232: Vulnerability in Multiple Components Severity 7 CVSS (AV:N/AC:L/Au:S/C:C/I:N/A:N) Published 06/27/2024 Created 08/23/2024 Added 08/22/2024 Modified 10/02/2024 Description A specially crafted url can be created which leads to a directory traversal in the salt file server. A malicious user can read an arbitrary file from a Salt master’s filesystem. Solution(s) alpine-linux-upgrade-salt References https://attackerkb.com/topics/cve-2024-22232 CVE - 2024-22232 https://security.alpinelinux.org/vuln/CVE-2024-22232

Oracle MySQL Vulnerability: CVE-2024-5535 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 10/24/2024 Added 10/23/2024 Modified 10/23/2024 Description 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. Solution(s) mysql-upgrade-latest References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535

Debian: CVE-2024-5535: openssl -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 11/05/2024 Added 11/04/2024 Modified 12/02/2024 Description 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. Solution(s) debian-upgrade-openssl References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 DLA-3942-1

Huawei EulerOS: CVE-2024-5535: openssl security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description 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. Solution(s) huawei-euleros-2_0_sp9-upgrade-openssl huawei-euleros-2_0_sp9-upgrade-openssl-libs huawei-euleros-2_0_sp9-upgrade-openssl-perl References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 EulerOS-SA-2024-2400

SUSE: CVE-2024-39705: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 07/30/2024 Added 07/29/2024 Modified 07/29/2024 Description NLTK through 3.8.1 allows remote code execution if untrusted packages have pickled Python code, and the integrated data package download functionality is used. This affects, for example, averaged_perceptron_tagger and punkt. Solution(s) suse-upgrade-python3-nltk References https://attackerkb.com/topics/cve-2024-39705 CVE - 2024-39705

SUSE: CVE-2024-39134: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 08/20/2024 Added 08/19/2024 Modified 08/28/2024 Description A Stack Buffer Overflow vulnerability in zziplibv 0.13.77 allows attackers to cause a denial of service via the __zzip_fetch_disk_trailer() function at /zzip/zip.c. Solution(s) suse-upgrade-libzzip-0-13 suse-upgrade-libzzip-0-13-32bit suse-upgrade-zziplib-devel suse-upgrade-zziplib-devel-32bit References https://attackerkb.com/topics/cve-2024-39134 CVE - 2024-39134

IBM AIX: openssl_advisory42 (CVE-2024-5535): Vulnerabilities in OpenSSL affect AIX Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 06/27/2024 Created 07/31/2024 Added 07/31/2024 Modified 10/01/2024 Description 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. Solution(s) ibm-aix-openssl_advisory42 References https://attackerkb.com/topics/cve-2024-5535 CVE - 2024-5535 https://aix.software.ibm.com/aix/efixes/security/openssl_advisory42.asc