Dria

Swan
NFTHardhat
21,000 USDC
View results
Submission Details
Severity: low
Valid

Lack of Input Validation in request() function in the LLMOracleCoordinator.sol Weakening Proof-of-Work Security

Summary

In the LLMOracleCoordinator.sol contract, the request() function currently does not validate the input parameter to ensure it is non-empty, despite a documented assumption that input must contain data. This oversight compromises the reliability of the Proof-of-Work (PoW) mechanism by introducing predictability into the nonce validation process. If left unchecked, it allows for potential manipulation of task requests and validations, which undermines the security and reliability of the PoW scheme.

Vulnerability Details

The LLMOracleCoordinator contract coordinates the task requests for LLM generation and response validations. However, a critical vulnerability exists in the request() function, where the input parameter is accepted without validation. This lack of validation can allow empty or trivially simple inputs, significantly weakening the effectiveness of the Proof-of-Work (PoW) mechanism.

The PoW mechanism, implemented in the assertValidNonce function, relies on input via task.input to calculate a unique hash for each task. Without validation, an attacker can submit tasks with empty or overly simplistic input values, reducing the computational cost required to generate a valid nonce. This can lead to spam attacks, decreased task processing efficiency, and potential denial of service for legitimate requests.

Vulnerable Code Snippet :

The code within the request() function in the LLMOracleCoordinator.sol contract lacks a check to enforce a non-empty input parameter despite documenting that "Input must be non-empty" :

/// @notice Request LLM generation.
/// @dev Input must be non-empty.
/// @dev Reverts if contract has not enough allowance for the fee.
/// @dev Reverts if difficulty is out of range.
/// @param protocol The protocol string, should be a short 32-byte string (e.g., "dria/1.0.0").
/// @param input The input data for the LLM generation.
/// @param parameters The task parameters
/// @return task id
function request(
bytes32 protocol,
bytes memory input,
bytes memory models,
LLMOracleTaskParameters calldata parameters
) public onlyValidParameters(parameters) returns (uint256) {
// Fee and allowance checks omitted for brevity
uint256 taskId = nextTaskId;
unchecked {
++nextTaskId;
}
emit Request(taskId, msg.sender, protocol);
// The `input` value is accepted without validation here
requests[taskId] = TaskRequest({
requester: msg.sender,
protocol: protocol,
input: input,
parameters: parameters,
status: TaskStatus.PendingGeneration,
generatorFee: generatorFee,
validatorFee: validatorFee,
platformFee: platformFee,
models: models
});
emit StatusUpdate(taskId, protocol, TaskStatus.None, TaskStatus.PendingGeneration);
return taskId;
}
}

The absence of validation allows for a trivial input, which impacts the PoW in assertValidNonce:

function assertValidNonce(uint256 taskId, TaskRequest storage task, uint256 nonce) internal view {
bytes memory message = abi.encodePacked(taskId, task.input, task.requester, msg.sender, nonce);
if (uint256(keccak256(message)) > type(uint256).max >> uint256(task.parameters.difficulty)) {
revert InvalidNonce(taskId, nonce);
}
}

The assertValidNonce function calculates the PoW hash using task.input. If input is empty or predictable, the PoW complexity is reduced, making it easier for an attacker to find a valid nonce.

Impact

The absence of strict input validation weakens the PoW scheme, allowing tasks to bypass intended computational difficulty. This has significant impacts:

  1. Increased Spam Requests and System Performance Degradation: Without input validation, attackers can issue low-effort tasks, leading to an increase in spam or abusive requests. This could clog the request queue, consuming processing resources and slowing the system’s responsiveness for legitimate tasks. Over time, this may degrade user experience as system capacity is consumed by trivial requests.

  2. Reduced Deterrence and PoW Effectiveness: The lowered PoW difficulty makes it easier for attackers to bypass computational costs, discouraging legitimate users from participating. In an environment with high adoption, this could undermine the fairness of task handling, leading to reliability issues and potential reputational damage.

Tools Used

Manual Review

Recommendations

To prevent this, a validation check should be added to ensure input is non-empty. This will enforce a minimal entropy requirement, preserving the PoW difficulty:

require(input.length > 0, "Input data must be non-empty");

This check should be added at the beginning of the request() function in the LLMOracleCoordinator.sol contract to prevent tasks with empty input values.

Updates

Lead Judging Commences

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Validated
Assigned finding tags:

No validation of input and models in `request` function

Support

FAQs

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