RecoverySpellFactory::_paramChecks
doesn't check if an owner is the same as the safe making it possible to create unusable recovery spells
#18
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
nullified
Issue is high quality, but not accepted
primary issue
Highest quality submission among a set of duplicates
🤖_primary
AI based primary recommendation
🤖_03_group
AI based duplicate group recommendation
sponsor disputed
Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-10-kleidi/blob/main/src/RecoverySpellFactory.sol#L118-L138
Vulnerability details
Description
Recovery spells are custom recovery mechanisms that can be used to recover funds in case of lost keys. They can be used to rotate the signers of a multisig, or to create other custom recovery logic. They are created after the wallet/safe creation, but their addresses are predicted and added beforehand to the wallet/safe creation, this logic is handled in
RecoverySpellFactory
.When a recovery spell is executed, it removes/swaps/adds the safe owners, this logic is done in the Owner module, and some checks are done upon owners' rotation, one of them is that the new owner shouldn't be the safe itself, else the rotation will revert.
However, this check is not available in the
RecoverySpellFactory
, this allows a malicious owner to construct, inject, and deploy a recovery spell that can never be used.Proof of Concept
Add the following test in
test/integration/RecoverySpells.t.sol
, and run it usingforge test -vv --fork-url "https://mainnet.infura.io/v3/PROJECT_ID" --fork-block-number 20515328 --mt test_NotValidatingSafeOwner
:Recommended Mitigation Steps
Don't allow users to pass the safe's address as a recovery owner.
and pass the safe's address to the above function from both
createRecoverySpell
andcalculateAddress
.Assessed type
Invalid Validation
The text was updated successfully, but these errors were encountered: