HardhatFoundry
30,000 USDC
View results
Submission Details
Severity: low
Invalid

`EIP-712` Compatibility issue in `Nexus.sol`

Summary

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.

Vulnerability Details

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.

https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/Nexus.sol#L339-L341

function replaySafeHash(bytes32 hash) public view virtual returns (bytes32) {
return _eip712Hash(hash);
}

https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/Nexus.sol#L367-L369

function _eip712Hash(bytes32 hash) internal view virtual returns (bytes32) {
return keccak256(abi.encodePacked("\x19\x01", _domainSeparator(), keccak256(abi.encode(_MESSAGE_TYPEHASH, hash))));
}

Impact

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.

Tools Used

Manual code review

Recommendations

  • 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.

Updates

Lead Judging Commences

0xnevi Lead Judge 11 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

finding-wrong-EIP712-encodeData

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.