This document describes the Sustaining position relative to the support of our applications.
Our response to
OpenSSL vulnerabilities CVE-2019-1552, CVE-2019-1547, and CVE-2019-1563:
Overview
This document addresses concerns about ePO and the
OpenSSL vulnerabilities. These vulnerabilities are referenced in the
OpenSSL Security Advisory published as shown below:
Descriptions
- CVE-2019-1552 (Severity: Low)
OpenSSL has internal defaults for a directory tree where it can find a configuration file and 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 that the default prefix for program installation, as well as for OPENSSLDIR, must be '/usr/local'. But, mingw programs are Windows programs, and as such, find themselves looking at subdirectories of 'C:/usr/local', which might be World-writable. This enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. But, 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. Owing to the limited scope of affected deployments, this reported vulnerability has been assessed as low severity.
- CVE-2019-1547 (Severity: Low)
Normally, in OpenSSL EC groups, always have a co-factor present, which is used in side channel resistant code paths. But, sometimes, it's possible to construct a group using explicit parameters (instead of using a named curve). In those cases, it's possible that such a group doesn't have the cofactor present. This issue can occur even where all parameters match a known named curve. If such a curve is used, OpenSSL falls back to non-side channel resistant code paths, which can result in full-key recovery during an ECDSA signature operation. In order to be vulnerable, an attacker would need 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 isn't vulnerable because explicit parameters are never used.
- CVE-2019-1563 (Severity: Low)
In situations where an attacker receives automated notification of the success or failure of a decryption attempt, an attacker after sending a 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 aren't 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.
Research and Conclusions
The ePO Engineering team has reviewed these
OpenSSL vulnerabilities and determined that it doesn't affect ePO.
- CVE-2019-1552: ePO isn't using the OpenSSL default OPENSSLDIR location (usr/local/ssl) for its configuration and hence isn't affected.
- CVE-2019-1547: We reviewed this CVE further in detail, and based on our ePO use of OpenSSL, we aren't affected. ePO doesn't use ECDSA, and instead uses the RSA algorithm for signature operations.
- CVE-2019-1563: ePO doesn't provide general decryption services. In any case, we must obfuscate our security-related return codes into generic HTTP results, which would prevent such issues and hence not affect us.
