Closed c4-submissions closed 12 months ago
raymondfam marked the issue as low quality report
raymondfam marked the issue as duplicate of #143
raymondfam marked the issue as duplicate of #398
alex-ppg marked the issue as not a duplicate
The Warden describes an out-of-scope issue that relates directly to the Gnosis Safe implementation rather than the Brahma implementation.
The referenced comment by Brahma implies that cross-chain multi-sig wallet deployments will have the same address as long as it is permitted by the Gnosis Safe implementation in the first place.
As such, I consider this exhibit invalid / out-of-scope.
alex-ppg marked the issue as unsatisfactory: Out of scope
Lines of code
https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeDeployer.sol#L56 https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeDeployer.sol#L49 https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeDeployer.sol#L214
Vulnerability details
Bug Description
In the Natspec documentation, it is mentioned what needs to be done to obtain the same address for a SafeConsole wallet on different chains, but as indicated in the title, this cannot be achieved.
Proof-of-Concept
Two scenarios will be outlined to illustrate the unattainability of identical Safe Console addresses across various target chains.
Scenario 1
If we examine the official Gnosis Safe addresses, it becomes apparent that the
GnosisSafeProxyFactory
is not uniform across all chains. Given that theGnosisSafeProxyFactory
serves as the deployer for theConsoleAccount
, and it varies among chains, theConsoleAccount
will exhibit differences as well. Using the official Gnosis addresses (GnosisSafeProxyFactory
,GnosisSafe
, etc.), creating deterministic ConsoleAccounts on the following chains, Optimism, Base, and Avalanche C, is not possible.Scenario 2
It's possible to bypass the first scenario by using unofficial Gnosis addresses, but a new problem will arise that prevents the creation of a deterministic ConsoleAccount.
The creation of a console account is carried out using the function
GnosisSafeProxyFactory.deployProxyWithNonce()
. If any of the arguments accepted byGnosisSafeProxyFactory.deployProxyWithNonce
changes, the address of theGnosisSafeProxy(ConsoleAccount)
will also be different:Let's break down each argument that is passed to GnosisSafeProxyFactory.deployProxyWithNonce:
Since the creation of a console account is not bound to
msg.sender
, a malicious user can frontrun theSafeDeployer.deployConsoleAccount
transaction and increase the nonce. Because the nonce depends solely on theowners
, a malicious user can create a console account with different parameters such asthreshold
,salt
, or with/withoutpolicyCommit
. This can lead to the creation of an undesired address and increaseownerSafeCount
. As a result, there will be two new console accounts, one from the malicious user and the other from a regular user, which will differ from the intended console account address.Impact
A user aiming to generate identical
ConsoleAccount
addresses across various chains will not be able to do so.Tools Used
Manual
Recommended Mitigation Steps
Please add to the documentation that you will be using unofficial Gnosis addresses (GnosisSafeProxyFactory, Singleton, etc.). Make sure that
ownerSafeCount
depends not only onownerHash
but also onmsg.sender
. In this way, a user who genuinely wants to generate the same console account address will be able to do so, while other users who do not have the same intention can generate console accounts without any issues.Assessed type
Context