Skip to content

Latest commit

 

History

History
45 lines (27 loc) · 1.45 KB

052.md

File metadata and controls

45 lines (27 loc) · 1.45 KB
Raw

Joyful Gingham Tarantula

Medium

Signers can frontrun Safe.exectransaction() when using delegatecalls to make it Revert.

Summary

Malicious Signers and hat wearers can use removeSigner() , claimSigner() to grief Safe.exectransaction() when using delegatecalls.

Root Cause

Safe's Safe.execTransaction() calls function HSG::checkAfterExecution() which is used to check If the transaction did not maliciously affect the safe, However in case of delegatecall transactions HSG::checkAfterExecution() calls HSG::_checkSafeState() which has an inbuilt check for change in number of owners:-

if (keccak256(abi.encode(_safe.getOwners())) != _existingOwnersHash) revert CannotChangeOwners();

https://github.com/sherlock-audit/2024-11-hats-protocol/blob/main/hats-zodiac/src/HatsSignerGate.sol#L960 If A signer renounces their hat and calls removeSigner() and frontruns execTransaction() It would change number of owners causing above check to fail and make transaction revert. A wearer of Hat can also use claimSigner() to achieve the same.

Internal pre-conditions

TX uses Delegatecall operation.

External pre-conditions

No response

Attack Path

  • Wait for Safe.execTransaction() using a delegatecall to appear in TxPool
  • Frontrun Tx by using removeSigner() or claimSigner().
  • _checkSafeState() would fail and Tx would revert.

Impact

Griefing of Users, Bad UX.

PoC

No response

Mitigation

No response