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).

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.

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

  - 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)

  - An integer overflow was found in the x64_64 Montgomery     squaring procedure used in exponentiation with 512-bit     moduli. As per upstream: * No EC algorithms are     affected. * Attacks against 2-prime RSA1024, 3-prime     RSA1536, and DSA1024 as a result of this defect would     be very difficult to perform and are not believed     likely. * Attacks against DH512 are considered just     feasible. However, for an attack the target would have     to re-use the DH512 private key, which is not     recommended anyway. * Also applications directly using     the low level API BN_mod_exp may be affected if they     use BN_FLG_CONSTTIME(CVE-2019-1551)

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 for ARM 64 installation on the remote host is affected by the following vulnerabilities :

  - 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)

  - 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)

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 Oracle Secure Global Desktop installed on the remote host is missing a security patch from the January 2020 Critical Patch Update (CPU). It is, therefore, affected by multiple vulnerabilities:

  - A remote code execution vulnerability exists in the Core (Apache Axis) component. An unauthenticated,     adjacent attacker can exploit this issue, to execute arbitrary commands. (CVE-2019-0227)

  - A cross-site scripting vulnerability exists in the Web Server (Appache HTTPD Server) component. An     unauthenticated, remote attacker can exploit this issue via causing the link on the mod_proxy error page     to be malformed and point to a page of the attacker's choice. (CVE-2019-10092)

  - A cross-site scripting vulnerability exists in faces/context/PartialViewContextImpl.java in Eclipse     (Mojarra) due to mishandling of a client window field. An unauthenticated, remote attacker can exploit     this issue, to perform unauthorized update, insert or delete access to some of Oracle Communications     Unified Inventory Management accessible data as well as to perform an unauthorized read access to a subset     of Oracle Communications Unified Inventory Management accessible data. (CVE-2019-17091)

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

  - 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)

  - OpenSSL 1.1.1 introduced a rewritten random number     generator (RNG). This was intended to include     protection in the event of a fork() system call in     order to ensure that the parent and child processes did     not share the same RNG state. However this protection     was not being used in the default case. A partial     mitigation for this issue is that the output from a     high precision timer is mixed into the RNG state so the     likelihood of a parent and child process sharing state     is significantly reduced. If an application already     calls OPENSSL_init_crypto() explicitly using     OPENSSL_INIT_ATFORK then this problem does not occur at     all. Fixed in OpenSSL 1.1.1d (Affected     1.1.1-1.1.1c).(CVE-2019-1549)

  - 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)

  - There is an overflow bug in the x64_64 Montgomery     squaring procedure used in exponentiation with 512-bit     moduli. No EC algorithms are affected. Analysis     suggests that attacks against 2-prime RSA1024, 3-prime     RSA1536, and DSA1024 as a result of this defect would     be very difficult to perform and are not believed     likely. Attacks against DH512 are considered just     feasible. However, for an attack the target would have     to re-use the DH512 private key, which is not     recommended anyway. Also applications directly using     the low level API BN_mod_exp may be affected if they     use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e-dev     (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u-dev     (Affected 1.0.2-1.0.2t).(CVE-2019-1551)

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 compat-openssl10 package installed, the EulerOS Virtualization for ARM 64 installation on the remote host is affected by the following vulnerabilities :

  - The OpenSSL toolkit provides support for secure     communications between machines. This version of     OpenSSL package contains only the libraries and is     provided for compatibility with previous releases and     software that does not support compilation with     OpenSSL-1.1. Security Fix(es):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).Not found.(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)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)

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 version of the openssl packages installed, the EulerOS installation on the remote host is affected by the following vulnerability :

  - 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)

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 installation on the remote host is affected by the following vulnerabilities :

  - 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)

  - 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)

  - 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)

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 compat-openssl10 package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - 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. (CVE-2019-1547)

  - 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.(CVE-2019-1563)

  - 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.(CVE-2019-1552)

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 installation on the remote host is affected by the following vulnerabilities :

  - 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. (CVE-2019-1547)

  - 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.(CVE-2019-1563)

  - OpenSSL 1.1.1 introduced a rewritten random number     generator (RNG). This was intended to include     protection in the event of a fork() system call in     order to ensure that the parent and child processes did     not share the same RNG state. However this protection     was not being used in the default case. A partial     mitigation for this issue is that the output from a     high precision timer is mixed into the RNG state so the     likelihood of a parent and child process sharing state     is significantly reduced. If an application already     calls OPENSSL_init_crypto() explicitly using     OPENSSL_INIT_ATFORK then this problem does not occur at     all.(CVE-2019-1549)

  - 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.(CVE-2019-1552)

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 installation on the remote host is affected by the following vulnerabilities :

  - 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.(CVE-2019-1547)

  - 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.(CVE-2019-1563)

  - 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.
    (CVE-2019-1552)

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.

Patch for CVE-2018-0737, CVE-2018-0732, CVE-2018-0734, CVE-2019-1552, CVE-2019-1559.

https://www.openssl.org/news/vulnerabilities.html

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

According to the version of the openssl1.1.0f packages installed, the EulerOS installation on the remote host is affected by the following vulnerability :

  - 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.
    (CVE-2019-1552)

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 version of the openssl110f packages installed, the EulerOS installation on the remote host is affected by the following vulnerability :

  - 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.
    (CVE-2019-1552)

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 openssl110h packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - ChaCha20-Poly1305 is an AEAD cipher, and requires a     unique nonce input for every encryption operation. RFC     7539 specifies that the nonce value (IV) should be 96     bits (12 bytes). OpenSSL allows a variable nonce length     and front pads the nonce with 0 bytes if it is less     than 12 bytes. However it also incorrectly allows a     nonce to be set of up to 16 bytes. In this case only     the last 12 bytes are significant and any additional     leading bytes are ignored. It is a requirement of using     this cipher that nonce values are unique. Messages     encrypted using a reused nonce value are susceptible to     serious confidentiality and integrity attacks. If an     application changes the default nonce length to be     longer than 12 bytes and then makes a change to the     leading bytes of the nonce expecting the new value to     be a new unique nonce then such an application could     inadvertently encrypt messages with a reused nonce.
    Additionally the ignored bytes in a long nonce are not     covered by the integrity guarantee of this cipher. Any     application that relies on the integrity of these     ignored leading bytes of a long nonce may be further     affected. Any OpenSSL internal use of this cipher,     including in SSL/TLS, is safe because no such use sets     such a long nonce value. However user applications that     use this cipher directly and set a non-default nonce     length to be longer than 12 bytes may be vulnerable.
    OpenSSL versions 1.1.1 and 1.1.0 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.(CVE-2019-1543)

  - 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.
    (CVE-2019-1552)

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 1.1.0l. It is, therefore, affected by multiple vulnerabilities as referenced in the 1.1.0l advisory.

  - 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)

  - 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)

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.1.1d. It is, therefore, affected by multiple vulnerabilities as referenced in the 1.1.1d advisory.

  - 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)

  - OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include     protection in the event of a fork() system call in order to ensure that the parent and child processes did     not share the same RNG state. However this protection was not being used in the default case. A partial     mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so     the likelihood of a parent and child process sharing state is significantly reduced. If an application     already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur     at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). (CVE-2019-1549)

  - 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)

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.2t. It is, therefore, affected by multiple vulnerabilities as referenced in the 1.0.2t advisory.

  - 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)

  - 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)

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

ID	Name	Product	Family	Severity
212513	Nutanix AOS : Multiple Vulnerabilities (NXSA-AOS-6.5.6.7)	Nessus	Misc.	critical
135606	EulerOS Virtualization 3.0.2.2 : openssl (EulerOS-SA-2020-1444)	Nessus	Huawei Local Security Checks	medium
134510	EulerOS Virtualization for ARM 64 3.0.2.0 : openssl (EulerOS-SA-2020-1221)	Nessus	Huawei Local Security Checks	medium
133042	Oracle Secure Global Desktop Multiple Vulnerabilities (January 2020 CPU)	Nessus	Misc.	high
132817	EulerOS Virtualization for ARM 64 3.0.5.0 : openssl (EulerOS-SA-2020-1063)	Nessus	Huawei Local Security Checks	medium
132815	EulerOS Virtualization for ARM 64 3.0.5.0 : compat-openssl10 (EulerOS-SA-2020-1061)	Nessus	Huawei Local Security Checks	medium
132177	EulerOS 2.0 SP3 : openssl (EulerOS-SA-2019-2642)	Nessus	Huawei Local Security Checks	low
131617	EulerOS 2.0 SP2 : openssl (EulerOS-SA-2019-2464)	Nessus	Huawei Local Security Checks	medium
130807	EulerOS 2.0 SP8 : compat-openssl10 (EulerOS-SA-2019-2098)	Nessus	Huawei Local Security Checks	medium
130806	EulerOS 2.0 SP8 : openssl (EulerOS-SA-2019-2097)	Nessus	Huawei Local Security Checks	medium
130678	EulerOS 2.0 SP5 : openssl (EulerOS-SA-2019-2216)	Nessus	Huawei Local Security Checks	medium
129653	Fedora 31 : 1:compat-openssl10 (2019-db06efdea1)	Nessus	Fedora Local Security Checks	high
129368	Fedora 29 : 1:compat-openssl10 (2019-9a0a7c0986)	Nessus	Fedora Local Security Checks	high
129319	Fedora 30 : 1:compat-openssl10 (2019-00c25b9379)	Nessus	Fedora Local Security Checks	high
129198	EulerOS 2.0 SP3 : openssl1.1.0f (EulerOS-SA-2019-2005)	Nessus	Huawei Local Security Checks	low
128914	EulerOS 2.0 SP2 : openssl110f (EulerOS-SA-2019-1862)	Nessus	Huawei Local Security Checks	low
128813	EulerOS 2.0 SP5 : openssl110h (EulerOS-SA-2019-1890)	Nessus	Huawei Local Security Checks	high
128117	OpenSSL 1.1.0 < 1.1.0l Multiple Vulnerabilities	Nessus	Web Servers	medium
128116	OpenSSL 1.1.1 < 1.1.1d Multiple Vulnerabilities	Nessus	Web Servers	medium
128115	OpenSSL 1.0.2 < 1.0.2t Multiple Vulnerabilities	Nessus	Web Servers	medium

Detections

Analytics

CVE-2019-1552

low

Tenable Plugins

critical

medium

medium

high

medium

medium

low

medium

medium

medium

medium

high

high

high

low

low

high

medium

medium

medium