what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

OpenSSL Security Advisory 20190910

OpenSSL Security Advisory 20190910
Posted Sep 10, 2019
Site openssl.org

OpenSSL Security Advisory 20190910 - 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. Other issues were also addressed.

tags | advisory
advisories | CVE-2019-1547, CVE-2019-1549, CVE-2019-1563
SHA-256 | 9aabd4d3854b3b34e811a20f6d073061497a1f35b60c234fd00725cb1cb66a77

OpenSSL Security Advisory 20190910

Change Mirror Download
OpenSSL Security Advisory [10 September 2019]
=============================================

ECDSA remote timing attack (CVE-2019-1547)
==========================================

Severity: Low

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.

OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by Cesar Pereida GarcĂ­a, Sohaib ul Hassan,
Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The
fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August
2019.


Fork Protection (CVE-2019-1549)
===============================

Severity: Low

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.

OpenSSL version 1.1.1 is affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d

This issue was reported by Matt Caswell. The fix was developed by Matthias
St. Pierre. It was reported to OpenSSL on 27th May 2019.


Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (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 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.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by and the fix developed by Bernd Edlinger. It was
reported to OpenSSL on 21st August 2019.


Note
=====

OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2
will end on 31st December 2019.

Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the
last 1.1.0 release.

Users of these versions should upgrade to OpenSSL 1.1.1.


References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190910.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    0 Files
  • 9
    Jul 9th
    0 Files
  • 10
    Jul 10th
    0 Files
  • 11
    Jul 11th
    0 Files
  • 12
    Jul 12th
    0 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    0 Files
  • 16
    Jul 16th
    0 Files
  • 17
    Jul 17th
    0 Files
  • 18
    Jul 18th
    0 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close