In L1Migrator.sol the function migrateLPT can be called by anyone. A malicious user can call migrateLPT with a small _maxSubmissionCost argument to intentionally make the retryable ticket creation fail. This will lock the LPT in the L1 escrow. Now, technically right now the admins would be able to retrieve these locked funds because the L1 escrow has the approve function. However, in a previous finding, I argued that this function gives the admins too much power so I recommended only allowing for approvals to the LPTGateway. So, in my opinion, this issue is a high severity issue as with the best codebase (that disallows admins rugging users), it is impossible to recover the locked LPT. At the very least, this griefing attack locks funds temporarily in the L1 escrow when they should be on L2.
Proof of Concept
Suppose a malicious user calls migrateLPT with _maxSubmissionCost == 0. According to the offchain labs documentation here and here, when you create a retryable ticket, if you underpay on the base submission cost, the ticket creation will fail even though the L1 transaction gets confirmed (the docs also note that this can be potentially be "very bad"). In the case of migrateLPT, this means that the LPT will have been transferred to the L1 escrow, but the retryable ticket will not be created so the corresponding L2 transaction will never be executed. This means that the LPT will be locked in the L1 escrow.
Tools Used
Manual inspection.
Recommended Mitigation Steps
In my opinion, only an admin should be able to call migrateLPT in order to ensure _maxSubmissionCost (and other param) values are set appropriately and retryable ticket creation goes smoothly. So I would recommend adding an "onlyAdmin" modifier to the function.
yondonfu
commented
2 years ago
Handle
harleythedog
Vulnerability details
Impact
In
L1Migrator.solthe functionmigrateLPTcan be called by anyone. A malicious user can callmigrateLPTwith a small_maxSubmissionCostargument to intentionally make the retryable ticket creation fail. This will lock the LPT in the L1 escrow. Now, technically right now the admins would be able to retrieve these locked funds because the L1 escrow has theapprovefunction. However, in a previous finding, I argued that this function gives the admins too much power so I recommended only allowing for approvals to the LPTGateway. So, in my opinion, this issue is a high severity issue as with the best codebase (that disallows admins rugging users), it is impossible to recover the locked LPT. At the very least, this griefing attack locks funds temporarily in the L1 escrow when they should be on L2.Proof of Concept
Suppose a malicious user calls
migrateLPTwith_maxSubmissionCost == 0. According to the offchain labs documentation here and here, when you create a retryable ticket, if you underpay on the base submission cost, the ticket creation will fail even though the L1 transaction gets confirmed (the docs also note that this can be potentially be "very bad"). In the case ofmigrateLPT, this means that the LPT will have been transferred to the L1 escrow, but the retryable ticket will not be created so the corresponding L2 transaction will never be executed. This means that the LPT will be locked in the L1 escrow.Tools Used
Manual inspection.
Recommended Mitigation Steps
In my opinion, only an admin should be able to call
migrateLPTin order to ensure_maxSubmissionCost(and other param) values are set appropriately and retryable ticket creation goes smoothly. So I would recommend adding an "onlyAdmin" modifier to the function.