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.