Vader Protocol contest - jonah1005's results

Handle

jonah1005

Vulnerability details

calculate Loss is vulnerable to flashloan attack

Impact

The VaderPool would compensate users' IL. The formula it uses to calculate lp value is vulnerable to manipulation.

The formula to calculate the lp value is similar to warp finance which is known to be unsafe. warpfinance-incident-root-cause-analysis (Please to refer to the POC section)

The Attacker can purchase an old lp position, manipulate price, take IL compensation and drain the reserve. I consider this is a high-risk issue.

Proof of Concept

VaderMath.sol#L69-L93

The lp value is calculated as [(A0 * P1) + V0] and // [(A1 * P1) + V1]. Assume that there's an ETH pool and there's 100 ETH and 100 Vader in the pool.

1. Attacker deposit 1 ETH and 1 Vader and own 1% of the liquidity.
2. Wait 1 year
3. Start flash loan and buy a lot ETH with 99900 Vader.
4. There's 0.1 ETH 100,000 Vader in the pool.
5. Burn 1 % lp at the price 1 ETH = 1,000,000 Vader.
6. A0 * P1 + V0 = 1 (eth) * 1,000,000 (price) + 100 (vader)
7. A1 * P1 + V1 = 0.001 (eth) * 1,000,000 (price) + 10,000 (vader)
8. IL compensation would be around 9891000.

Tools Used

None

Recommended Mitigation Steps

Please use the fair lp pricing formula from alpha finance instead. fair-lp-token-pricing

Handle

jonah1005

Vulnerability details

Impact

createPool is a permissionless transaction.

1. Anyone can create a token pool.
2. Token price is set by the first lp provider.
3. User can get a synthetic asset.

Assume a new popular coin that the DAO decides to add to the protocol. The attacker can create the pool and set it to be extremely cheap. (By depositing 1 wei coin and 10^18 wei Vader.) The attacker can mint a lot of synth by providing another 10^18 wei Vader.

There's no way to revoke the pool. The coin pool would be invalid since the attacker can drain all the lp in the pool.

I consider this is a high-risk issue.

Proof of Concept

VaderPoolFactory.sol#L43-L89 VaderPoolV2.sol#L115-L167

Tools Used

None

Recommended Mitigation Steps

Restrict users from minting synth from a new and illiquid pool. Some thoughts about the fix:

1. Decide minimum liquidity for a synthetic asset (e.g 1M Vader in the pool)
2. Once there's enough liquidity pool, anyone can deploy a synthetic asset after a cool down. (e.g. 3 days

The pool can remain permissionless and safe.

Handle

jonah1005

Vulnerability details

add liquidity is vulnerable to MEV

Impact

addLiquidity in the VaderRouter and VaderRouterV2 contract does not check the minimum liquidity amount. This makes users' funds vulnerable to sandwich attacks.

The team says a minimum amount is not required as the VaderPool supports imbalanced mint. However, imbalanced mint is a helper function of buying tokens and providing to lp. A sandwich attack would take over more than 50% of a transaction in an illiquid pool.

Given the current network environment, most transactions in the mempool would be sandwiched. However, users may avoid this attack if they only send tx through flashbot RPC. I consider this is a medium-risk issue.

Proof of Concept

VaderRouterV2.sol#L77-L96

That says a user wants to provide 1M ETH in the pool. Attackers can sandwich this trade as follows:

1. Buy Vader with 10M ETH and makes ETH extremely cheap
2. Put user's tx here User's tx would first buy a lot Vader and deposit to the pool.
3. Since ETH becomes even cheaper in the pool. The MEV attacker buyback ETH and get profit.

Tools Used

None

Recommended Mitigation Steps

Always check how much liquidity a user received in a transaction. A tx would not be sandwiched if it's not profitable.

We could learn a lot about MEV from Robert Miller'tweets.

Handle

jonah1005

Vulnerability details

Impact

The user would not get full IL compensation if there's not enough funds in the reserve. VaderReserve.sol#L76-L91

VaderReserve.sol#L85

        uint256 actualAmount = _min(reserve(), amount);

While this is reasonable, users should be able to specify the minimum received amount in the transaction. Otherwise, it's vulnerable to some kind of MEV attack.

I consider this is a medium-risk issue.

Proof of Concept

The user can not specify a minimum IL compensation in the router. VaderRouter.sol#L169-L207

The user may not receive the full amount of compensation. VaderReserve.sol#L76-L91

Tools Used

None

Recommended Mitigation Steps

Users should be able to protect themselves when burning lp.

Some possible fixes:

1. Return the actual amount this line reserve.reimburseImpermanentLoss(msg.sender, coveredloss);
2. Checks whether there's slippage. Revert if the user doesn't receive the full amount.

We can add a new parameter in the function.

    require(actualCompensation > minimumCompensation);

Or we can check the amountAMin after receiving the compensation. ( assume tokenA is native token)

    require(amountA +actualCompensation > amountAMin);

Handle

jonah1005

Vulnerability details

Impact

First lp provider received liquidity amount same as the nativeDeposit amount and decides the rate. If the first lp sets the pool's rate to an extreme value no one can deposit to the pool afterward. (please refer to the proof of concept section)

A malicious attacker can DOS the system by back-running the setTokenSupport and setting the pools' price to the extreme. I consider this is a medium-risk issue.

Proof of Concept

    deposit_amount = 1000 * 10**18
    get_token(dai, user, deposit_amount*3)
    get_token(vader, user, deposit_amount*3)
    dai.functions.approve(pool.address, deposit_amount*3).transact()
    link.functions.approve(pool.address, deposit_amount*3).transact()


    # deposit_amount = 1000 * 10**18

    # # first deposit 1 wei Dai and 1 vader to the pool
    router.functions.addLiquidity(dai.address, vader.address, 1, 10**18, user, 10**18).transact()
    print('received liquidity', pool.functions.positions(0).call()[2])
    # output log:
    # 1000000000000000000

    # normally deposit to the pool
    router.functions.addLiquidity(dai.address, vader.address, deposit_amount, deposit_amount, user, 10**18).transact()
    print('received liquidity', pool.functions.positions(1).call()[2])

    # output log:
    # 500000000000000000500000000000000000000

    # no one can deposit to the pool now
    # there would be revert

    router.functions.addLiquidity(dai.address, vader.address, 1, deposit_amount, user, 10**18).transact()

VaderMath.sol#L42

    ((totalPoolUnits * poolUnitFactor) / denominator) * slip

Since the scale of the total supply is (10**18)^2, the operation would overflow.

Tools Used

None

Recommended Mitigation Steps

Set a minimum deposit amount (both asset amount and native amount) for the first lp provider.