Several libraries use C.getChainId()
to retrieve the chain ID, which is a constant variable, and create a non-replayable signature. This mechanism is employed to create permit
functions, which allows a user to execute a transaction on behalf of another user. Including the chain ID in this signature prevents a user from replaying the sametransaction on other chains.
The issue here is that this variable is a constant and will require an update to change it. Deploying on other chains would not pose a problem, but since Beanstalk is a protocol expected to endure, there is a possibility of a chain fork. This means that the entire chain, including the smart contracts, would be duplicated. In such a case, the constant would remain the same until the protocol updates the C
contract on the new chain. This would leave a considerable window of time for an attacker to replay all the transactions generated for the permit
functions and the tractor, if those transactions have not yet passed their deadline.
LibTractor :
LibSiloPermit:
LibTokenPermit:
Likelyhood: Low
If the deployment chain is forked.
Affect all the transaction that have not yet passed their deadline.
Impact: High
Replay attack on permit functions: theft of tokens
Replay attack on tractor: numerous possible impacts depending on the transaction created, such as theft of tokens, simultaneous execution of all transactions to attempt to depeg, etc.
Use block.chainid
instead of storing a constant variable.
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.