Closed c4-submissions closed 12 months ago
Similar to N-06 from the bot.
raymondfam marked the issue as low quality report
raymondfam marked the issue as primary issue
This particular SafeEnabler
is utilized as a temporary delegatecall
replacement to the original by Gnosis Safe to ensure certain security checks are bypassed when initializing a fresh Console Account / sub-account deployment.
This function is never directly invoked nor is it part of a Gnosis Safe, it is only meant to be the target of delegatecall
instructions and if a Console Account / sub-account wishes to remove a module, they can invoke the relevant function of the Gnosis Safe counterpart with a delegatecall
invocation.
alex-ppg marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeEnabler.sol#L43
Vulnerability details
Impact
While
SafeEnabler.sol
implements a functionenableModule()
, which enables the module for the Safe, there's no way to disable/remove it later.Whenever some module is/becomes malicious and there would be need to remove them - protocol does not provide such a mechanism.
Proof of Concept
While looking at the documentation and the NatSpec, we can see, that
enableModule()
is based on theModuleManager.sol
from Safe. This is even explicitly mentioned in the NatSpace:When we look into
ModuleManager.sol
from Safe, we can spot, that it implements not onlyenableModule()
, but alsodisableModule()
which gives a chance to disable previously enabled module. However,SafeEnabler.sol
does not implement such a function. OnlyenableModule()
is implemented, which implies, it's not possible to disable previously enabled module.Tools Used
Manual code review
Recommended Mitigation Steps
Implement additional function
disableModule()
(it's code is even in Safe'sModuleManager.sol
) to allow disabling modules.Assessed type
Other