Advisories for Golang/Github.com/Consensys/Gnark-Crypto package

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 …

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, …

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 …

Consensys gnark-crypto through 0.11.2 allows Signature Malleability. This occurs because deserialisation of EdDSA and ECDSA signatures does not ensure that the data is in a certain interval.