An attacker can repeatedly DoS SolConnector by sending maliciously deposit requests
Summary
If SolConnector::_lzReceive reverts for any reason (e.g when calling ledger.accountDepositSol), the Solana Endpoint outbound nonce will be desync'd with the SolConnector internal nonce checker.
This state can be repeatedly activated by the attacker by sending incorrect AccountDepositSol (vault_deposit_params on the Solana side) to the ledger.
Root Cause
Everytime a message is sent from solana-vault::deposit instruction through oapp::endpoint_cpi::send, the nonce.outbound_noncegets incremented on the endpoint.
The user can call the solana-vault::deposit a specific set of parameters that would make the call revert (e.g a wrong account_id) when executed by ledger.accountDepositSol
The user can call the solana-vault::deposit instruction with a token_amount == 0 allowing him to grief the protocol for low costs.
Internal pre-conditions
SolConnector::_lzReceive reverts when receiving the message, which do not increase the nonce on the destination chain
External pre-conditions
a message is sucessfully sent from Solana which increase the nonce on the source chain
Attack Path
A malicious user continuously craft reverting message to de-sync the nonces which DoS SolConnector, causing honest request to revert when processed. Every time inboundNonce is set back to a correct value the attacker can send a new malicious request.
Impact
Repeated/continous DoS of SolConnector
PoC
No response
Mitigation
Consider changing for an unordered delivery mechanism on SolConnector, or requesting a minimum deposit of token_amount in solana-vault::deposit
Silly Amber Shell
Medium
An attacker can repeatedly DoS
SolConnectorby sending maliciously deposit requestsSummary
If
SolConnector::_lzReceivereverts for any reason (e.g when callingledger.accountDepositSol), the Solana Endpoint outbound nonce will be desync'd with theSolConnectorinternal nonce checker. This state can be repeatedly activated by the attacker by sending incorrectAccountDepositSol(vault_deposit_paramson the Solana side) to the ledger.Root Cause
solana-vault::depositinstruction throughoapp::endpoint_cpi::send, thenonce.outbound_noncegets incremented on the endpoint.outbound_nonceattached to the packet to the destination chain.SolConnectorhas implemented an ordered delivery mechanism by requiring each new received message to be in sync with itsinboundNoncesolana-vault::deposita specific set of parameters that would make the call revert (e.g a wrongaccount_id) when executed byledger.accountDepositSolsolana-vault::depositinstruction with atoken_amount == 0allowing him to grief the protocol for low costs.Internal pre-conditions
SolConnector::_lzReceivereverts when receiving the message, which do not increase the nonce on the destination chainExternal pre-conditions
Attack Path
SolConnector, causing honest request to revert when processed. Every time inboundNonce is set back to a correct value the attacker can send a new malicious request.Impact
Repeated/continous DoS of
SolConnectorPoC
No response
Mitigation
Consider changing for an unordered delivery mechanism on
SolConnector, or requesting a minimum deposit oftoken_amountinsolana-vault::deposit