You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2023. It is now read-only.
sherlock-admin opened this issue
Mar 9, 2023
· 0 comments
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA valid Medium severity issueRewardA payout will be made for this issue
Transactions will be frozen if incorrect settings are used during a deployment on HatsSignerGateFactory
Summary
Transactions executed on the HatsSignerGate or the MultiHatsSignerGate must pass a pre-flight check and a post-flight check in order to be successful (checkTransaction(...) and checkAfterExecution(...)).
One check is to prevent safe signers from changing any modules:
// checkTransaction(...)// record existing modules for post-flight check
(address[] memorymodules,) = safe.getModulesPaginated(SENTINEL_OWNERS, enabledModuleCount);
_existingModulesHash =keccak256(abi.encode(modules));
So, if any extra module is found on the checkAfterExecution, it will result on a different hash, and the transaction will revert.
This will always happen if enabledModuleCount does not reflect the real number of modules.
Vulnerability Detail
An incorrect enabledModuleCount value, making the transactions fail can be produced due to:
Using the HatsSignerGateFactory._deployMultiHatsSignerGate(...) with a _existingModuleCount value lower than the actual modules count on the assigned safe. This function presumably has a wrong visibility scope, but can lead to these scenarios if left as it is.
Attaching a Safe with more than 5 existing modules. This is explicitly said on the documented contract, but there is no strict check to prevent it from any other interface that interacts with the contract.
On any case, there will be more modules than the actual enabledModuleCount on the contract, leading to the described transaction reverts.
Impact
Transactions performed on an HSG with incorrect module settings will be frozen and revert every time.
The enabledModuleCount public variable will reflect an incorrect value.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA valid Medium severity issueRewardA payout will be made for this issue
juancito
medium
Transactions will be frozen if incorrect settings are used during a deployment on HatsSignerGateFactory
Summary
Transactions executed on the
HatsSignerGate
or theMultiHatsSignerGate
must pass a pre-flight check and a post-flight check in order to be successful (checkTransaction(...)
andcheckAfterExecution(...)
).One check is to prevent
safe
signers from changing any modules:So, if any extra module is found on the
checkAfterExecution
, it will result on a different hash, and the transaction will revert.This will always happen if
enabledModuleCount
does not reflect the real number of modules.Vulnerability Detail
An incorrect
enabledModuleCount
value, making the transactions fail can be produced due to:HatsSignerGateFactory._deployMultiHatsSignerGate(...)
with a_existingModuleCount
value lower than the actual modules count on the assigned safe. This function presumably has a wrong visibility scope, but can lead to these scenarios if left as it is.On any case, there will be more modules than the actual
enabledModuleCount
on the contract, leading to the described transaction reverts.Impact
enabledModuleCount
public variable will reflect an incorrect value.Code Snippet
Tool used
Manual Review
Recommendation
_deployMultiHatsSignerGate
function tointernal
5
Duplicate of #43
The text was updated successfully, but these errors were encountered: