Platform: Code4rena
Start Date: 21/08/2023
Pot Size: $125,000 USDC
Total HM: 26
Participants: 189
Period: 16 days
Judge: GalloDaSballo
Total Solo HM: 3
Id: 278
League: ETH
Rank: 94/189
Findings: 1
Award: $90.63
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: juancito
Also found by: 0x3b, 0xmuxyz, 0xnev, ArmedGoose, Bauchibred, KrisApostolov, RED-LOTUS-REACH, Viktor_Cortess, ciphermarco, ginlee, ladboy233, mitko1111, nemveer
90.6302 USDC - $90.63
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L286-L295
This code contains a potentially dangerous bug that uses zero values for amountAmin
and amountBmin
in the contracts/reLP/ReLPContract.sol
contract's addLiquidity
function call, which can expose the transaction to front-running attacks and unpredictable outcomes, including impermanent loss.
The vulnerable code snippet is as follows:
(, , uint256 lp) = IUniswapV2Router(addresses.ammRouter).addLiquidity( addresses.tokenA, addresses.tokenB, tokenAAmountOut, amountB / 2, 0, // @audit 0 value for amountAmin 0, // @audit 0 value for amountBmin address(this), block.timestamp + 10 // @audit this means any deadline );
It's worth noting that block.timestamp + 10
is functionally equivalent to block.timestamp
, which is equivalent to having no deadline at all. However, the critical issue arises from setting amountAmin
and amountBmin
values to zero, which, when combined with a block.timestamp
deadline, allows for infinite slippage.
To exploit this vulnerability, an attacker could monitor pending transactions, observe this transaction, and submit a new adversarial transaction, causing the original transaction to receive fewer tokens than expected or acceptable.
Manual: code editor.
To mitigate the risks associated with this vulnerability, it is strongly recommended to specify meaningful non-zero values for amountAmin
and amountBmin
in the addLiquidity
function call. These values should be calculated based on the acceptable slippage and market conditions to protect against front-running attacks and reduce the potential for impermanent loss.
Here's an example of how to set non-zero values for amountAmin and amountBmin:
uint256 minTokenA = calculateMinAmount(); // Calculate a reasonable minimum amount. uint256 minTokenB = calculateMinAmount(); // Calculate a reasonable minimum amount. (, , uint256 lp) = IUniswapV2Router(addresses.ammRouter).addLiquidity( addresses.tokenA, addresses.tokenB, tokenAAmountOut, amountB / 2, minTokenA, minTokenB, address(this), block.timestamp + 10 );
By implementing these mitigation steps, the code will be more resistant to front-running attacks and will provide a more predictable outcome for liquidity provision.
MEV
#0 - c4-pre-sort
2023-09-07T12:37:26Z
bytes032 marked the issue as high quality report
#1 - c4-pre-sort
2023-09-07T12:37:30Z
bytes032 marked the issue as primary issue
#2 - bytes032
2023-09-07T12:38:05Z
It's worth noting that block.timestamp + 10 is functionally equivalent to block.timestamp, which is equivalent to having no deadline at all
That's OOS. The rest is correct.
#3 - c4-pre-sort
2023-09-11T07:50:00Z
bytes032 marked the issue as sufficient quality report
#4 - c4-pre-sort
2023-09-11T07:53:28Z
bytes032 marked the issue as duplicate of #1032
#5 - c4-judge
2023-10-15T19:21:23Z
GalloDaSballo marked the issue as satisfactory