Beanstalk Notion
Beanstalk Notion
/
🪲
Bug Reports
/
BIC Notes
/
📄
Report #34352
📄

Report #34352

Report Date
August 9, 2024
Status
Closed
Payout

Improper Initialization of Reserves

‣
Report Info

Report ID

#34352

Report type

Smart Contract

Has PoC?

Yes

Target

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

Impacts

Temporary freezing of funds for at least 1 hour

Description

The _init function in the MultiFlowPump contract is responsible for initializing the reserves for a given slot. However, the function contains a critical flaw where it returns early if any reserve in the reserves array is 0. This can leave the contract in an inconsistent state, leading to unexpected behavior and potential issues in subsequent operations.

Code snippet:

Detailed Analysis:

Initialization Check:

  • The function iterates through the reserves array.
  • If any reserve value is 0, the function returns early without completing the initialization.
  • This premature return prevents the reserves from being stored properly.

Impact:

  • If the initialization is aborted, the contract may not store the correct initial state.
  • Subsequent calls to functions that rely on the initialized state may fail or produce incorrect results.
  • This can lead to unexpected behavior and potential loss of funds or incorrect oracle data.

Related Code: The update function calls _init if the last timestamp is 0 (indicating the pump has never been used before).

Mitigations

Remove Early Return: Instead of returning early if a reserve is 0, handle the 0 value appropriately.

Add Validation: Ensure that the reserves array passed to _init does not contain any 0 values before calling the _init function.

By removing the early return or adding validation to ensure no reserves are 0, you can mitigate this issue and maintain the integrity and security of the contract.

Proof of concept

  1. Call the update function with a reserves array that includes a 0 value.
  2. Verify that the contract does not properly initialize the reserves, leading to incorrect behavior in subsequent calls.

Exploitation Scenario

  1. A malicious actor could call the update function with a reserves array containing a 0 value.
  2. This would cause the _init function to return early, leaving the contract in an uninitialized state.
  3. Subsequent operations relying on the initialized state may fail, leading to unexpected behavior or potential loss of funds.

Impact Justification

Impact: Temporary freezing of funds for at least 1 hour

Reasoning:

  • The vulnerability can lead to the contract being in an inconsistent state, causing subsequent operations to fail.
  • This can result in temporary freezing of funds as the contract is unable to process transactions correctly until the issue is resolved.
  • The issue does not lead to permanent freezing or direct theft of funds, but it can cause significant disruption and potential loss of funds due to incorrect behavior in subsequent calls.

Immunefi Response

After reviewing your report, we have decided to close it due to the absence of a PoC.

Our review found that:

  • assessed impact by the triage team is in scope for the bug bounty program
  • assessed asset by the triage team is in scope for the bug bounty program
  • No working PoC was submitted with the report
  • As per the program policy, A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.

We take the triaging of submissions seriously at Immunefi, and our process involves checking the PoC to see if it matches the assessed impact and bug description, as well as verifying the accuracy of the whitehat's claims.

Please note that the Project's team will receive a report of the closed submission and may choose to re-open it at their discretion. However, they are under no obligation to do so.

function _init(bytes32 slot, uint40 lastTimestamp, uint256[] memory reserves) internal {
    uint256 numberOfReserves = reserves.length;
    bytes16[] memory byteReserves = new bytes16[](numberOfReserves);

    for (uint256 i; i < numberOfReserves; ++i) {
        uint256 _reserve = reserves[i];
        if (_reserve == 0) return; // This line can cause premature return
        byteReserves[i] = _reserve.fromUIntToLog2();
    }

    // Write: Last Timestamp & Last Reserves
    slot.storeLastReserves(lastTimestamp, byteReserves);

    // Write: EMA Reserves
    uint256 numSlots = _getSlotsOffset(numberOfReserves);
    assembly {
        slot := add(slot, numSlots)
    }
    slot.storeBytes16(byteReserves); // EMA Reserves
}
function update(uint256[] calldata reserves, bytes calldata) external {
    uint256 numberOfReserves = reserves.length;
    PumpState memory pumpState;

    // All reserves are stored starting at the msg.sender address slot in storage.
    bytes32 slot = _getSlotForAddress(msg.sender);

    // Read: Last Timestamp & Last Reserves
    (, pumpState.lastTimestamp, pumpState.lastReserves) = slot.readLastReserves();

    // If the last timestamp is 0, then the pump has never been used before.
    if (pumpState.lastTimestamp == 0) {
        _init(slot, uint40(block.timestamp), reserves);
        return;
    }

    // Continue with the update logic...
}