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). Reference: https://arxiv.org/abs/1909.01785 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=21c856b75d81eff61aa63b4f036bb64a85bf6d46 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=30c22fa8b1d840036b8e203585738df62a03cec8 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7c1709c2da5414f5b6133d00a03fc8c5bf996c7a https://seclists.org/bugtraq/2019/Sep/25 https://www.openssl.org/news/secadv/20190910.txt
Created mingw-openssl tracking bugs for this issue: Affects: epel-7 [bug 1752091] Affects: fedora-all [bug 1752093] Created openssl tracking bugs for this issue: Affects: fedora-all [bug 1752092]
Since libssl is not affected, this does not really affect SSL/TLS use case.
This vulnerability is out of security support scope for the following products: * Red Hat Enterprise Application Platform 6 * Red Hat Enterprise Application Platform 5 * Red Hat JBoss Enterprise Web Server 2 * Red Hat JBoss Web Server 3 Please refer to https://access.redhat.com/support/policy/updates/jboss_notes for more details.
This keeps coming up with our services teams needing the fixed versions of OpenSSL. There are several CVEs that are involved ... CVE-2019-1547 - 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-1549 - Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). CVE-2019-1551 - 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-1563 - 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). Our images installed with OpenSSL show the following ... Based on registry.access.redhat.com/ubi7/ubi-minimal - Need OpenSSL 1.0.2t or 1.0.2u-dev in ubi-7/x86_64 Red Hat Universal Base Image 7 Server (RPMs) [root@4c866ac08b81 /]# openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 Based on registry.access.redhat.com/ubi8/ubi-minimal - Need OpenSSL 1.1.1d or 1.1.1e-dev in ubi-8-baseos Red Hat Universal Base Image 8 (RPMs) - BaseOS [root@6ad506124398 /]# openssl version OpenSSL 1.1.1c FIPS 28 May 2019 Having these upgrades will solve a lot of these issues for us. When can we expect the OpenSSL packages upgraded?
This issue has been addressed in the following products: JBoss Core Services Apache HTTP Server 2.4.37 SP2 Via RHSA-2020:1336 https://access.redhat.com/errata/RHSA-2020:1336
This issue has been addressed in the following products: JBoss Core Services on RHEL 6 JBoss Core Services on RHEL 7 Via RHSA-2020:1337 https://access.redhat.com/errata/RHSA-2020:1337
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-1547
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1840 https://access.redhat.com/errata/RHSA-2020:1840
Statement: As per upstream: 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. Also libssl is not vulnerable because explicit parameters are never used.
FEDORA-EPEL-2020-ff94ccbdec has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.