## Summary The `get_multiple_accounts` RPC method in `svm-rollup-cantina/crates/svm/src/rpc/mod.rs` accepts a vector of public keys (`pubkeys`) without enforcing any limit on its size. This allows a potential attacker to submit a request with a massive number of keys, causing the RPC node to consume excessive CPU and I/O resources while fetching the accounts from state, which can degrade performance or lead to a minor Denial of Service. ## Finding Description The implementation of the `get_multiple_accounts` method iterates through the user-provided vector of keys without any length checks: ```rust #[rpc_method(name = "getMultipleAccounts")] pub fn get_multiple_accounts( &self, pubkeys: Vec, config: Option, state: &mut ApiStateAccessor, ) -> RpcResult>>> { // VULNERABLE LOOP: Iterates over a user-controlled vector `pubkeys` of any size. pubkeys .into_iter() .map(|pubkey| { self.get_account_info(pubkey, config.clone(), state) .map_err(|e| { create_client_error(&format!("Account with pubkey {pubkey} not found: {e}")) }) .map(|res| res.value) }) .collect::>>>() .and_then(|r| self.to_response(r, state)) } ``` A malicious user can craft a request containing millions of public keys. The node will dutifully attempt to process each one, leading to significant resource consumption. ## Impact Explanation The impact of this vulnerability is resource exhaustion on the RPC node. While modern JSON-RPC servers often have a global request size limit that might indirectly mitigate this, relying on this is not robust. A direct application-level limit is necessary. - **CPU and I/O Spikes:** A request with a very large number of keys will cause a spike in CPU usage and disk I/O as the node reads from its state database. - **Performance Degradation:** This can significantly slow down the RPC node, increasing latency for all other users. - **Minor Denial of Service:** While less severe than a crash, this can make the node unresponsive for a period, effectively a temporary DoS. Because this attack vector is limited by global server configurations and results in performance degradation rather than a crash, its severity is rated as **Low**. ## Likelihood Explanation The vulnerability is present in the code and can be triggered by a single RPC call. However, the impact is less severe than other DoS vulnerabilities. The likelihood is **Low**. ## Proof of Concept 1. Craft a JSON-RPC request for the `getMultipleAccounts` method containing a large array of public keys (e.g., 100,000). 2. Send this request to a Solaxy RPC node. 3. **Observe the CPU and memory usage of the node process.** Note a significant spike in resource consumption that corresponds to the processing of the request. 4. While the request is being processed, attempt to send other, legitimate requests to the node and observe increased latency. ## Recommendation Introduce a reasonable, application-level limit on the number of public keys that can be requested in a single `get_multiple_accounts` call. A limit of 100, similar to what is used in other Solana RPC implementations, is a sensible choice. ```rust const MAX_GET_MULTIPLE_ACCOUNTS_LIMIT: usize = 100; #[rpc_method(name = "getMultipleAccounts")] pub fn get_multiple_accounts( &self, pubkeys: Vec, config: Option, state: &mut ApiStateAccessor, ) -> RpcResult>>> { if pubkeys.len() > MAX_GET_MULTIPLE_ACCOUNTS_LIMIT { return Err(create_client_error(&format!( "Request limit {} is greater than {}", pubkeys.len(), MAX_GET_MULTIPLE_ACCOUNTS_LIMIT ))); } pubkeys .into_iter() .map(|pubkey| { // ... (rest of the function) }) .collect::>>>() .and_then(|r| self.to_response(r, state)) } ``` This prevents abuse of the endpoint while still providing sufficient functionality for legitimate use cases.

hecok

Biography

Top competitions