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

[sherlock-admin4]

0x3adeade

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