TempleGold

Summary

TempleGold's cross-chain messaging implementation lacks a non-blocking receive method, which can lead to message queue blockages and potential Denial of Service (DoS) attacks. This vulnerability can severely impact the protocol's functionality and reliability across different chains.

Vulnerability Details

Impact

The absence of a non-blocking receive method in TempleGold's implementation of LayerZero messaging can result in:

1. Complete blockage of cross-chain communication between affected chains.

2. Vulnerability to low-cost DoS attacks.

3. Potential loss of user funds stuck in transit during a blockage.

4. Requirement for manual intervention to resolve blockages.

Root Cause

The vulnerability stems from three primary issues in the TempleGold protocol's implementation of LayerZero messaging:

Issue A. Unrestricted Gas Parameter Specification:
The protocol allows users to specify arbitrary gas parameters for cross-chain calls, contrary to best-practice guidelines.

Issue B. Lack of Non-Blocking Implementation in _lzReceive:
TempleGold does not implement a non-blocking pattern for its lzReceive function. This means that if a message fails to process (e.g., due to insufficient gas), it can block the entire message queue for that specific (source, destination) chain pair. The protocol doesn't handle the "in-blocking scenario," leaving the system vulnerable to prolonged disruptions.

Issue C. Incomplete Implementation of LayerZero Interface:
The protocol does not fully implement the ILayerZeroUserApplicationConfig interface as recommended by LayerZero. Specifically, the absence of functions like forceResumeReceive limits the protocol's ability to recover from blocked states without manual intervention at the LayerZero Endpoint level.

The main issue is the lack of a non-blocking receive method.

Proof of Concept

The vulnerability can be demonstrated conceptually:

1. An attacker sends a cross-chain message with intentionally low gas (e.g., gas limit set to 1).

2. This message fails to execute on the destination chain due to insufficient gas.

3. Due to the lack of a non-blocking receive method, this failure causes LayerZero to store the payload and block the message queue.

4. Subsequent legitimate messages fail with a "LayerZero: in message blocking" error.

5. The queue remains blocked until manual intervention through Endpoint::retryPayload().

The channel can only be unblocked through a manual call to Endpoint::retryPayload(); crucially, the TempleDao protocol team will need to bear the costs of this transaction.

Layer Zero provides a "get-out-of-jail-card" for these cases through its forceResumeReceive functionality. Unfortunately, because of Issue C, the protocol doesn't implement forceResumeReceive and thus has no other way to clear the channel without bearing the execution cost. This results in blocking the channel and communication loss.

The tx might failed for many other reasons, but the main issue is that the queue is blocked and no other messages can be processed.

Tools Used

Manual code review and understanding of LayerZero's cross-chain messaging mechanism.

Certainly. I'll modify the recommendations section to align with the structure and content you've provided. Here's the revised version:

Recommended Mitigation Steps

As this vulnerability stems from multiple root causes, we provide specific recommendations for each issue:

Issue A: Unrestricted Gas Parameter Specification

Layer Zero allows custom gas parameters to accommodate varying gas requirements across different chains. However, allowing users to set these parameters without validation exposes TempleGold to vulnerabilities related to cross-chain gas inequalities.

Recommendations:

1. Implement input validation in the TempleTeleporter and TempleGold contracts before initiating cross-chain calls:

   function validateGasParams(GasParams memory _gParams) internal view {

   require(_gParams.gasLimit >= MINIMUM_GAS_LIMIT, "Gas limit too low");

   // Additional checks as needed

   }

Issue B: Lack of Non-Blocking Implementation in lzReceive

he current implementation is designed to never allow failures from the Layer Zero Endpoint as it implements a non-blocking pattern. Due to Issue A the lzReceive call from Endpoint can be forced to fail. This blocks the message channel, violating the intended non-blocking pattern (and giving rise to this issue).

Consider inheriting from the Layer Zero non-blocking app example.

Issue C: Incomplete Implementation of LayerZero Interface

It is highly recommended to implement the ILayerZeroApplicationConfig as it provides access to forceResumeReceive in the case of a channel blockage and allows the protocol to resume communication between these two chains. Most importantly, it will allow the team to resume messaging at a fraction of what it might cost to call retryPayload.