[Bug 2062202] CVE-2022-0778 openssl: Infinite loop in BN_mod_sqrt() reachable when parsing certificates
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2062202
--- Comment #21 from Hubert Kario <hkario(a)redhat.com> ---
CVE-2022-0778 is a bug that causes OpenSSL to enter an infinite loop in the
BN_mod_sqrt() function.
The problem is caused by using the BN_mod_sqrt() function with the p parameter
that's not a prime number
(something that was documented since the function was added to OpenSSL:
https://github.com/openssl/openssl/blame/22b52164aaed31d6e93dbd2d397ace04...
as incorrect).
The way to cause OpenSSL to call BN_mod_sqrt() with p that's not a prime is to
provide OpenSSL with custom elliptic curve parameters and a point in compressed
form.
All the elliptic curves we support for ECDSA and ECDH operations are defined by
the following equation: y^2 = x^3 + ax + b mod p.
The x and y are the coordinates of a point, which in Elliptic Curve
Cryptography (ECC) is the public key.
the a, b, and p are the parameters of the curve.
The secp224r1, secp256k1, secp384r1, secp521r1 and prime256v1 curves specify
values for a, b, and p. For interoperability there's also a need to specify a
so-called base point G. That is just one specific point (pair of x and y
values) that satisfies the curve equation. The base point is used as a sort-of
"starting position" for calculations in ECDSA and ECDH.
All of those values (a, b, p, G) are static for all operations on those curves
(signatures, verification, and key exchange) irrespective of the public and
private key values. Since they are static and shared between all
implementations, protocols generally just specify a generic short identifier of
the curve instead of sending all the parameters explicitly. Some protocols,
like ECDHE in TLS 1.3, don't allow sending the parameters explicitly, some,
like X.509, do support both specifying the curve as an identifier (so-called
"named curve") and as explicit parameters, some, like ECDHE in TLS 1.2 do
support both identifiers and explicit parameters, but there are no
implementations that support explicit parameters.
Note that if you know the value of x, a, b and p, you can calculate the
possible values of y by calculating the square root of (x^3 + ax + b) mod p.
That property is used to create so-called "compressed" representation of the
point, where the point is specified only as the x coordinate and the sign of y
(reminder: equation y^2 = 4 has two solutions: y = 2 and y = -2).
So to perform the attack OpenSSL needs to receive explicit elliptic curve
parameters with p that's not a prime, accept them, and then attempt to recover
the y value of a compressed representation of a point.
The versions of OpenSSL included in Red Hat Enterprise Linux have been modified
to support only specific curve parameters: prime256v1, secp384r1, etc. That
check, if the provided parameters match one of those well-known curves, is
performed before attempting to decode the G point or read any public point
(public key). Since all the curves that OpenSSL on RHEL does support use p
that's a prime number, the attack is not possible against OpenSSL as
distributed in Red Hat Enterprise Linux.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062202
2 years, 1 month
[Bug 2062202] CVE-2022-0778 openssl: Infinite loop in BN_mod_sqrt() reachable when parsing certificates
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2062202
Mauro Matteo Cascella <mcascell(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Comment|0 |updated
--- Comment #0 has been edited ---
The BN_mod_sqrt() function, which computes a modular square root, contains
a bug that can cause it to loop forever for non-prime moduli.
Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.
It is possible to trigger the infinite loop by crafting a certificate that
has invalid explicit curve parameters.
Since certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate may thus
be subject to a denial of service attack. The infinite loop can also be
reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.
Thus vulnerable situations include:
TLS clients consuming server certificates
TLS servers consuming client certificates
Hosting providers taking certificates or private keys from customers
Certificate authorities parsing certification requests from subscribers
Anything else which parses ASN.1 elliptic curve parameters
Also any other applications that use the BN_mod_sqrt() where the attacker
can control the parameter values are vulnerable to this DoS issue.
On the OpenSSL 1.0.2 version the public key is not parsed during initial
parsing of the certificate which makes it slightly harder to trigger
the infinite loop. However any operation which requires the public key
from the certificate will trigger the infinite loop. In particular the
attacker can use a self-signed certificate to trigger the loop during
verification of the certificate signature.
This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was
addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.
OpenSSL 1.0.2 users should upgrade to 1.0.2zd
OpenSSL 1.1.1 users should upgrade to 1.1.1n
OpenSSL 3.0 users should upgrade to 3.0.2
This issue was reported to OpenSSL on the 24th February 2022 by Tavis Ormandy
from Google. The fix was developed by David Benjamin from Google and Tomáš Mráz
from OpenSSL.
OpenSSL Security Advisory:
https://www.openssl.org/news/secadv/20220315.txt
Upstream patch:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=3118eb649344...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062202
2 years, 2 months