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.
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.
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.
Manual review
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:
Valid medium, although all issues lack a little detail on some form of protocol specific impact here. See similar reference finding [here](https://github.com/sherlock-audit/2024-04-titles-judging/issues/279)
Valid medium, although all issues lack a little detail on some form of protocol specific impact here. See similar reference finding [here](https://github.com/sherlock-audit/2024-04-titles-judging/issues/279)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.