Full Report
In the first part, the author goes over how the EVM part of Layer Zero works. In this part, they go over some bugs that they found within the ecosystem. Being able to shut down an individual cross chain message arbitrarily is a rather bad issue. Not only as a single user but since things must be done sequentially on LZ, being able to force a transaction to revert could block the whole setup. On a crosschain swap, the developers consider the scenario where transaction reverts by handling it within a try/catch block. So, even if this reverts, it should be able to handle it. But, Trust has an interesting piece of insight on this! If the call to a contract is made but address is NOT a contract that exists then the try/catch block of code will NOT handle it properly. Instead, the transaction will simply revert. This leads to a persistent DoS attack, since it will block transactions occurring afterwards. The developers thought of this situation occurring. So, they have function that will remove a transaction from the queue when this happens. Sadly for Trust, this was fixed at a different layer of the stack that they had not seen and was found internally by the team. Looking at the same code they wanted to force a revert in a different way. If the try/catch was correct so they turned to gas related attacks. When executing an external call, the user pays a fixed 175000 gas. First, they tried a return data bomb attack. This is when the copying of the reason for the external call eats up a ton of gas. In this case, it wasn't possible because to eat up all of this gas in this case. What they did realize was that the failure case was copying the payload into storage. Since every zero to non-zero storage costs 22.1K gas. The payload was capped to 10K at the LZ level for a total of 313 operations or 7M gas. To attack this, we would send a swap with a very large payload then have it fail. To unDoS this a relayer would need to pay 7M gas, which is a lot. Once again, the development team had found the vulnerability internally then sent it to people doing an audit. To fix the vulnerability they added some middleware to the router call that protections against many of these gas spending edge cases. The check appears to be within some router code, which is extremely strange place to put it. Overall, it was interesting reading about various gas denial of service techniques. It's a bummer that neither of these bugs panned out for Trust but I believe in part 3 they get something.
Analysis Summary
# Vulnerability: Stargate Protocol Persistent Denial of Service (DoS)
## CVE Details
- **CVE ID**: N/A (Disclosed via bug bounty/internal discovery)
- **CVSS Score**: High (Estimated 7.5 - 8.5)
- **CWE**: CWE-755 (Improper Handling of Exceptional Conditions), CWE-400 (Uncontrolled Resource Consumption)
## Affected Systems
- **Products**: Stargate Protocol (Liquidity layer for LayerZero)
- **Versions**: Versions prior to March 2024 updates
- **Configurations**: Cross-chain bridge channels utilizing LayerZero’s `lzReceive` and the Stargate `Router`.
## Vulnerability Description
Analysis identified two distinct vectors for causing a persistent Denial of Service (DoS) on Stargate bridge channels:
1. **Try/Catch Bypass via Non-Contract Addresses**: In Solidity, if an external call is made to an address that contains no code (EOA or undeployed contract) within a `try/catch` block, the execution reverts immediately without entering the `catch` block. Because LayerZero requires sequential message processing, a revert at the Bridge level blocks all subsequent messages in that specific channel.
2. **Gas Consumption (Storage Bombing)**: Attackers could exploit the failure state of a transaction. When a cross-chain call fails, the protocol attempts to store the payload in state. By sending a maximum-sized payload (10K bytes) that is designed to fail, an attacker forces the Relayer to perform hundreds of zero-to-non-zero storage writes (SSTORE). This can exhaust gas limits or make the cost of "unblocking" the queue (approx. 7 million gas) prohibitively expensive for relayers.
## Exploitation
- **Status**: PoC available (Internal/Researcher identified); mitigated by developers before external exploitation.
- **Complexity**: Low to Medium
- **Attack Vector**: Network (Cross-chain message initiation)
## Impact
- **Confidentiality**: None
- **Integrity**: None
- **Availability**: **High**. Success results in the permanent freezing of specific Bridge-to-Bridge communication channels, preventing all users from completing swaps or liquidity transfers until manual intervention.
## Remediation
### Patches
- **MPTValidator Update**: LayerZero updated the validation library to check for contract existence before attempting calls.
- **Relayer Middleware**: A new Relayer was deployed to validate payloads and destination addresses (e.g., ensuring calls go through the "Composer" contract).
- **Router Gas Protections**: Implementation of logic to store a **hash** of the payload rather than the full data during failure states to prevent storage-based gas exhaustion.
### Workarounds
- **ForceResumeReceive**: Administrators can manually call `forceResumeReceive` on the LayerZero Endpoint to skip a blocking message, though this is a reactive measure and susceptible to back-running by an attacker.
## Detection
- **Indicators of Compromise**: Repeated reverts in `lzReceive` transactions; large payloads (up to 10KB) targeting non-contract addresses.
- **Detection Methods**: Monitor for `Bridge` contract reverts on destination chains and track sudden spikes in gas costs for `sgReceive` operations.
## References
- **Vendor**: hxxps[://]stargate[.]finance/
- **Research**: hxxps[://]www[.]trust-security[.]xyz/post/learning-by-breaking-a-layerzero-case-study-part-two
- **LayerZero Repository**: hxxps[://]github[.]com/LayerZero-Labs/LayerZero