The vulnerability in cloudflare/circl (GHSA-2x5j-vhc8-9cwm) stems from improper validation of elliptic curve points in its FourQ implementation. My analysis of the patches between the vulnerable version (1.6.0) and the fixed version (1.6.1) confirms this. The root cause is spread across several functions responsible for point creation, validation, and use in cryptographic protocols.
An attacker could exploit these flaws in a few ways:
- Low-Order Point Injection: By providing a specially crafted public key during a Diffie-Hellman key exchange, an attacker could force the shared secret to become a predictable, non-secret value (the identity point). The
curve4q.Shared function was vulnerable as it lacked a check to prevent this.
- Invalid Point Acceptance: The
fourq.Point.Unmarshal function could be tricked into creating an invalid point from a malicious byte string. Furthermore, the fourq.pointR1.IsOnCurve and fourq.pointR1.isEqual functions contained logic flaws, particularly around handling points at infinity (where Z=0), that would allow these invalid points to be treated as valid within the system.
These vulnerabilities would be triggered during cryptographic operations involving the FourQ curve, such as key generation, key exchange, or signature verification. A runtime profile during an exploit would likely show calls to curve4q.Shared when targeting the key exchange, and calls to fourq.Point.Unmarshal, fourq.pointR1.IsOnCurve, and fourq.pointR1.isEqual when processing malicious point data. The patches address these issues by adding strict checks for point identity, ensuring correctness during unmarshalling, and fixing the mathematical validation within IsOnCurve and isEqual.