-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protection against malicious recovery spells is not sufficient in case of multiple recovery spells #14
Comments
Already covered in the guardian issues section, we expect users to only have a single recovery key https://github.com/code-423n4/2024-10-kleidi/blob/main/docs/EDGECASES.md#guardian |
I believe I also had flagged the issue around non-deterministic behaviour when more than one spell is armed This seems to be a known issue |
GalloDaSballo marked the issue as nullified |
GalloDaSballo changed the severity to QA (Quality Assurance) |
Having a hard time finding my comment about different order of operations Downgrading to QA due to that |
The sponsor has commented that the scenario described in this finding is already covered in the guardian issues section.
We have provided evidence in different submissions how the safety mechanisms of the protocol can break. See this finding but also:
Saying for every malicious scenario, there is a safe configuration vs saying there is a safe configuration that protects against all malicious scenarios are two different statements. I agree with the first statement that for every malicious scenario, there is a safe configuration, but there is no overall safe configuration, and this is the point of our issues. We tried to separate the different concerns which we believe point to distinct weaknesses. With these high level thoughts out of the way, let's go back to what the sponsor said:
Again, this is not stated in the documentation and in fact there is reference to multiple recovery spells all over the documentation.
Saying one timelock can cancel malicious recovery spells (-> plural!) means the system is not restricted to one recovery spell. The scenario described in the report is then straightforward, respects all the rules with which the system should be set up, and shows that there is insufficient protection against a malicious recovery spell. You introduced another argument why this issue should be considered known:
Non-deterministic behavior is different from the system getting compromised. Non-deterministic behavior just means we can't know which signers the Safe will end up with after recovery but not that the system can just easily be compromised. I don't think this statement alone is sufficient to discount the issue and point of view introduced in this finding. Overall I believe this issue is valid because
I will also agree it is hard to find a solution for this problem (see recommendation section above) but this doesn't reduce the validity of the problem. Maybe it just means the system must be advertised as less safe than expected. |
As discussed above and discussed in the EDGECASES:
The scenario listed would require both signers and malicious spell being compromised If a spell and the signers are compromised, the system has been taken over and there is no recovery scenario covered by the system Adding more spells doesn't allow to shrink the sequence to these 2 core pieces It's worth noting that in this scenario, if a bening and malicious recovery spell where present, the non deterministic behaviour of spells may actually play in favour of the benign side, since as long as they execute the spell last they will regain ownership of the Safe However all of these discussions fall into cases that can be reduced to known For this reason I believe it's most appropriate to maintain the severity as QA |
Okay, if this makes the finding fall under known edge cases I agree this is invalid. Thanks for checking. |
Lines of code
https://github.com/code-423n4/2024-10-kleidi/blob/ab89bcb443249e1524496b694ddb19e298dca799/src/RecoverySpellFactory.sol#L44-L78
https://github.com/code-423n4/2024-10-kleidi/blob/ab89bcb443249e1524496b694ddb19e298dca799/src/RecoverySpell.sol#L165-L317
https://github.com/code-423n4/2024-10-kleidi/blob/ab89bcb443249e1524496b694ddb19e298dca799/src/Timelock.sol#L687-L700
Vulnerability details
Vulnerability Details
Impact
To protect against malicious recovery spells, the documentation states that it is important to have a longer time delay on the recovery spells than the timelock. This way the safe can remove the recovery spell with a proposal before it becomes executable.
However, if the protocol had to be protected by the pause guardian because the safe keys were compromised, a malicious recovery spell will be executable before it can be removed.
The issue is not possible when there is only one recovery spell, but the protocol clearly aims to set up multiple recovery spells and by restricting oneself to one recovery spell there can be times when cold signer key loss can not be recovered.
So the issue is clearly present in live deployments and can not be explained away by the system configuration.
Proof of Concept
Consider the following scenario:
The cold signers are compromised.
RecoverySpellA gets created to rotate the signing keys.
The pause guardian calls
pause()
to cancel the malicious proposals the compromised cold signers scheduled.One day later RecoverySpellM gets created as well.
The contract is paused for
15 days
which means that, among other things, it is not possible to schedule proposals.10 days
later RecoverySpellA gets executed to rotate the signing keys.One more day later, the malicious recovery spell will be executed and the safe will be lost, as there is no protection by the safe keys.
Recommended Mitigation Steps
While the contest documentation claims that the wallet can be protected against malicious recovery spells, the finding shows that this protection is limited.
It is not possible to make minor changes in such a way that the intended protection is achieved.
Instead, the protocol design as a whole needs to be reconsidered or at least the safety guarantees that the protocol aims for must be lowered.
Assessed type
Context
The text was updated successfully, but these errors were encountered: