Ordering Requirement of Nonces Leads to DoS on Orderly chain
Summary
Replay protection on Orderly is managed through an incrementing nonce (i.e., inbound_nonce) stored in the contract SolConnector. For any successful receive operation, the transaction must use the current nonce. Afterward, the nonce increments, blocking the same cross-chain transaction (CCTX) from being reprocessed.
The nonce must follow a strict increment sequence without skipping. Therefore, if a CCTX cannot be processed for any reason, it remains stuck, halting the processing of subsequent CCTXs.
Root Cause
In deposit.rs, vault_authority.deposit_nonce will be sent to the destination chain as a parameter in vault_deposit_params:
However, if the receive transaction fails on the destination chain, it prevents the increment of inboundNonce. Consequently, if any receive transaction reverts, all subsequent bridging transactions will also revert due to the mismatch between inboundNonce and _origin.nonce, causing DoS.
Internal pre-conditions
1- The orderDelivery boolean should be true in order to preserve the sequential nonce property. This requirement is met by default, since orderDelivery is set to true in initialize function:
The SolConnector contract can be functionality bricked by a simple transaction failing with the ordered nonce requirement. This could be done intentionally by a malicious actor or by accident from a user, resulting in a hight impact. The justification of a high vs. a medium is that user tokens can be stuck in the contract intentionally by an attacker since there is no revert and refund mechanism for users tokens if a transaction fails at destination chain.
PoC
No response
Mitigation
Implement the message receiving logic within a try-catch block to ensure the inboundNonce is incremented even if the message receiving logic fails. This approach prevents subsequent bridging transactions from being blocked, thereby avoiding potential DoS issues within the protocol.
Raspy Seaweed Bear
High
Ordering Requirement of Nonces Leads to DoS on Orderly chain
Summary
Replay protection on Orderly is managed through an incrementing nonce (i.e.,
inbound_nonce) stored in the contract SolConnector. For any successful receive operation, the transaction must use the current nonce. Afterward, the nonce increments, blocking the same cross-chain transaction (CCTX) from being reprocessed. The nonce must follow a strict increment sequence without skipping. Therefore, if a CCTX cannot be processed for any reason, it remains stuck, halting the processing of subsequent CCTXs.Root Cause
In
deposit.rs,vault_authority.deposit_noncewill be sent to the destination chain as a parameter invault_deposit_params:https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/solana-vault/packages/solana/contracts/programs/solana-vault/src/instructions/vault_instr/deposit.rs#L119-L140
At the destination chain, function
_lzReceiveis called with the message as parameter sent from the source chain. This function includes a condition to check if the nonce provided in the message match theinbound_noncein the contract: https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/sol-cc/contracts/SolConnector.sol#L53-L73However, if the receive transaction fails on the destination chain, it prevents the increment of
inboundNonce. Consequently, if any receive transaction reverts, all subsequent bridging transactions will also revert due to the mismatch betweeninboundNonceand_origin.nonce, causing DoS.Internal pre-conditions
1- The
orderDeliveryboolean should be true in order to preserve the sequential nonce property. This requirement is met by default, sinceorderDeliveryis set to true ininitializefunction:https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/sol-cc/contracts/SolConnector.sol#L46-L51
External pre-conditions
No response
Attack Path
No response
Impact
The SolConnector contract can be functionality bricked by a simple transaction failing with the ordered nonce requirement. This could be done intentionally by a malicious actor or by accident from a user, resulting in a hight impact. The justification of a high vs. a medium is that user tokens can be stuck in the contract intentionally by an attacker since there is no revert and refund mechanism for users tokens if a transaction fails at destination chain.
PoC
No response
Mitigation
Implement the message receiving logic within a try-catch block to ensure the
inboundNonceis incremented even if the message receiving logic fails. This approach prevents subsequent bridging transactions from being blocked, thereby avoiding potential DoS issues within the protocol.