Skip to content

Fix CVE-2023-50980 in BERDecodeGF2NP - #1356

Open
Coralesoft wants to merge 1 commit into
weidai11:masterfrom
Coralesoft:fix/cve-2023-50980-bergf2np
Open

Fix CVE-2023-50980 in BERDecodeGF2NP#1356
Coralesoft wants to merge 1 commit into
weidai11:masterfrom
Coralesoft:fix/cve-2023-50980-bergf2np

Conversation

@Coralesoft

Copy link
Copy Markdown
Contributor

Summary

Fixes CVE-2023-50980.

BERDecodeGF2NP accepted invalid reduction-polynomial exponents for F(2^m) curve parameters and did not bound the field degree m before constructing the PolynomialMod2 representation.

Malformed input could reach PolynomialMod2::Trinomial or PolynomialMod2::Pentanomial, where the runtime checks are relaxed for ECIES<EC2N> compatibility. An unbounded m value could also drive a large bit-vector allocation.

This validates the values before constructing the PolynomialMod2
representation:

  • require 0 < t1 < m for trinomials
  • require 0 < t3 < t2 < t1 < m for pentanomials
  • cap m at MAX_GF2N_FIELD_DEGREE = 4096

The cap covers B-571 with headroom.

What changed

  • Added a bound check on m in BERDecodeGF2NP
  • Added exponent-ordering checks for trinomial and pentanomial bases

The BER decoder for F(2^m) curve parameters accepted invalid reduction
polynomial exponents and did not bound m before constructing the
PolynomialMod2 representation.

Malformed input could therefore reach PolynomialMod2::Trinomial or
Pentanomial, where the runtime checks are relaxed for ECIES<EC2N>
compatibility. An unbounded m value could also drive a large bit-vector
allocation.

Move validation to the decode boundary. Require 0 < t1 < m for trinomials,
0 < t3 < t2 < t1 < m for pentanomials, and cap m at 4096. The cap covers
B-571 with plenty of headroom.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant