Biconomy: Nexus

Summary

The protocol relies on Solady's SignatureCheckerLib to verify that the signature provided is valid, i.e https://github.com/vectorized/solady/blob/main/src/utils/SignatureCheckerLib.sol

However the Solady's SignatureCheckerLib warns that the library does not check if a signature is non-malleable.

https://github.com/Vectorized/solady/blob/a34977e56cc1437b7ac07e6356261d2b303da686/src/utils/SignatureCheckerLib.sol#L23

The signature verification logic is broken due to the lack of checks to ensure the s value in ECDSA signatures is only greater/lesser than 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0. This oversight could potentially allow for replay attacks, compromising the security of transactions processed through the contract.

Vulnerability Details

First see https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/Nexus.sol#L371-L520 ... snippet is too large to attach to the report.

However this signature verification process is broken, due to the absence of a critical check within the signature verification process. In ECDSA signatures, the s value plays a crucial role in ensuring the uniqueness and integrity of the signature. Specifically, the s value can either be greater than 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 or less than and these two scenarios would be counted as valid signatures, so to avoid potential issues related to signature malleability and replay attacks we need to chose one to use. Cause, without this check, malicious actors could potentially craft signatures with manipulated s values that pass the current verification logic, leading to unauthorized actions being performed as if they were legitimate transactions.

Impact

The primary impact of this vulnerability is the increased risk of replay attacks since the reuse of signatures would be possible, just by changing the s value.

Tools Used

• Manual review

Recommendations

To mitigate this vulnerability and enhance the security of the signature verification process, it is recommended to introduce a check that validates the s value of the ECDSA signature. This check should ensure that the s value is greater than 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0.

Here is a suggested code snippet that implements this recommendation: