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 12 months 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.