code-423n4 / 2022-06-yieldy-findings

0 stars 0 forks source link

QA Report #267

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

1. Migration incorrect interface

Impact

Contract Migration implements function moveFundsToUpgradedContract that is expected to move funds from OLD_CONTRACT to NEW_CONTRACT. The issue is that for withdrawing funds it uses instantUnstake that does not exist in Staking contract. Contract Staking implements instantUnstakeReserve and instantUnstakeCurve, while instantUnstake is being implemented by LiquidityReserve.

Proof of Concept

Migration.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to use ILiquidityReserve interface for OLD_CONTRACT and make sure that OLD_CONTRACT is a LiquidityReserve contract.

2. Missing threshold validation

Risk

Low

Impact

Contract Staking implements multiple functions for setting staking parameters. The issue is that these functions are missing basic threshold checks of received arguments which makes it risky that, either by accident or intentionally, the parameters will be set to values that will completely break Staking contract logic.

Proof of Concept

Staking.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to add threshold checks for listed parameters.

3. Missing approve(0) first

Risk

Low

Impact

Some tokens (like USDT L199) do not work when changing the allowance from an existing non-zero allowance value. They must first be approved by zero and then the actual allowance must be approved.

IERC20(token).approve(address(operator), 0);
IERC20(token).approve(address(operator), amount);

Proof of Concept

Staking.sol:

LiquidityReserver.sol:

Migration.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

Approve with a zero amount first before setting the actual amount.

4. Missing events

Risk

Low

Impact

Multiple contracts are not implementing events for critical functions. Lack of events makes it difficult for off-chain applications to monitor the protocol.

Proof of Concept

Staking.sol:

LiquidityReserve.sol:

Migration.sol:

BatchRequests.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to add missing events to listed functions.

5. Missing zero address checks

Risk

Low

Impact

Multiple contracts do not check for zero addresses which might lead to loss of funds, failed transactions and can break the protocol functionality.

Proof of Concept

Staking.sol:

LiquidityReserve.sol:

BatchRequests.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to add zero address checks for listed parameters.

6. Critical address change

Risk

Low

Impact

Changing critical addresses such as ownership should be a two-step process where the first transaction (from the old/current address) registers the new address (i.e. grants ownership) and the second transaction (from the new address) replaces the old address with the new one. This gives an opportunity to recover from incorrect addresses mistakenly used in the first step. If not, contract functionality might become inaccessible.

Proof of Concept

Staking.sol:

LiquidityReserve.sol:

BatchRequests.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to implement two-step process for changing ownership.

7. Use max values

Risk

Non-Critical

Impact

Contract YieldStorage.sol uses bit negation to retrieve MAX_UINT256 and MAX_SUPPLY (max uint128), these values can be easily retrieved from type object.

(..)
    uint256 internal constant MAX_UINT256 = ~uint256(0);

    uint256 internal constant MAX_SUPPLY = ~uint128(0); // (2^128) - 1
(..)

Proof of Concept

YieldyStorage.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to use type(uint256).max and type(uint128).max respectively.

8. Use scientific notation

Risk

Non-Critical

Impact

    uint256 public constant BASIS_POINTS = 10000; // 100% in basis points

Proof of Concept

StakingStorage.sol:

LiquidityReserveStorage.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to use scientific notation such as 1e4.

9. Missing/incomplete natspec comments

Risk

Non-Critical

Impact

Contracts are missing natspec comments which makes code more difficult to read and prone to errors.

Proof of Concept

Staking.sol:

Yieldy.sol:

Migration.sol:

BatchRequests.sol:

Tools Used

Manual Review / VSCode

Recommended Mitigation Steps

It is recommended to add missing natspec comments.