Report #14849

Report Date

December 17, 2022

Status

Closed

Payout

Unchecked calldata

‣

Report Info

Report ID

#14849

Target

https://etherscan.io/address/0xb1bE0000bFdcDDc92A8290202830C4Ef689dCeaa

Report type

Smart Contract

Impacts

Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Has PoC?

Yes

Bug Description

the contract's pipe, multiPipe, and advancedPipe functions accept calldata as an input and pass it directly to the _pipe and _advancedPipe functions without any validation or sanitization. This could potentially allow an attacker to pass malicious calldata to the contract and execute arbitrary code or trigger unintended behavior.

Calldata is data that is passed to a contract function as an input and is used to encode function arguments and other data. In Solidity, calldata is an immutable type that represents a byte array that can be passed to a contract function as an argument. When calldata is passed to a contract function, it can be accessed and decoded using the abi.decode function or other decoding functions.

This means that if an attacker passes malicious calldata to the contract that includes a function call that transfers funds or assets from the contract, the contract could potentially lose funds as a result of the attack.

Recommendation

Here are some specific steps that can be taken to fix this issue:

Add input validation: The first step to fix this vulnerability is to add input validation to the pipe, multiPipe, and advancedPipe functions to ensure that the calldata passed to the contract is properly formatted and does not include any malicious code or data. This can be done using Solidity's require function or other validation methods to ensure that the calldata is in the correct format.
Sanitize calldata: After validating the calldata, it is important to sanitize the data to ensure that it does not include any malicious code or data. This can be done by using the abi.decode function or other decoding functions to properly decode the calldata and ensure that it does not include any malicious code or data.
Check the return values of external contract calls: In addition to validating and sanitizing calldata, it is also important to properly check the return values of external contract calls to ensure that the contract is behaving as intended and to prevent security vulnerabilities. To do this, the contract should check the return value of each external contract call and take appropriate action if the call fails or returns an unexpected value.

Proof of concept

Here is an example of how an attacker could exploit the unchecked calldata vulnerability in the pipe function:

pragma solidity =0.7.6;

import "./Pipeline.sol";

// Attacker contract that will pass malicious calldata to the target contract
contract Attacker {
    // Address of the target contract
    address target;

    // Constructor
    constructor(address _target) public {
        target = _target;
    }

    // Function to trigger the attack
    function attack() public {
        // Encode a malicious function call in calldata
        bytes memory maliciousData = abi.encodeWithSelector(
            bytes4(keccak256("arbitraryFunction()")),  // Function selector
            // Function arguments (none in this case)
        );

        // Call the target contract's `pipe` function with the malicious calldata
        Pipeline(target).pipe(maliciousData);
    }
}

To test this exploit, deploy the Pipeline contract and then deploy the Attacker contract, passing the address of the Pipeline contract as an argument. Then call the attack function of the Attacker contract to trigger the attack.

This exploit demonstrates how an attacker could pass malicious calldata to the pipe function of the Pipeline contract, potentially allowing the attacker to execute arbitrary code or trigger unintended behavior.

BIC Reponse

This is not a security bug report because the report outlines expected functionality. Pipeline was built with the philosophy that it is not the smart contract's role to protect users against misuse. Adding validation like suggested in the report would reduce gas efficiency. See the Risk section of the Pipeline whitepaper: https://evmpipeline.org/pipeline.pdf#section.6

Due to these reasons, we are closing the submission and no reward will be issued.