Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/consensys/gnark-crypto >= 0.9.1, < 0.18.1; >= 0.19.0, <= 0.19.0
Fixed in
0.19.20.18.1· Vendor fix available
Issue
The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report: A critical vulnerability exists in the gnark-crypto library's Vector.ReadFrom() function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service. Root Cause The vulnerability stems from unchecked deserialization of attacker-controlled length fields in the gnark-crypto library's Vector.ReadFrom() function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking. Vulnerable Code Path Vulnerable Code File: gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144 The code reads a 4-byte big-endian unsigned integer (sliceLen) directly from the input stream and uses it to allocate a slice without any…
Recommended action: Upgrade to 0.19.2 or 0.18.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact During deserialization of ECDSA and EdDSA signatures gnark-crypto did not check that the values are in the range [1, n-1] with n being the corresponding modulus (either base field modulus in case of R in EdDSA, and scalar field modulus in case of s,r in ECDSA and s in EdDSA). As this also allowed zero inputs, then it was possible to craft a signature which lead to null pointer dereference, leading to denial-of-service of an application. This also enabled weak signature malleability when the users assumed uniqueness of the serialized signatures (but not the underlying modulo reduced values). We are not aware of any users impacted by the bug. The implemented signature schemes in gnark-crypto complement the in-circuit versions in gnark, allowing to have end-to-end tests. Patches The issue was patched in PR #449. The fix returns an error during deserialization if the values do not belong to the ranges [1, n-1]. The fix is included in release v0.12.0 and upwards. Workarounds Users…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the exponent is bigger than r, the group order of the pairing target group GT, the exponentiation à la GLV (ExpGLV) can sometimes give incorrect results compared to normal exponentiation (Exp). The issue impacts all users using ExpGLV for exponentiations in GT. This does not impact Exp and ExpCyclotomic which are sound. Also note that GLV methods in G1 and G2 are sound and not impacted. Patches Fix has been implemented in pull request https://github.com/Consensys/gnark-crypto/pull/451 and merged in commit https://github.com/Consensys/gnark-crypto/commit/ec6be1a037f7c496d595c541a8a8d31c47bcfa3d to master branch. The fix increased the bounds of the sub-scalars by 1. In fact, since https://github.com/Consensys/gnark-crypto/pull/213, we use a fast scalar decomposition that tradeoffs divisions (needed in the Babai rounding) by right-shifts. We precompute b=2^mv/d (m log2(d)) and then at runtime compute scalarb/2^m (v is a lattice vector and d the lattice determinant). This…
Recommended action: Upgrade to 0.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.