TempleGold
TempleDAO
Foundry
25,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Cross-Chain GAS Message Manipulation Leading to Protocol-Wide DoS

Beyond Audit

Lines of code

https://github.com/TempleDAO/temple/blob/templegold/protocol/contracts/templegold/TempleTeleporter.sol#L62-L72
https://github.com/TempleDAO/temple/blob/templegold/protocol/contracts/templegold/TempleGold.sol#L308-L332

Vulnerability details

Summary

In the TempleTeleporter and TempleGold contracts, the teleport and send functions, respectively, allow the sender to specify the gas amount for message execution on the destination chain. There is no minimum gas limit enforced for these cross-chain calls.

An attacker can exploit this by sending multiple transactions with very low gas limits, blocking cross-chain communication pathways between all chains in the TempleGold ecosystem.

Proof of Concept

LayerZero's send function allows the sender to specify the gas amount for message execution on the destination chain. This configuration is specified in the options parameter for TempleTeleporter and in the _fee parameter for TempleGold.

Both TempleTeleporter.sol and TempleGold.sol use the _lzSend function without enforcing a minimum gas limit:

// TempleTeleporter.sol
receipt = _lzSend(dstEid, _payload, options, MessagingFee(msg.value, 0), payable(msg.sender));
​
// TempleGold.sol
msgReceipt = _lzSend(_sendParam.dstEid, message, options, _fee, _refundAddress);

An attacker can exploit this by:

  1. Calling the teleport function in TempleTeleporter or send function in TempleGold multiple times.

  2. Specifying a very low gas limit (e.g., 5k gas) in the options or _fee parameter for each call.

These transactions will succeed on the source chain but fail on the destination chain due to insufficient gas, resulting in blocked message pathways.

Attack scenario

  1. The attacker calls the teleport or send function multiple times on any chain.

  2. For each call, they set the gas limit to a very low value (e.g., 5k gas) in the relevant parameter.

  3. The transactions are executed on the source chain and delivered to the destination chain.

  4. On the receiving chain, the transactions revert due to "out of gas" errors during execution.

  5. The revert is caught inside the lzEndpoint catch block resulting in StoredPayload and blocking the pathway

Impact

This vulnerability allows an attacker to potentially block cross-chain communication pathways between all chains in the TempleGold ecosystem. By manipulating the gas parameters in cross-chain calls, an attacker can, with low cost and high frequency, block the pathway between any two chains, rendering the whole system unusable and potentially locking user funds.

Tools Used

  • Manual review

  • LayerZero documentation

Recommendation

Implement a minimum gas threshold for all LayerZero message sends:

uint256 constant MIN_GAS_LIMIT = 100000; // Adjust based on the minimal gas required for cross-chain message execution
​
// For TempleTeleporter.sol
function teleport(
uint32 dstEid,
address to,
uint256 amount,
bytes calldata options
) external payable override returns(MessagingReceipt memory receipt) {
// ... existing code ...
​
uint256 gasLimit = extractGasLimit(options);
require(gasLimit >= MIN_GAS_LIMIT, "Gas limit too low");
​
receipt = _lzSend(dstEid, _payload, options, MessagingFee(msg.value, 0), payable(msg.sender));
}
​
// For TempleGold.sol
function send(
SendParam calldata _sendParam,
MessagingFee calldata _fee,
address _refundAddress
) external payable virtual override(IOFT, OFTCore) returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt) {
// ... existing code ...
​
uint256 gasLimit = extractGasLimit(_fee);
require(gasLimit >= MIN_GAS_LIMIT, "Gas limit too low");
​
msgReceipt = _lzSend(_sendParam.dstEid, message, options, _fee, _refundAddress);
// ... rest of the function ...
}
​
function extractGasLimit(bytes memory options) internal pure returns (uint256) {
// Implementation depends on how options are encoded
}

Consider implementing a mechanism to retry failed messages with increased gas to prevent permanent blocking.

Assessed type

Denial of Service (DoS)

Updates

Lead Judging Commences

inallhonesty Lead Judge
about 1 year ago
inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

Not using the Non-Blocking Implementation might get the teleporter stuck

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.