Skip to content
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

H-01 MitigationConfirmed #40

Open
c4-bot-3 opened this issue Jun 7, 2024 · 1 comment
Open

H-01 MitigationConfirmed #40

c4-bot-3 opened this issue Jun 7, 2024 · 1 comment
Labels
mitigation-confirmed MR-H-01 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@c4-bot-3
Copy link
Contributor

c4-bot-3 commented Jun 7, 2024

Lines of code

Vulnerability details

Original Issue Summary

In the original issue, due to a combination of the usage of transfer and the usage of a two-step withdrawal process, people who used multisig would be able to complete the first step of the two-step withdrawal process, but they would not be able to complete the second step of the two-step withdrawal process, leading to funds lost.

Mitigation

This mitigation proposes the usage of call() instead of transfer() and checks if the call() returns a true value.

-            payable(msg.sender).transfer(_withdrawRequest.amountToRedeem);
+            (bool success, ) = payable(msg.sender).call{ value: _withdrawRequest.amountToRedeem }(
+                ""
+            );
+            if (!success) revert TransferFailed();

Comments

This mitigation succesfully mitigates the original issue - usage of call() will forward all available gas, which would prevent a lockup like in the original issue.

Suggestions

If this has not been done already, add documentation telling users to be extra careful when using multisigs. Even though this mitigation mitigates the original issue, Safe multisigs are complex and not one-size fits all. Safe multisigs can have different Guards/Modules that change the inner-workings of a Safe multisig, so it would be good to give the multisig users a heads-up.

Conclusion

LGTM

@c4-judge
Copy link

c4-judge commented Jun 8, 2024

alcueca marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Jun 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mitigation-confirmed MR-H-01 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants