-
Notifications
You must be signed in to change notification settings - Fork 18
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
if the Virtual Account's owner is a Contract Account (multisig wallet), attackers can gain control of the Virtual Accounts by gaining control of the same owner's address in a different chain #877
Comments
0xA5DF marked the issue as sufficient quality report |
0xA5DF marked the issue as primary issue |
0xBugsy (sponsor) disputed |
0xLightt (sponsor) confirmed |
Contracts should not use Virtual Accounts and deploying a specific router for contract usage is most likely the safest option. |
alcueca marked the issue as satisfactory |
alcueca marked the issue as selected for report |
This is related to #351 in the wrong assumption that a given address is controlled by the same individual in all chains. There are different attack vectors and impacts, but fixing that core assumption will solve all of them. |
alcueca changed the severity to 3 (High Risk) |
alcueca marked the issue as duplicate of #351 |
alcueca marked the issue as not selected for report |
alcueca changed the severity to 2 (Med Risk) |
alcueca marked the issue as selected for report |
Leaving this group as Medium, as this warden estimated it. The underlying issue is assuming that the same addresses are controlled by the same people in different chains, which is not necessarily true. While the sponsor states that contracts should not use virtual accounts, that is not specified in the documentation, and might only have been discovered in a future issue of rekt. |
alcueca changed the severity to 3 (High Risk) |
Greetings all, judge @alcueca While I appreciate the in-depth analysis presented in the report, there's a fundamental discrepancy when it comes to the exploitability of the vulnerability mentioned. The report suggests that on Polygon, an attacker could simply gain control of an address identical to the MultiSigWallet from Avax. However, referring to a recent real-world scenario as detailed in the Wintermute incident, we observe that this assumption may be oversimplified. The Wintermute incident underscores the intricacies and challenges involved in gaining control of a similar address on a different chain:
Given these complexities and the potential for failure, it's crucial to approach the reported vulnerability with a nuanced understanding of its practical exploitability. Thank you for considering this perspective, and I'd appreciate any further insights on this matter. |
Agree with the above comments that there maybe some efforts involved to gain control the same address but the wrong assumption that same address is controlled by same person when using smart contract wallet does cost wintermute lose 20M OP token so once fund are lost and the lost amount is large you know in case of wintermute, the multisig wallet is created using the opcode "CREATE" instead of "CREATE2" and the create opcode is not really deprecated, and still be used cc the original author @stalinMacias |
more info about the CREATE opcode https://www.evm.codes/#f0?fork=shanghai and deterministic address, https://coinsbench.com/a-comprehensive-guide-to-the-create2-opcode-in-solidity-7c6d40e3f1af anyway, agree with high severity because the potential lose of fund is large |
Addressed at Maia-DAO/2023-09-maia-remediations@4df0350 |
Lines of code
https://github.com/code-423n4/2023-09-maia/blob/main/src/RootPort.sol#L350-L353
Vulnerability details
Impact
Proof of Concept
RootPort::fetchVirtualAccount()
to get the virtual account that is assigned in the Root environment to the address who initiated the call in the SrcBranch, and if that address doesn't have assigned a virtual account yet, it proceeds to create one and assign it.Like Example, Let's suppose that a user uses a MultiSigWallet contract to deposit tokens from Avax to Root, in the RootBridgeAgent contract, the address of the MultisigWallet will be used to create a Virtual Account, and all the globalTokens that were bridged will be deposited in this Virtual Account.
As explained in detail on this article written by Rekt, it is possible to gain control of the same address for contract accounts in a different chain, especially for those contract accounts that are deployed using the Gnosis Safe contracts:
Tools Used
Manual Audit & Article wrote by Rekt
Recommended Mitigation Steps
Assessed type
Access Control
The text was updated successfully, but these errors were encountered: