Dria

Relevant Context

The LLMOracleCoordinator contract handles LLM generation requests, responses, and validations. Both the respond() and validate() functions, which are called directly by oracles in response to a request, call assertValidNonce(), which processes the task input data in memory.

Finding Description

The request() function lacks input size validation for the input parameter. This allows malicious users to submit extremely large input payloads that will be processed in memory during both generation and validation phases through the assertValidNonce() function.

The issue stems from the following line in assertValidNonce():

The processing of large inputs results in significant memory allocations with quadratic cost scaling. Since the entire input must be loaded into memory for each generator and validator processing the task, the gas costs become prohibitively expensive relative to the reward fees. This creates an economic imbalance where oracles are forced to spend substantially more on gas than they can earn from task participation.

The attack becomes even more devastating when considering that an attacker can submit multiple large-input requests in rapid succession by directly calling the request() method or trough the BuyerAgent interface. The attacker can chain together numerous requests with massive input sizes, forcing almost all oracle nodes in the network to process some of these malicious request. This creates a multiplicative drain on oracle funds - ultimately allowing an attacker to systematically drain the entire oracle network's funds through accumulated gas fees while only paying the standard request costs themselves. And become one of the only node to validate or/generate task, allowing easier manipulation of output task.

Impact Explanation

High. This vulnerability can be exploited to:

1. Drain generator and validator balances through excessive gas costs

2. Make the protocol economically unsustainable as oracles lose money processing malicious requests

3. Effectively deny service to legitimate users as oracles become unwilling to process tasks

Likelihood Explanation

High. The attack is:

1. Easy to execute - just requires submitting a large input

2. Cheap for the attacker - they only pay the initial request fee

3. Highly profitable - can force multiple oracles to spend significant gas

Recommendation

Implement a maximum size limit for the input parameter in the request() function:

The MAX_INPUT_SIZE constant should be set to a value that:

1. Is large enough for legitimate use cases

2. Results in reasonable gas costs for oracles

3. Ensures profitability for oracle operators

Consider setting this limit around 32-64KB initially and adjusting based on network usage patterns.