Inverse Finance contest - Ruhum's results

Lines of code

https://github.com/code-423n4/2022-10-inverse/blob/main/src/Oracle.sol#L124

Vulnerability details

Impact

The two-day feature of the oracle can be gamed where you only have to manipulate the oracle for ~2 blocks.

Proof of Concept

The oracle computes the day using:

uint day = block.timestamp / 1 days;

Since we're working with uint values here, the following is true: $1728799 / 86400 = 1$ $172800 / 86400 = 2$

Meaning, if you manipulate the oracle at the last block of day $X$, e.g. 23:59:50, and at the first block of day $X + 1$, e.g. 00:00:02, you bypass the two-day feature of the oracle. You only have to manipulate the oracle for two blocks.

This is quite hard to pull off. I'm also not sure whether there were any instances of Chainlink oracle manipulation before. But, since you designed this feature to prevent small timeframe oracle manipulation I think it's valid to point this out.

Tools Used

none

Recommended Mitigation Steps

If you increase it to a three-day interval you can fix this issue. Then, the oracle has to be manipulated for at least 24 hours.

Lines of code

https://github.com/code-423n4/2022-10-inverse/blob/main/src/Oracle.sol#L121

Vulnerability details

Impact

The oracle expects the token to have at most 18 decimals. But, there are tokens with more, e.g. 24. A prominent example is NEAR. It's in place 17 in Etherscan's ERC20 token ranking (by market cap)

The normalization logic will produce wrong results.

Proof of Concept

The price is normalized using:

            uint8 feedDecimals = feeds[token].feed.decimals();
            uint8 tokenDecimals = feeds[token].tokenDecimals;
            uint8 decimals = 36 - feedDecimals - tokenDecimals;
            uint normalizedPrice = price * (10 ** decimals);

With NEAR, you have the following result:

// using real chainlink feed data: https://etherscan.io/address/0xC12A6d1D827e23318266Ef16Ba6F397F2F91dA9b#readContract
chainlink round ID = 18446744073709556379
answer = 306615587 ($3.07)

normalizedPrice = 306615587 * (10 ** (36 - 24 - 8)) = 30661.5587

The price is scaled to 12 decimals instead of 18. The collateral's value will be lower than it should be and thus unusable.

Tools Used

none

Recommended Mitigation Steps

You can scale the value to 18 decimals using

price * (10 ** (18 - feed.decimals()))

The token's own decimals can be ignored. Just scale the oracle's value to 18 decimals and you should be fine.

Lines of code

https://github.com/code-423n4/2022-10-inverse/blob/main/src/Oracle.sol#L82

Vulnerability details

Impact

The Chainlink oracle latestAnswer() function is deprecated. Instead, you're supposed to use latestRoundData().

Using deprecated functions can result in the PriceOracleImplementation not returning the correct value anymore. It will affect the availability of that module.

Proof of Concept

Usage of latestAnswer(): https://github.com/code-423n4/2022-10-inverse/blob/main/src/Oracle.sol#L82

You can find the deprecation notice in the used contract itself: https://etherscan.io/address/0x986b5E1e1755e3C2440e960477f25201B0a8bbD4#code#L142

Tools Used

none

Recommended Mitigation Steps

Use latestRoundData() and verify its return values properly, e.g. that the price was updated recently.