-
Notifications
You must be signed in to change notification settings - Fork 17
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
Redeeming a Settlement won't work for unsigned messages when the communicating dApps have different addresses on the different chains #679
Comments
0xA5DF marked the issue as sufficient quality report |
0xA5DF marked the issue as primary issue |
0xLightt (sponsor) confirmed |
alcueca marked the issue as satisfactory |
alcueca marked issue #351 as primary and marked this issue as a duplicate of 351 |
alcueca changed the severity to 2 (Med Risk) |
alcueca marked the issue as not a duplicate |
alcueca marked the issue as primary issue |
alcueca marked the issue as selected for report |
alcueca changed the severity to 3 (High Risk) |
Hello @alcueca I'd like to bring this to the table. So, this report is about problems with redeeming settlements for unsigned messages. So, first and foremost, for redemption to be possible, a deposit should've been made in the first place, right? No deposit, no redemption. So, following this logic, and based on your comment on issue #685 , if users doing unsigned deposits is judged as qa, shouldn't the same criteria be applied to unsigned redemptions? |
Hello again @stalinMacias, |
@alexxander77 I see what you are saying, so, this issue is similar to #877 in the sense that the problem is for contract accounts that interact with the protocol. Here, the problem is for unsigned messages that don't involve the virtual account, but the problem is similar about the owner of the contract account may not own the same address in a different chain Good catch |
Addressed at Maia-DAO/2023-09-maia-remediations@b429742 |
Lines of code
https://github.com/code-423n4/2023-09-maia/blob/f5ba4de628836b2a29f9b5fff59499690008c463/src/MulticallRootRouter.sol#L163-L171
https://github.com/code-423n4/2023-09-maia/blob/f5ba4de628836b2a29f9b5fff59499690008c463/src/MulticallRootRouter.sol#L186-L194
https://github.com/code-423n4/2023-09-maia/blob/f5ba4de628836b2a29f9b5fff59499690008c463/src/RootBridgeAgent.sol#L311-L315
Vulnerability details
Impact
Funds cannot be redeemed and remain stuck in a settlement
Proof Of Concept
In
MulticallRootRouter
execute()
calls_approveAndCallOut(...)
, however, it passes the Output Params recipient also as the refundee. This is dangerous because the recipient Dapp on the BranchChain can have a different address or not exist on the Root Chain and therefore if a settlement fails it won't be able to be redeemed since the settlement owner is set as the refundee. Here is a scenario -address = 0xbeef
) initiates aCallOut(...) 0x01
withOutputParams (0x01)
for theRootRouter
RootBridgeAgent
executor callsMulticallRootRouter
execute()
which then performs some number of arbitrary calls and gets theOutputParams
assets into theMulticallRootRouter
MulticallRootRouter
attempts to bridge out the assets to the BranchChain and creates a settlement, passing therecipient (address = 0xbeef)
but also sets therefundee as (address = 0xbeef)
.0xbeef
is a known dApp on the Root Chain and the assets won't be able to be redeemed.Tools Used
Manual Inspection
Recommended Mitigation Steps
Include an argument that enables users to specify the refundee when creating settlements without using a Virtual Account
Assessed type
Context
The text was updated successfully, but these errors were encountered: