DeFiHardhatFoundry
250,000 USDC
View results
Submission Details
Severity: medium
Invalid

Replay attack in case of hard fork

Summary

If there is ever a hardfork for Beanstalk then EIP712_TYPE_HASH value will become invalid. This is because the chainId parameter is hardcoded.

L2ContractMigrationFacet.sol

function _domainSeparatorV4() internal view returns (bytes32) {
return
keccak256(
abi.encode(
EIP712_TYPE_HASH,
MIGRATION_HASHED_NAME,
MIGRATION_HASHED_VERSION,
@> C.getLegacyChainId(), // @audit - hardcoded chainId - 1
address(this)
)
);
}

LibTractor.sol:

function _domainSeparatorV4() internal view returns (bytes32) {
return
keccak256(
abi.encode(
BLUEPRINT_TYPE_HASH,
TRACTOR_HASHED_NAME,
TRACTOR_HASHED_VERSION,
@> C.getChainId(), // @audit - hardcoded chainId - 1
address(this)
)
);

Impact

  • This means even after a hard fork chainId would remain the same which is incorrect and could cause possible replay attacks.

For reference, here are findings reporting the same problem:

High - https://solodit.xyz/issues/lack-of-chainid-validation-allows-reuse-of-signatures-across-forks-trailofbits-advanced-blockchain-pdf

Medium - https://code4rena.com/reports/2022-07-golom#m-05-replay-attack-in-case-of-hard-fork

Tools Used

Manual Review

Recommendations

The EIP712_TYPE_HASH variable should be recomputed everytime by placing current value of chainId. Therefore use block.chainid instead of the hardcoded chain id.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Known issue
Assigned finding tags:

Replay attack in case of hard fork - Hardcoded chainId 712

Support

FAQs

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