Withdrawals can be replayed in multiple chains because of the absence of chain.id in the signature .
Proof of Concept
The withdrawWithSig is for withdrawing funds with a signature :
function withdrawWithSig(address from, address to, uint256 amount, uint256 deadline, bytes calldata sig) external {
if (block.timestamp > deadline) revert DeadlineExpired();
if (!_verifySignature(from, to, amount, nonces[from], deadline, sig)) revert InvalidSignature();//@audit chain.id not included, makes it vulnerable to replay attacks !
unchecked {
++nonces[from];
}
_withdraw(from, to, amount);
}
Phi protocol will be deployed in multiple chains . If a user has balances in different chains and signs a withdrawal to a person , If the nonces are same in both chains , the withdrawal can be replayed in all deployed chains .
Main issue here is the absense of chain.id in the signature .
Tools Used
Manual Review !
Recommended Mitigation Steps
Include chain.id in the signature to be replay proof !
Lines of code
https://github.com/code-423n4/2024-08-phi/blob/main/src/abstract/RewardControl.sol#L100
Vulnerability details
Impact
Withdrawals can be replayed in multiple chains because of the absence of chain.id in the signature .
Proof of Concept
The
withdrawWithSig
is for withdrawing funds with a signature :Phi protocol will be deployed in multiple chains . If a user has balances in different chains and signs a withdrawal to a person , If the nonces are same in both chains , the withdrawal can be replayed in all deployed chains .
Main issue here is the absense of chain.id in the signature .
Tools Used
Manual Review !
Recommended Mitigation Steps
Include
chain.id
in the signature to be replay proof !Assessed type
Context