openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
-
- Posts: 1
- Joined: 2017/12/21 14:11:52
openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Hi,
CVE-2017-3737 and CVE-2017-3738 have been released for openssl. According to redhat [1,2], the default version that is currently available in CentOS 7 (openssl 1.0.2k) is vulnerable, and needs to be updated (to openssl 1.0.2n).
Is there a plan to perform this upgrade of openssl? Or is there another plan for addressing these CVEs?
(I couldn't find a page indicating that CentOS backported the fix.)
Thanks!
[1] https://access.redhat.com/security/cve/cve-2017-3737
[2] https://access.redhat.com/security/cve/cve-2017-3738
CVE-2017-3737 and CVE-2017-3738 have been released for openssl. According to redhat [1,2], the default version that is currently available in CentOS 7 (openssl 1.0.2k) is vulnerable, and needs to be updated (to openssl 1.0.2n).
Is there a plan to perform this upgrade of openssl? Or is there another plan for addressing these CVEs?
(I couldn't find a page indicating that CentOS backported the fix.)
Thanks!
[1] https://access.redhat.com/security/cve/cve-2017-3737
[2] https://access.redhat.com/security/cve/cve-2017-3738
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
We are dependent on RH issuing the fixes. They have not yet done so. When they do then CentOS will pick up the new SRPM and rebuild it and release it. The links you've given there will update and show links to the the errata pages showing the fixed versions once those are released.
Despite the text saying that an update to 1.0.2n is required, that's from the upstream openssl announcement and RHEL does not work like that. The fixes in question will be backported to the 1.0.2k version that they (and we) ship.
All you can do for now is monitor those CVE pages and the associated links to bugzilla.redhat.com for the progress.
Despite the text saying that an update to 1.0.2n is required, that's from the upstream openssl announcement and RHEL does not work like that. The fixes in question will be backported to the 1.0.2k version that they (and we) ship.
All you can do for now is monitor those CVE pages and the associated links to bugzilla.redhat.com for the progress.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Hello,
Do you know if there are news about the availability of these patches?
Thank you.
Do you know if there are news about the availability of these patches?
Thank you.
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
The only news you will get is by clicking on the two links in the first post. CentOS only rebuilds what Redhat release for RHEL and have no visibility on the status of things inside Redhat. The first news we get that something is fixed is when RH release it.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
There has been an update from Redhat on these security issues.
https://access.redhat.com/errata/RHSA-2018:0998
There are updated packages that were released on April 10, 2018.
When can we expect these packages to be made available to the Centos Community?
https://access.redhat.com/errata/RHSA-2018:0998
There are updated packages that were released on April 10, 2018.
When can we expect these packages to be made available to the Centos Community?
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Anything released by RH on or after the 10th April 2018 is part of RHEL 7.5 and will be in CentOS 7.5 when that is released.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Release 7.5 of CentOS supposed that solves the relative security vulnerabilities as this is follows RH 7.5.
But by using the MaxPatrol 7.0 security scanner on a Centos 7.5 OS the software report that vulnerabilities (CVE-2017-3737, CVE-2017-3738) still existing.
Anybody know what's going on ?
Thanks
But by using the MaxPatrol 7.0 security scanner on a Centos 7.5 OS the software report that vulnerabilities (CVE-2017-3737, CVE-2017-3738) still existing.
Anybody know what's going on ?
Thanks
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Most likely your security scanner is relying on a banner check where they retrieve the info from the --version string returned by the command and if not > whatever they think the fixed version should be, alert. That doesn't work on RHEL/CentOS where Redhat backport the fixes to the version that they ship. The rpm changelog has the definitive answer:
$ rpm -q openssl
openssl-1.0.2k-12.el7.x86_64
$ rpm -q --changelog openssl | grep CVE-2017-37
- fix CVE-2017-3737 - incorrect handling of fatal error state
- fix CVE-2017-3738 - AVX2 Montgomery multiplication bug with 1024 bit modulus
- fix CVE-2017-3736 - carry propagation bug in Montgomery multiplication
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Could you possibly provide some insight as to why this is RH's approach vs. shipping the latest version?TrevorH wrote: ↑2018/10/05 13:40:38Most likely your security scanner is relying on a banner check where they retrieve the info from the --version string returned by the command and if not > whatever they think the fixed version should be, alert. That doesn't work on RHEL/CentOS where Redhat backport the fixes to the version that they ship. The rpm changelog has the definitive answer:
$ rpm -q openssl
openssl-1.0.2k-12.el7.x86_64
$ rpm -q --changelog openssl | grep CVE-2017-37
- fix CVE-2017-3737 - incorrect handling of fatal error state
- fix CVE-2017-3738 - AVX2 Montgomery multiplication bug with 1024 bit modulus
- fix CVE-2017-3736 - carry propagation bug in Montgomery multiplication
The result of this is that there are false positives that cause issues in many other scenarios, even if it's technically "fixed". A good example would be PCI vendors' scans returning a red flag on OpenSSL version. It's impossible to pass this compliance test w/out actually moving to the latest OpenSSL version.
Would that cause serious issues in CentOS that aren't obvious? I've done this on a number of CentOS systems and haven't seen issues, but I'm wondering if there's something going on where backporting is technically necessary.
Re: openssl 1.0.2k and CVE-2017-3737, CVE-2017-3738
Please see https://access.redhat.com/security/updates/backporting/ for information on backporting of security fixes and features in CentOS and RHEL. Additionally https://access.redhat.com/solutions/2074 may also be of use.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke