Report #33969

Report ID

#33969

Report type

Smart Contract

Has PoC?

Yes

Target

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

Impacts

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Note, this is a submission of a similar bug report from before, but only on a different condition that an attacker may be able to do. Since, dilligently mentioned before, integer overflows and underflows will in fact revert for any operations for the most part in the solidity, this issue focuses on zeroing out the reserves rather than causing an underflow, preventing reverts.

Brief/Intro

Essentially an attacker can obtain an AmountOut that would be just enough to zero out the reserve that other users have contributed to, which can impact the overall protocol for that pool.

Vulnerability Details

In Well.sol, there isn't any checks to make sure the AmountOut can't exceed the Reserve Amount, With logic denoting AmountOut from user transfers.

Lines 207-217

function swapFrom( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline ) external nonReentrant expire(deadline) returns (uint256 amountOut) { fromToken.safeTransferFrom(msg.sender, address(this), amountIn); amountOut = _swapFrom(fromToken, toToken, amountIn, minAmountOut, recipient); }

Now since AmountOut is set via Swapfrom, an attacker can initiate (assuming that the amountout is far more than the reserve) the function SwapIn.

on Lines 336-348

function getSwapIn( IERC20 fromToken, IERC20 toToken, uint256 amountOut ) external view readOnlyNonReentrant returns (uint256 amountIn) { IERC20[] memory _tokens = tokens(); (uint256 i, uint256 j) = _getIJ(_tokens, fromToken, toToken); uint256[] memory reserves = _getReserves(_tokens.length);

reserves[j] -= amountOut;

amountIn = _calcReserve(wellFunction(), reserves, i, totalSupply()) - reserves[i];

} This has no checks for AmountOut, and amountOut can be freely called from its initialization from Swapfrom. Called again, the AmountOut which > Reserves and be subtracted from reserves from 2nd function (SwapIn) without any checks to make sure the reserves aren't impacted by an attackers AmountOut that can zero out the reserves potentially that other users have added to.

Impact Details

The impact would primarily be to the users who've contributed to the protocol, causing damage to the overall reserves, but the attacker wouldn't necessarily benefit.

References

https://etherscan.io/address/0xBA51AAAA95aeEFc1292515b36D86C51dC7877773?utm_source=immunefi#code

Proof of concept

Same as before, based on different premise of vulnerability;

Attacker.Sol

// SPDX-License-Identifier: MIT pragma solidity ^0.8.4;

pragma solidity ^8.20;

//Where an attackers AmountOut > Reserve.

interface Well {

//attacker obtains an AmountOut greater than the reserves

function swapFromFeeOnTransfer( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline) external nonReentrant expire(deadline) returns (uint256 amountOut);

// Attacker utilizes this function to cause reserve damages. function getSwapIn( IERC20 fromToken, IERC20 toToken, uint256 amountOut ) external view readOnlyNonReentrant returns (uint256 amountIn);

}

contract Well { address immutable Well2 = 0xBA51AAAA95aeEFc1292515b36D86C51dC7877773;

Well2 Well = Well2(Well);

Well2.swapFromFeeOnTransfer( IERC20 fromToken, IERC20 toToken, uint256 amountIn, uint256 minAmountOut, address recipient, uint256 deadline)

Well2.getSwapIn( IERC20 tokenOut, uint256 minAmountOut, address recipient ) external nonReentrant returns (uint256 amountOut);

}