Time Dependency in Smart Contracts

by ImmuneBytes
Time Dependency

We are back with the next part of All About Smart Contract Bugs & Security – A cakewalk series, explaining to you one of the top three vulnerabilities that can weaken a smart contract, Timestamp Dependence. The timestamp dependence vulnerability occurs from a flawed comprehension of timekeeping. Make sure to check out the other parts in this series to know about Flash Loans and Re-entrancy, and how these bugs affect smart contracts.

Unfortunately, In a distributed system like the blockchain itself, the timestamp of the block can be manipulated by the miner to exploit the vulnerability. The miner can alter the timestamp by just a few seconds that best suits his profit and completely change the output of the contract.

This vulnerability exists when a smart contract uses the block timestamp as part of the conditions to perform a critical operation (e.g., sending ether) or as the source of entropy to generate random numbers. Let’s take a look at the implementation of the vulnerability:

function oddOrEven(bool yourGuess) external payable returns (bool) {

    if (yourGuess == now % 2 > 0) {

        uint fee = msg.value / 10;

        msg.sender.transfer(msg.value * 2 – fee);

    }

}

 

In this particular code, we see that now can be manipulated by hackers for their own advantage, allowing them to always win. While reviewing this particular bug, all its direct and indirect cases should be kept in mind.

How does Time Dependence works?

Since such a bug can be easily identified while the smart contract is being audited, there haven’t been any major hacks surrounding it but surely, if you skip a third-party audit for your smart contract, attacks are bound to happen. Let’s take up a scenario of what would happen if there is a time dependency in your smart contract.

In order to gain a profit, a miner may manipulate the timestamp by a few seconds. This, in turn, enables the Ethereum network to be detached from the synchronized global clock. 

For example, let’s say a smart contract utilizes the current timestamp to generate random integers in order to compute the result and award the miner.

uint256 constant private salt =  block.timestamp;


function random(uint Max) constant private returns (uint256 result){

    //get the best seed for randomness

    uint256 x = salt * 100/Max;

    uint256 y = salt * block.number/(salt % 5) ;

    uint256 seed = block.number/3 + (salt % 300) + Last_Payout + y;

    uint256 h = uint256(block.blockhash(seed));

    return uint256((h / x)) % Max + 1; //random number between 1 and Max

}

Since the smart contract allows miners to put up a timestamp within 10 seconds of block validation, this gives a miner an opportunity to exploit the scenario, by altering the outcome of the random number generator to gain benefits. Hence, it is advised to not use timestamps in that context as they are not random.

What is the 15-second Rule?

There is no such restriction on how much blocks can shift in time, but according to the Yellow Paper (Ethereum’s reference specification), each timestamp should be bigger than the timestamp of its parent. Thus, a good unwritten rule in computing timestamp usage is:

“ If the scale of your time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use a block.timestamp.”

The two popularly known Ethereum protocol implementations Geth and Parity reject any blocks with a timestamp greater than 15 seconds in the future. 

This was our take on the Timestamp Dependency bug that can cause trouble to smart contract users. Why leave any window open for the hackers to commit any notorious crimes and to ensure that there are no such windows in your smart contract, you should get a third-party audit. Connect with the team of security professionals at ImmuneBytes today to get your smart contract free of any vulnerabilities and loopholes.

Tune in next Thursday for Part IV of this series wherein we discuss the Overflow and Underflow bug in smart contracts.

 

Spread the love

You may also like