Dria

Summary

In the LLM Oracle Coordinator contract of the Swan protocol, the request function contains a reentrancy vulnerability. This vulnerability arises because the function makes an external call to feeToken.transferFrom before updating critical state variables like nextTaskId. A malicious actor could exploit this vulnerability to re-enter the request function before the state is updated, potentially creating multiple tasks with the same taskId. This can lead to overwriting existing tasks, inconsistent contract state, and disruption of protocol operations, thereby affecting not only the attacker but also the integrity of the entire system and its users.

Vulnerability Detail

Contract Involved:

• LLMOracleCoordinator

Function Under Scrutiny:

Issue Description:

• External Call Before State Update:

  • The feeToken.transferFrom function is an external call that could potentially invoke untrusted or malicious code, especially if feeToken is a malicious token contract or implements hooks like ERC777.

  • Making this external call before updating the nextTaskId state variable violates the Checks-Effects-Interactions (CEI) pattern, a best practice in Solidity to prevent reentrancy attacks.

• Potential Reentrancy Attack:

  • Step 1: An attacker initiates a request by calling the request function.

  • Step 2: During the execution of feeToken.transferFrom, if feeToken is malicious or supports reentrancy (e.g., ERC777 tokens with hooks), it can re-enter the request function before nextTaskId is incremented.

  • Step 3: The re-entered request call passes the onlyValidParameters modifier and proceeds to transfer tokens again, using the same taskId since nextTaskId hasn't been incremented yet.

  • Step 4: This results in multiple tasks being created with the same taskId, leading to overwriting of tasks or inconsistent state within the contract.

Code Flow Breakdown:

1. Initial Call to request:

   • External call: feeToken.transferFrom(msg.sender, address(this), totalfee);

   • State not yet updated: nextTaskId remains the same.

2. Reentrant Call Triggered During External Call:

   • Re-enter request function.

   • External call: feeToken.transferFrom(msg.sender, address(this), totalfee);

   • nextTaskId still unchanged.

3. Outcome:

   • Both the original and reentrant calls use the same taskId.

   • Potential overwriting of task data or creation of duplicate tasks.

Impact

Severity: High

Potential Consequences:

1. State Inconsistencies:

   • Duplicate Task IDs: Multiple tasks with the same taskId can overwrite each other, leading to loss of task data or incorrect task processing.

   • Unpredictable Behavior: The contract may behave unpredictably when multiple tasks share the same ID, affecting the overall protocol's reliability.

2. Protocol Disruption:

   • Operational Failures: Overwritten tasks may fail to execute correctly, leading to failed asset purchases or incorrect state updates.

   • Financial Losses: Users relying on accurate task executions may suffer financial losses due to failed or manipulated transactions.

3. Exploitation Potential:

   • Resource Drain: Attackers can create multiple tasks, potentially draining protocol resources or disrupting service availability.

   • Collateral Exploits: If other parts of the protocol depend on unique taskIds, this vulnerability can cascade, affecting multiple functionalities.

4. Impact on Other Users:

   • Indirect Harm: Even though the attacker primarily affects their own registration attempts, the resulting state inconsistencies can negatively impact all users interacting with the protocol.

Tools Used

manual review

Recommendations

1. Implement the Checks-Effects-Interactions (CEI) Pattern.
2. Add Reentrancy Guards