Closed c4-submissions closed 1 year ago
0xA5DF marked the issue as primary issue
0xA5DF marked the issue as sufficient quality report
Improvements are usually just QA, but will leave open for sponsor to comment and for judge to see if there's a case to make an exception here
0xBugsy (sponsor) disputed
This is intended. Our system is a centralization minimal approach to a non blocking lzApp. Despite this not being possible in production in theory would be a nice addition due to abundance of caution.
0xBugsy (sponsor) confirmed
0xBugsy marked the issue as disagree with severity
Medium is justified, see #399
alcueca marked the issue as satisfactory
alcueca marked the issue as partial-50
Misses the attack angle via underfunded transactions that makes it a valid DoS
alcueca marked the issue as duplicate of #399
alcueca marked the issue as satisfactory
alcueca marked the issue as partial-50
Lines of code
https://github.com/code-423n4/2023-09-maia/blob/c0dc3550e0754571b82d7bfd8f0282ac8fa5e42f/src/RootBridgeAgent.sol#L32 https://github.com/code-423n4/2023-09-maia/blob/c0dc3550e0754571b82d7bfd8f0282ac8fa5e42f/src/BranchBridgeAgent.sol#L45
Vulnerability details
Impact
The User Application (LZReceiver) should implement the ILayerZeroUserApplicationConfig interface which includes the forceResumeReceive function. This is very important as in the worst case, it can allow the owner to unblock the queue of messages if something unexpected/unpredicted occurs.
This is crucially important to have especially in emergency situations. I've reported 2 issues related to blocking messaging channel of LZ. This explains why it is highly recommended by LayerZero. Please check https://layerzero.gitbook.io/docs/evm-guides/best-practice
Proof of Concept
Please check RootBridgeAgent and BranchBridgeAgent. There is no Implementation of ILayerZeroUserApplicationConfig.
Tools Used
Manual analysis
Recommended Mitigation Steps
Implement forceResumeReceive to as a last resort in case something happens.
Assessed type
Other