The version of openssl11 installed on the remote host is prior to 1.1.1c-15. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2020-1456 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 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)

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.

Detections

Analytics

Amazon Linux 2 : openssl11 (ALAS-2020-1456)

medium Nessus Plugin ID 138622

Version 1.4

Version 1.3

Version 1.2

Version 1.4 Dec 12, 2024, 9:55 AM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202412120955
Version 1.3 Mar 1, 2024, 4:03 PM CVSSv2 score source (set to "CVE-2019-1549") Exploit attributes ("Exploit available" set to "False") Plugin Feed: 202403011603
Version 1.2 Mar 1, 2024, 1:53 PM CVSSv2 score source (set to "CVE-2019-1549") Exploit attributes ("Exploit available" set to "False") Plugin Feed: 202403011353