Dopex - ciphermarco's results

A rebate system for option writers in the Dopex Protocol.

General Information

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

Dopex

Findings Distribution

Researcher Performance

Rank: 94/189

Findings: 1

Award: $90.63

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Labels

bug
2 (Med Risk)
satisfactory
sufficient quality report
edited-by-warden
duplicate-1032

Awards

90.6302 USDC - $90.63

External Links

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L286-L295

Vulnerability details

Impact

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.

Proof of Concept

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.

Tools Used

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.

Assessed type

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

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter