002.md

Boxy Sky Shell

Medium

Protocol fetch incorrect block.number on Arbitrum

Summary

CNumaLst and CNumaToken relies on both block.number and block.timestamp to accure interest. However arbitrum block.number will return a value close to (but not necessarily exactly) the L1 block number at which the sequencer received the transaction. This allows malicious users to minimize interest through specific strategies, thereby reducing the returns for suppliers.

Root Cause

The root cause is CToken.sol:L242

    function getBlockNumber() internal view virtual returns (uint) {
        return block.number;
    }

According to Arbitrum doc,

Accessing block numbers within an Arbitrum smart contract (i.e., block.number in Solidity) will return a value close to (but not necessarily exactly) the L1 block number at which the sequencer received the transaction.

Compared to the L1 block time, which is 12 seconds, the L2 block time on Arbitrum is only about 0.25 seconds. Since orders on Arbitrum usually decay within a few seconds (less than 8 seconds at the time of writing), it would be necessary to calculate blockDelta based on L2 block numbers to allow the orders to decay as expected and enable more flexible configurations of the decay curve.

This can lead to inaccuracies in accureInterest().

Internal pre-conditions

Protocol to be deployed on Arbitrum. This is confirmed by contest Readme.

External pre-conditions

N/A

Attack Path

N/A

Impact

Breaks some core functions.

PoC

No response

Mitigation

Before deploying to Arbitrum, change

    function getBlockNumber() internal view virtual returns (uint) {
        return block.number;
    }

to

    function getBlockNumber() internal view virtual returns (uint) {
        return ArbSys(100).arbBlockNumber() // returns Arbitrum block number;
    }