The OpenSSL low-level curve API flaw: out-of-bounds memory access, in apis almost nothing calls

What it actually is

Using the low-level GF(2^m) elliptic curve functions with untrusted explicit curve parameters can read or write memory outside the intended buffer.

What an attacker gets: Out-of-bounds read or write in the calling process. OpenSSL itself judged the practical risk low, because of what it takes to reach the code.

When it applies to you, and when it does not

An old package version and a real exposure are different things. These are the conditions this one needs.

• TLS does not take this path. A normal HTTPS server, mail server or database using OpenSSL for transport does not call these functions.
• It needs an application deliberately using the low-level curve APIs with curve parameters from an untrusted source, which is rare and usually deliberate cryptographic code.
• Patch it in the ordinary course of updates. It is on this site as a worked example of reading a CVE in context rather than as an emergency.

Check your own server

openssl version -a | head -2

The version and build date. As always, the package version below is the one that decides whether the fix is present.

Fixed package version, per distribution

From each distribution’s own advisory data, asked per release. A version here is the package version that carries the fix on that release, not the upstream release number.

What SecAI has recorded about it

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes. Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low. In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding. The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions. Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Recorded from nvd. Its weakness class is CWE-125 and CWE-787, from NVD.

• https://github.com/openssl/openssl/commit/72ae83ad214d2eef262461365a1975707f862712
• https://github.com/openssl/openssl/commit/bc7e04d7c8d509fb78fc0e285aa948fb0da04700
• https://github.com/openssl/openssl/commit/c0d3e4d32d2805f49bec30547f225bc4d092e1f4
• https://github.com/openssl/openssl/commit/fdf6723362ca51bd883295efe206cb5b1cfa5154
• https://github.openssl.org/openssl/extended-releases/commit/8efc0cbaa8ebba8e116f7b81a876a4123594d86a
• https://github.openssl.org/openssl/extended-releases/commit/9d576994cec2b7aa37a91740ea7e680810957e41

Read next