The current implementation of the replaySafeHash
and _eip712Hash
functions in the Nexus.sol
contract does not conform to the EIP-712
standard, particularly in how dynamic types like bytes32 are handled. This causes signatures generated using standard EIP-712
tools to fail validation.
The vulnerability lies in the direct usage of the hash parameter without properly encoding it as per EIP-712
requirements. According to EIP-712
:
Dynamic types (bytes, string) should be hashed using keccak256
before being included in the final hash computation.
The current implementation directly uses hash instead of encoding it properly, which results in an incompatible hash structure.
Signatures generated using common EIP-712
tools would fail validation when interacting with the Nexus.sol
contract. This inconsistency undermines the security and reliability of signature verification processes.
Manual code review
Correct Encoding: Ensure that dynamic types (bytes32 in this case) are encoded using keccak256
before being included in the hash computation.
Update _eip712Hash
Function: Modify the _eip712Hash
function to correctly encode the hash parameter as per EIP-712
specifications.
Invalid, `bytes32` is not a dynamic value as oppose to `bytes`, since it is exactly 32 bytes long, so the encoding is correct, no issues here that is inconsistent with the `encodeData` definition highlighted in EIP712. > The atomic values are encoded as follows: Boolean false and true are encoded as uint256 values 0 and 1 respectively. Addresses are encoded as uint160. Integer values are sign-extended to 256-bit and encoded in big endian order. bytes1 to bytes31 are arrays with a beginning (index 0) and an end (index length - 1), they are zero-padded at the end to bytes32 and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2.
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.