The same address in original owner set and recovery owner set can lead to permanent DoS #33
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-19
nullified
Issue is high quality, but not accepted
🤖_primary
AI based primary recommendation
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-10-kleidi/blob/ab89bcb443249e1524496b694ddb19e298dca799/src/RecoverySpell.sol#L268
Vulnerability details
Describtion
The contract
RecoverySpell
is deployed with an array of new owners. This array is used when recovery is executed and new owners are set. However there is an edge case scenario which causes revert of the functionexecuteRecovery
.Example scenario:
We have 3/4 multisig. And one of the signers is another multisig.
This wallet is considered safe and thats why we include the wallet to the recovery owners array. Other addresses will be new.
Threshold is set to 3/4 and 2 signer keys are lost. So we have the following list of Safe owners
and a set of new recovery owners:
And we execute recovery process.
Now if we follow the code
state after
OwnerManager.removeOwner
callsand here is the problem. Swapping
[existingOwners[existingOwnersLength - 1]
forowners[0]
Aka Swapping D_M for D_M.
We can see in Safe
OwnerManager
contract:More specifically:
The address
D_M
was not removed before, and it is the last address remaining. It does point toSENTINEL_OWNERS
.It is an edge scenario, but the impact is very dangerous as it will make the recovery permanently DoSed. The system should be robust enough for all different use-cases, including the mentioned one.
PoC
See Safe test - same address swap fail:
https://github.com/safe-global/safe-smart-account/blob/6fde75d29c8b52d5ac0c93a6fb7631d434b64119/test/core/Safe.OwnerManager.spec.ts#L313C1-L322C12
Recommended Mitigation Steps
In case any address will be re-used for a new owner set, make sure it does not occupy the zero index of recovery owners
Assessed type
Invalid Validation
The text was updated successfully, but these errors were encountered: