Illuminate contest - dipp's results

Lines of code

Lender.sol#L192-L235 Lender.sol#L486-L534 Lender.sol#L545-L589

Vulnerability details

Impact

Some of the lend functions do not validate addresses sent as input which could lead to a malicous user being able to mint more PT tokens than they should.

Functions affect:

• Illuminate and Yield lend function.

• Sense lend function.

• APWine lend function.

Proof of Concept

In the Illuminate and Yield lend function:

1. Let the Yieldspace pool y be a malicious contract that implements the IYield interface.

2. The base and maturity functions for y may return any value so the conditions on lines 208 and 210 are easily passed.

3. The caller of lend sends any amount a for the desired underlying u.

4. If principal token p corresponds to the Yield principal, then the yield function is called which has a return value controlled by the malicious contract y.

5. The mint function is then called for the principal token with an underlying u and a maturity m which will then mint the returned amount of principal tokens to the malicious user.

In the Sense lend function:

1. Let the amm x input variable be a malicous contract that implements the ISense interface.

2. The malicious user sends any amount of underlying to Lender.sol.

3. Since the amm isn't validated, the swapUnderlyingForPTs function can return any amount for returned that is used to mint the Illuminate tokens.

4. The malicious user gains a disproportionate amount of PT.

In the APWine lend function:

1. Let the APWine pool input variable be a malicous contract that implements the IAPWineRouter interface.

2. The malicious user sends any amount of underlying to Lender.sol.

3. The swapExactAmountIn function of the malicious pool contract returns any amount for returned.

4. The mint function is called for the PT with underlying u and maturity m with the attacker controlled returned amount.

Recommmended Mitigation Steps

Consider validating the input addresses of y, x and pool through a whitelisting procedure if possible or validating that the returned amounts correspond with the amount of PT gained from the protocols by checking the balance before and after the PTs are gained and checking the difference is equal to returned.

Lines of code

Redeemer.sol#L193

Vulnerability details

Impact

The maxRedeem function is a view function which only returns the balance of the Redeemer.sol contract. After this value is obtained, the PT is not redeemed from Notional. The user will be unable to redeem PT from Notional through Redeemer.sol.

Proof of Concept

Notional code:

    function maxRedeem(address owner) public view override returns (uint256) {
        return balanceOf(owner);
    }

Recommmended Mitigation Steps

Call redeem from Notional using the amount from maxRedeem as the shares input after the call to maxRedeem.

1. Setting a new admin should be a 2-step process

Line References

Lender.sol#L129-L132

Impact

If the incorrect address is mistakenly supplied to setAdmin, the Lender.sol contract would be completely compromised since functions such as approve could cause a lot of damage.

Recommmended Mitigation Steps

Consider using a proposeAdmin function that sets a pending admin and a acceptAdminfunction for the pending admin to accept the admin role.

2. Element pool e is not validated

Line References

Lender.sol#L362

Impact

A user can pass a malicious contract e into the element lend function which returns any amount. The returned purchased amount is then emitted and returned by the lend function. This could lead to undesirable behaviour depending on how the emitted and return values are used.

Recommmended Mitigation Steps

Check the amount of PT gained from the swap by comparing the purchased value to the difference in balance before and after the swap.