According to the versions of the openssl packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - A security vulnerability has been identified in all supported versions of OpenSSL related to the     verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit     this vulnerability by creating a malicious certificate chain that triggers exponential use of     computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy     processing is disabled by default but can be enabled by passing the `-policy' argument to the command line     utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0464)

  - Applications that use a non-default option when verifying certificates may be vulnerable to an attack from     a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are     silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A     malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent     policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled     by passing the `-policy' argument to the command line utilities or by calling the     `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0465)

  - The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy     check when doing certificate verification. However the implementation of the function does not enable the     check which allows certificates with invalid or incorrect policies to pass the certificate verification.
    As suddenly enabling the policy check could break existing deployments it was decided to keep the existing     behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to     perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the     policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.
    Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
    (CVE-2023-0466)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the openssl packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - A security vulnerability has been identified in all supported versions of OpenSSL related to the     verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit     this vulnerability by creating a malicious certificate chain that triggers exponential use of     computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy     processing is disabled by default but can be enabled by passing the `-policy' argument to the command line     utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0464)

  - Applications that use a non-default option when verifying certificates may be vulnerable to an attack from     a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are     silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A     malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent     policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled     by passing the `-policy' argument to the command line utilities or by calling the     `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0465)

  - The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy     check when doing certificate verification. However the implementation of the function does not enable the     check which allows certificates with invalid or incorrect policies to pass the certificate verification.
    As suddenly enabling the policy check could break existing deployments it was decided to keep the existing     behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to     perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the     policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.
    Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
    (CVE-2023-0466)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The version of OpenSSL installed on the remote host is prior to 3.1.1. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.1.1 advisory.

  - Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be     very slow. Impact summary: Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL     subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to     very long delays when processing those messages, which may lead to a Denial of Service. An OBJECT     IDENTIFIER is composed of a series of numbers - sub-identifiers - most of which have no size limit.
    OBJ_obj2txt() may be used to translate an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the     OpenSSL type ASN1_OBJECT) to its canonical numeric text form, which are the sub-identifiers of the OBJECT     IDENTIFIER in decimal form, separated by periods. When one of the sub-identifiers in the OBJECT IDENTIFIER     is very large (these are sizes that are seen as absurdly large, taking up tens or hundreds of KiBs), the     translation to a decimal number in text may take a very long time. The time complexity is O(n^2) with 'n'     being the size of the sub-identifiers in bytes (*). With OpenSSL 3.0, support to fetch cryptographic     algorithms using names / identifiers in string form was introduced. This includes using OBJECT IDENTIFIERs     in canonical numeric text form as identifiers for fetching algorithms. Such OBJECT IDENTIFIERs may be     received through the ASN.1 structure AlgorithmIdentifier, which is commonly used in multiple protocols to     specify what cryptographic algorithm should be used to sign or verify, encrypt or decrypt, or digest     passed data. Applications that call OBJ_obj2txt() directly with untrusted data are affected, with any     version of OpenSSL. If the use is for the mere purpose of display, the severity is considered low. In     OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS. It also impacts     anything that processes X.509 certificates, including simple things like verifying its signature. The     impact on TLS is relatively low, because all versions of OpenSSL have a 100KiB limit on the peer's     certificate chain. Additionally, this only impacts clients, or servers that have explicitly enabled client     authentication. In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects, such as X.509     certificates. This is assumed to not happen in such a way that it would cause a Denial of Service, so     these versions are considered not affected by this issue in such a way that it would be cause for concern,     and the severity is therefore considered low. (CVE-2023-2650)

  - Applications that use a non-default option when verifying certificates may be vulnerable to an attack from     a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are     silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A     malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent     policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled     by passing the `-policy' argument to the command line utilities or by calling the     `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0465)

  - Issue summary: The AES-XTS cipher decryption implementation for 64 bit ARM platform contains a bug that     could cause it to read past the input buffer, leading to a crash. Impact summary: Applications that use     the AES-XTS algorithm on the 64 bit ARM platform can crash in rare circumstances. The AES-XTS algorithm is     usually used for disk encryption. The AES-XTS cipher decryption implementation for 64 bit ARM platform     will read past the end of the ciphertext buffer if the ciphertext size is 4 mod 5 in 16 byte blocks, e.g.
    144 bytes or 1024 bytes. If the memory after the ciphertext buffer is unmapped, this will trigger a crash     which results in a denial of service. If an attacker can control the size and location of the ciphertext     buffer being decrypted by an application using AES-XTS on 64 bit ARM, the application is affected. This is     fairly unlikely making this issue a Low severity one. (CVE-2023-1255)

  - The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy     check when doing certificate verification. However the implementation of the function does not enable the     check which allows certificates with invalid or incorrect policies to pass the certificate verification.
    As suddenly enabling the policy check could break existing deployments it was decided to keep the existing     behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to     perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the     policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.
    Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
    (CVE-2023-0466)

  - A security vulnerability has been identified in all supported versions of OpenSSL related to the     verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit     this vulnerability by creating a malicious certificate chain that triggers exponential use of     computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy     processing is disabled by default but can be enabled by passing the `-policy' argument to the command line     utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0464)

Note that Nessus has not tested for these issues 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.2k-16.163. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS-2023-1762 advisory.

    A security vulnerability has been identified in all supported versions of OpenSSL related to the     verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit     this vulnerability by creating a malicious certificate chain that triggers exponential use of     computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy     processing is disabled by default but can be enabled by passing the `-policy' argument to the command line     utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0464)

    Applications that use a non-default option when verifying certificates may be vulnerable to an attack from     a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are     silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A     malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent     policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled     by passing the `-policy' argument to the command line utilities or by calling the     `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0465)

    The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy     check when doing certificate verification. However the implementation of the function does not enable the     check which allows certificates with invalid or incorrect policies to pass the certificate verification.
    As suddenly enabling the policy check could break existing deployments it was decided to keep the existing     behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to     perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the     policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.
    Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
    (CVE-2023-0466)

    Issue summary: Processing some specially crafted ASN.1 object identifiers ordata containing them may be     very slow.

    Impact summary: Applications that use OBJ_obj2txt() directly, or use any ofthe OpenSSL subsystems OCSP,     PKCS7/SMIME, CMS, CMP/CRMF or TS with no messagesize limit may experience notable to very long delays when     processing thosemessages, which may lead to a Denial of Service.

    An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -most of which have no size     limit.  OBJ_obj2txt() may be used to translatean ASN.1 OBJECT IDENTIFIER given in DER encoding form (using     the OpenSSLtype ASN1_OBJECT) to its canonical numeric text form, which are thesub-identifiers of the     OBJECT IDENTIFIER in decimal form, separated byperiods.

    When one of the sub-identifiers in the OBJECT IDENTIFIER is very large(these are sizes that are seen as     absurdly large, taking up tens or hundredsof KiBs), the translation to a decimal number in text may take a     very longtime.  The time complexity is O(n^2) with 'n' being the size of thesub-identifiers in bytes (*).

    With OpenSSL 3.0, support to fetch cryptographic algorithms using names /identifiers in string form was     introduced.  This includes using OBJECTIDENTIFIERs in canonical numeric text form as identifiers for     fetchingalgorithms.

    Such OBJECT IDENTIFIERs may be received through the ASN.1 structureAlgorithmIdentifier, which is commonly     used in multiple protocols to specifywhat cryptographic algorithm should be used to sign or verify,     encrypt ordecrypt, or digest passed data.

    Applications that call OBJ_obj2txt() directly with untrusted data areaffected, with any version of     OpenSSL.  If the use is for the mere purposeof display, the severity is considered low.

    In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,CMS, CMP/CRMF or TS.  It also     impacts anything that processes X.509certificates, including simple things like verifying its signature.

    The impact on TLS is relatively low, because all versions of OpenSSL have a100KiB limit on the peer's     certificate chain.  Additionally, this onlyimpacts clients, or servers that have explicitly enabled     clientauthentication.

    In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,such as X.509 certificates.  This     is assumed to not happen in such a waythat it would cause a Denial of Service, so these versions are     considerednot affected by this issue in such a way that it would be cause for concern,and the severity is     therefore considered low. (CVE-2023-2650)

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 Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:3722 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: Possible DoS translating ASN.1 object identifiers (CVE-2023-2650)

    * openssl: Denial of service by excessive resource usage in verifying X509 policy constraints     (CVE-2023-0464)

    * openssl: Invalid certificate policies in leaf certificates are silently ignored (CVE-2023-0465)

    * openssl: Certificate policy check not enabled (CVE-2023-0466)

    * openssl: Input buffer over-read in AES-XTS implementation on 64 bit ARM (CVE-2023-1255)

    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.

    Bug Fix(es):

    * In FIPS mode, openssl KDFs should only allow selected hash algorithms (BZ#2175860)

    * In FIPS mode, openssl should reject short KDF input or output keys or provide an indicator (BZ#2175864)

    * In FIPS mode, openssl should provide an indicator for AES-GCM to query whether the IV was generated     internally or provided externally (BZ#2175868)

    * openssl FIPS mode self-test should zeroize `out` in `verify_integrity` in providers/fips/self_test.c     (BZ#2175873)

    * In FIPS mode, openssl should not support RSA encryption or decryption without padding (outside of     RSASVE) or provide an indicator (BZ#2178029)

    * In FIPS mode, openssl should reject EVP_PKEY_fromdata() for short DHX keys, or provide an indicator     (BZ#2178030)

    * In FIPS mode, openssl should not use the legacy ECDSA_do_sign(), RSA_public_encrypt(),     RSA_private_decrypt() functions for pairwise consistency tests (BZ#2178034)

    * In FIPS mode, openssl should enter error state when DH PCT fails (BZ#2178039)

    * In FIPS mode, openssl should always run the PBKDF2 lower bounds checks or provide an indicator when the     pkcs5 parameter is set to 1 (BZ#2178137)

    * Support requiring EMS in TLS 1.2, default to it when in FIPS mode (BZ#2188046)

    * OpenSSL rsa_verify_recover doesn't use the same key checks as rsa_verify in FIPS mode (BZ#2188052)

    * RHEL9.0 - sshd dumps core when ibmca engine is configured with default_algorithms = CIPHERS or ALL     (openssl) (BZ#2211396)

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

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

According to its self-reported version, the Tenable Security Center running on the remote host is either 6.0.0, 6.1.0 or 6.1.1. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-26 advisory.

  - Tenable Security Center leverages third-party software to help provide underlying functionality. One of     the third-party components (OpenSSL) was found to contain vulnerabilities, and updated versions have been     made available by the providers.    Out of caution, and in line with best practice, Tenable has upgraded     the bundled components to address the potential impact of these issues. Tenable Security Center Patch     SC-202307.1-6.x updates OpenSSL to 3.0.9 to address the identified vulnerabilities.   Tenable has released     Patch SC-202307.1-6.x to address these issues. The installation files can be obtained from the Tenable     Downloads Portal: https://www.tenable.com/downloads/security-center   (CVE-2023-0465, CVE-2023-0466,     CVE-2023-1255, CVE-2023-2650)

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

According to its self-reported version, the Tenable Security Center running on the remote host is . It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-25 advisory.

  - Tenable Security Center leverages third-party software to help provide underlying functionality. One of     the third-party components (OpenSSL) was found to contain vulnerabilities, and updated versions have been     made available by the providers.  Out of caution, and in line with best practice, Tenable has upgraded     the bundled components to address the potential impact of these issues. Tenable Security Center Patch     SC-202307.1-5.23.1 updates OpenSSL to 1.1.1u to address the identified vulnerabilities.
    (CVE-2023-0465, CVE-2023-0466, CVE-2023-2650)

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

According to its self-reported version, the Tenable Sensor Proxy running on the remote host is version 1.0.7. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-28 advisory.

  - Sensor Proxy leverages third-party software to help provide underlying functionality. One of the third-     party components (OpenSSL) was found to contain vulnerabilities, and updated versions have been made     available by the provider. Out of caution and in line with best practice, Tenable has opted to upgrade     these components to address the potential impact of the issues. Sensor Proxy 1.0.8 updates OpenSSL     to version 3.0.10 to address the identified vulnerabilities. Tenable has released Sensor Proxy 1.0.8 to     address these issues.   (CVE-2023-0465, CVE-2023-0466, CVE-2023-1255, CVE-2023-2650,     CVE-2023-3446, CVE-2023-3817)

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

The remote Redhat Enterprise Linux 7 / 8 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:7622 advisory.

    Red Hat JBoss Web Server is a fully integrated and certified set of components for hosting Java web     applications. It is comprised of the Apache Tomcat Servlet container, JBoss HTTP Connector (mod_cluster),     the PicketLink Vault extension for Apache Tomcat, and the Tomcat Native library.

    This release of Red Hat JBoss Web Server 5.7.7 serves as a replacement for Red Hat JBoss Web Server 5.7.6.
    This release includes bug fixes, enhancements and component upgrades, which are documented in the Release     Notes linked to in the References section.

    Security Fix(es):

    * jbcs-httpd24-openssl: OpenSSL: Excessive time spent checking DH q parameter value (CVE-2023-3817)
    * openssl: Excessive time spent checking DH keys and parameters (CVE-2023-3446)
    * openssl: Certificate policy check not enabled (CVE-2023-0466)
    * openssl: Invalid certificate policies in leaf certificates are silently ignored (CVE-2023-0465)
    * openssl: Denial of service by excessive resource usage in verifying X509 policy constraints     (CVE-2023-0464)
    * openssl: Possible DoS translating ASN.1 object identifiers (CVE-2023-2650)
    * tomcat: Open Redirect vulnerability in FORM authentication (CVE-2023-41080)

    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 these issues but has instead relied only on the application's self-reported version number.

The version of openssl-snapsafe installed on the remote host is prior to 1.0.2k-24. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2OPENSSL-SNAPSAFE-2023-002 advisory.

    A timing-based side channel exists in the OpenSSL RSA Decryption implementation, which could be sufficient     to recover a ciphertext across a network in a Bleichenbacher style attack. To achieve a successful     decryption, an attacker would have to be able to send a very large number of trial messages for     decryption. This issue affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP, and RSASVE. (CVE-2022-4304)

    A use-after-free vulnerability was found in OpenSSL's BIO_new_NDEF function. The public API function     BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally     by OpenSSL to support the SMIME, CMS, and PKCS7 streaming capabilities, but it may also be called directly     by end-user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter     BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the     caller. Under certain conditions. For example, if a CMS recipient public key is invalid, the new filter     BIO is freed, and the function returns a NULL result indicating a failure. However, in this case, the BIO     chain is not properly cleaned up, and the BIO passed by the caller still retains internal pointers to the     previously freed filter BIO. If the caller then calls BIO_pop() on the BIO, a use-after-free will occur,     possibly resulting in a crash. (CVE-2023-0215)

    A type confusion vulnerability was found in OpenSSL when OpenSSL X.400 addresses processing inside an     X.509 GeneralName. When CRL checking is enabled (for example, the application sets the     X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a     memcmp call, enabling them to read memory contents or cause a denial of service. In most cases, the attack     requires the attacker to provide both the certificate chain and CRL, of which neither needs a valid     signature. If the attacker only controls one of these inputs, the other input must already contain an     X.400 address as a CRL distribution point, which is uncommon. In this case, this vulnerability is likely     only to affect applications that have implemented their own functionality for retrieving CRLs over a     network. (CVE-2023-0286)

    A security vulnerability has been identified in all supported versions of OpenSSL related to the     verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit     this vulnerability by creating a malicious certificate chain that triggers exponential use of     computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy     processing is disabled by default but can be enabled by passing the `-policy' argument to the command line     utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0464)

    Applications that use a non-default option when verifying certificates may be vulnerable to an attack from     a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are     silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A     malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent     policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled     by passing the `-policy' argument to the command line utilities or by calling the     `X509_VERIFY_PARAM_set1_policies()' function. (CVE-2023-0465)

    The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy     check when doing certificate verification. However the implementation of the function does not enable the     check which allows certificates with invalid or incorrect policies to pass the certificate verification.
    As suddenly enabling the policy check could break existing deployments it was decided to keep the existing     behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to     perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the     policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.
    Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.
    (CVE-2023-0466)

    Issue summary: Processing some specially crafted ASN.1 object identifiers ordata containing them may be     very slow.

    Impact summary: Applications that use OBJ_obj2txt() directly, or use any ofthe OpenSSL subsystems OCSP,     PKCS7/SMIME, CMS, CMP/CRMF or TS with no messagesize limit may experience notable to very long delays when     processing thosemessages, which may lead to a Denial of Service.

    An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -most of which have no size     limit.  OBJ_obj2txt() may be used to translatean ASN.1 OBJECT IDENTIFIER given in DER encoding form (using     the OpenSSLtype ASN1_OBJECT) to its canonical numeric text form, which are thesub-identifiers of the     OBJECT IDENTIFIER in decimal form, separated byperiods.

    When one of the sub-identifiers in the OBJECT IDENTIFIER is very large(these are sizes that are seen as     absurdly large, taking up tens or hundredsof KiBs), the translation to a decimal number in text may take a     very longtime.  The time complexity is O(n^2) with 'n' being the size of thesub-identifiers in bytes (*).

    With OpenSSL 3.0, support to fetch cryptographic algorithms using names /identifiers in string form was     introduced.  This includes using OBJECTIDENTIFIERs in canonical numeric text form as identifiers for     fetchingalgorithms.

    Such OBJECT IDENTIFIERs may be received through the ASN.1 structureAlgorithmIdentifier, which is commonly     used in multiple protocols to specifywhat cryptographic algorithm should be used to sign or verify,     encrypt ordecrypt, or digest passed data.

    Applications that call OBJ_obj2txt() directly with untrusted data areaffected, with any version of     OpenSSL.  If the use is for the mere purposeof display, the severity is considered low.

    In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,CMS, CMP/CRMF or TS.  It also     impacts anything that processes X.509certificates, including simple things like verifying its signature.

    The impact on TLS is relatively low, because all versions of OpenSSL have a100KiB limit on the peer's     certificate chain.  Additionally, this onlyimpacts clients, or servers that have explicitly enabled     clientauthentication.

    In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,such as X.509 certificates.  This     is assumed to not happen in such a waythat it would cause a Denial of Service, so these versions are     considerednot affected by this issue in such a way that it would be cause for concern,and the severity is     therefore considered low. (CVE-2023-2650)

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.

An update of the openssl package has been released.

The version of AOS installed on the remote host is prior to 6.5.6.7. It is, therefore, affected by multiple vulnerabilities as referenced in the NXSA-AOS-6.5.6.7 advisory.

  - Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30     may allow an unauthenticated user to potentially enable escalation of privilege via network access.
    (CVE-2023-25775)

  - In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances     where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection     were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other     places in the script where the file names of certificates being hashed were possibly passed to a command     executed through the shell. This script is distributed by some operating systems in a manner where it is     automatically executed. On such operating systems, an attacker could execute arbitrary commands with the     privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the     OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in     OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze). (CVE-2022-2068)

  - Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant     code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead     of using a named curve). In those cases it is possible that such a group does not have the cofactor     present. This can occur even where all the parameters match a known named curve. If such a curve is used     then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery     during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability     to time the creation of a large number of signatures where explicit parameters with no co-factor present     are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because     explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL     1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s). (CVE-2019-1547)

  - OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as     certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and     is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and     1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a     Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be     '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-     directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify     OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules,     etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows     targets, including Visual C builds. However, some build instructions for the diverse Windows targets on     1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by     this issue. Due to the limited scope of affected deployments this has been assessed as low severity and     therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).
    Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
    (CVE-2019-1552)

  - In situations where an attacker receives automated notification of the success or failure of a decryption     attempt an attacker, after sending a very large number of messages to be decrypted, can recover a     CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the     public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a     certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the     correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL     1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s). (CVE-2019-1563)

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

The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy check when doing certificate verification. However the implementation of the function does not enable the check which allows certificates with invalid or incorrect policies to pass the certificate verification.  As suddenly enabling the policy check could break existing deployments it was decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy() function.  Instead the applications that require OpenSSL to perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument.  Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.

This plugin only works with Tenable.ot.
Please visit https://www.tenable.com/products/tenable-ot for more information.

ID	名稱	產品	系列	已發布	已更新	嚴重性
175302	EulerOS 2.0 SP10 : openssl (EulerOS-SA-2023-1807)	Nessus	Huawei Local Security Checks	2023/5/9	2023/8/10	medium
177007	EulerOS 2.0 SP8 : openssl (EulerOS-SA-2023-2195)	Nessus	Huawei Local Security Checks	2023/6/9	2023/8/10	medium
179090	EulerOS Virtualization 3.0.6.0 : openssl (EulerOS-SA-2023-2505)	Nessus	Huawei Local Security Checks	2023/7/31	2023/8/10	medium
188763	EulerOS Virtualization 2.11.0 : openssl (EulerOS-SA-2023-2767)	Nessus	Huawei Local Security Checks	2024/1/16	2024/1/16	medium
188995	EulerOS 2.0 SP11 : openssl (EulerOS-SA-2023-2702)	Nessus	Huawei Local Security Checks	2024/1/16	2024/1/16	medium
173267	OpenSSL 3.1.0 < 3.1.1 Multiple Vulnerabilities	Nessus	Web Servers	2023/3/22	2024/10/23	medium
177069	Amazon Linux AMI : openssl (ALAS-2023-1762)	Nessus	Amazon Linux Local Security Checks	2023/6/9	2024/12/11	high
177529	RHEL 9 : openssl (RHSA-2023:3722)	Nessus	Red Hat Local Security Checks	2023/6/22	2025/3/6	high
178941	Tenable Security Center 6.0.0 / 6.1.0 / 6.1.1 Multiple Vulnerabilities (TNS-2023-26)	Nessus	Misc.	2023/7/27	2024/5/10	medium
179954	Tenable Security Center Multiple Vulnerabilities (TNS-2023-25)	Nessus	Misc.	2023/8/18	2024/5/10	medium
179955	Tenable Sensor Proxy < 1.0.8 Multiple Vulnerabilities (TNS-2023-28)	Nessus	Misc.	2023/8/18	2023/12/1	medium
186675	RHEL 7 / 8 / 9 : Red Hat JBoss Web Server 5.7.7 (RHSA-2023:7622)	Nessus	Red Hat Local Security Checks	2023/12/7	2024/11/7	high
182040	Amazon Linux 2 : openssl-snapsafe (ALASOPENSSL-SNAPSAFE-2023-002)	Nessus	Amazon Linux Local Security Checks	2023/9/27	2024/12/11	critical
204445	Photon OS 5.0: Openssl PHSA-2023-5.0-0041	Nessus	PhotonOS Local Security Checks	2024/7/24	2024/7/24	medium
212513	Nutanix AOS : Multiple Vulnerabilities (NXSA-AOS-6.5.6.7)	Nessus	Misc.	2024/12/11	2025/9/17	critical
502325	Siemens SIMATIC and SCALANCE Products Inadequate Encryption Strength (CVE-2023-0466)	Tenable OT Security	Tenable.ot	2024/7/23	2025/10/29	medium

偵測

搜尋 Plugin

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

high

critical

medium

critical

medium