Full Report
Elliptic Curve Cryptography is the basis of most signature verification, hence identity, in modern blockchains. Prior to the recent Pectra release, only the bn254 elliptic curve was allowed. There are some precompiles for curve pairing checks and multiplication/division that were defined in previous releases for efficient gas-wise computations. Invalid curve attacks are a known issue surrounding ECDSA systems. For non-prime order curves, it's important that they're in the proper subgroup. If it's not in the correct subgroup then cryptographic operations can be manipulated/compromised. To check if a point is valid, there are two things to check: it must be on the curve and belong to a subgroup. If P is untrusted, then these verification's are crucial. In the Besu implementation of the EVM, is_valid_point was not checking if the point was on the curve - it was only cehcking if it was in the subgroup. So, can you create a point that lies in the correct subgroup but off the curve? This requires choosing a very well-chosen curve. In particular an isomorphic curve. There are more details on the math but I don't really understand them :) Why does all of this matter though? In this case, the main issue was a consensus failure. Since the Besu implementation was the only one with this particular issue, it would have diverged from the other clients, potentially leading to a chain fork. Besides this, they imply that it has other security concerns but didn't say it specifically. To me, up time is not a huge concern compared to the benefit of multiple clients. If there's a loss of funds bug to be exploited in the EVM, it would have to appear in 66% of the clients; this is the benefit of client diversity. Good bug that was very specific to cryptography none-the-less.
Analysis Summary