MultiSig Timelock
First Flight #55
Beginner FriendlyWallet
100 EXP
View all submissions
Previous Next
Submission Details
Impact: high
Likelihood: high

Revoke confirmation can be front ran

Author Revealed upon completion

Revoke confirmation can be front ran

Description

The revokeConfirmation function is susceptible to front-running by validators who control transaction ordering. An attacker with validator privileges can submit and have their executeTransaction call processed before a legitimate revokeConfirmation, causing the transaction to be executed despite an attempt to revoke its confirmation.

Risk

Likelihood: High
Validators have control over the sequencing of transactions within blocks, enabling front-running of critical function calls.

Impact: High
The ability to front-run revokeConfirmation permits bypassing the revocation, resulting in unintended execution of transactions that were meant to be canceled, potentially leading to asset loss or unauthorized actions.

Proof of Concept

function test_frontRunningRevoke() public setupSigners createTransaction(100 ether) confirmTransaction {
vm.warp(10 days);
vm.deal(address(wallet), 1000 ether);
​
uint256 txId = 0;
assertEq(address(1).balance, 0, "Invalid initial balance");
vm.startPrank(OWNER);
vm.expectEmit(true, true, true, false);
emit MultiSigTimelock.TransactionExecuted(0, address(1), 100 ether);
wallet.executeTransaction(txId);
vm.stopPrank();
assertEq(address(1).balance, 100 ether, "Invalid initial balance");
​
vm.prank(SIGNER_TWO);
vm.expectRevert();
wallet.revokeConfirmation(txId);
}

Mitigation

Employ timelocks that enforce a minimum delay between confirmation revocation and execution, allowing observers to detect and censor front-running attempts.

Support

FAQs

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

Give us feedback!