Open c4-submissions opened 1 year ago
raymondfam marked the issue as low quality report
raymondfam marked the issue as duplicate of #244
alex-ppg marked the issue as not a duplicate
alex-ppg marked the issue as primary issue
alex-ppg marked the issue as satisfactory
Both issues describe different attack vectors arising from the same vulnerability; the nonce of a particular owner-set is tied to their hash and not necessarily to the salt_
used for them.
This is indeed an issue, however, classifying it as "Medium" is an over-statement; funds will not be lost as directly interacting with the Gnosis Safe deployer will still permit those funds to be retrieved.
I did note this particular misbehaviour in #396, indicating that this particular misbehaviour is not solely an issue with chain re-orgs but a general flaw in the way the nonce system of the deployer works.
alex-ppg changed the severity to QA (Quality Assurance)
alex-ppg marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeDeployer.sol#L253-L255
Vulnerability details
Because Brahma is planning to deploy on L2 chains where re-orgs are common like on Polygon there should always be an option to redeploy the safe on the same address so no funds are lost because it is very likely that users will deposit funds there right after deploying their console account.
If a user creates a console account and right after deposits funds there but a reorg happens and the account is not deployed but the funds are sent, the user will have to call
deployConsoleAccount()
again with the same params so that the nonce is the same and the address where funds were sent is the same, however take a look at_genNonce()
:https://github.com/code-423n4/2023-10-brahma/blob/dd0b41031b199a0aa214e50758943712f9f574a0/contracts/src/core/SafeDeployer.sol#L253-L255
The problem is that the
ownerSafeCount
can be incremented by anyone because_ownersHash
is the hash of the owners array and not the msg.sender so an attacker can calldeployConsoleAccount()
with the same owners array and this will increase theownerSafeCount
.So when a re-org happens but the users funds were sent, the attacker will call
deployConsoleAccount()
with the same owners array but different salt(so the address is not the same as the one the user deployed) this will increase theownerSafeCount
and the user will never be able to redeploy on the same address and his funds will be lost because_genNonce()
will now return a different nonceImpact
The user will fail to redeploy to the address where the funds were sent and these funds will be stuck forever.
Proof of Concept
Add this to
DeployConsoleAccount.t.sol
, as you can see the attacker can increase theownerSafeCount
and the user will fail to deploy on the same addressTools Used
Foundry
Recommended Mitigation Steps
The solution here is simple - hash
msg.sender
with the owners array so that if a re-org happens onlymsg.sender
that deployed will be able to redeploy on the same addressAssessed type
Other