What are the Ethereum’s Smart Contract Vulnerability Types?

SMART CONTRACTS VULNERABILITY TYPES 

 

VULNERABILITY TYPES 

Reentrancy Problem

Reentrancy risk is an infamous weakness. Smart contracts element to conjure and use codes from outside contracts. The presentation of setting off an outside contract or on the other hand sending digital money to a record needs to submit an outside call. The outside call might be commandeered by an assailant to compel the contract to execute reentrant codes counting getting back-to-back themselves. Hence, similar codes are executed more than once like the backhanded recursive capacity brings in the programming language. The vulnerability was found in the DAO contract in 2016.

A Reentrancy attack could indeed deplete the ether of a Smart-Contract and enable an intrusion into contract software. When an exterior function calls some other unauthenticated contract, and an intruder takes control of that unknown contract, they can end up making a recursive call back to the original function, unusually repeating transactions it would not have run or else, and ultimately consuming all of the gas.

Single Function: If a contract seems to be using a call, send, or transfer that may end up causing control flow to an exterior contract with a fallback method and afterward updates the state, the contract's state will be inadequate when flow control is relocated. As a result, when this fallback function is called, the flow of control might not always revert back as expected by the called contract, and the caller could do anything unexpected, including such as calling the function once more, calling some other function, or even calling some other contract.

Cross Function Reentrancy: When two different functions or even contracts share the same state, a similar move can be carried out. When the attacker's code is executed on the external call in withdrawal in this case, it calls transfer (). Even though they have already obtained the withdrawal, they can transfer the tokens because their balance has still not been reset to zero. This flaw was also exploited in the DAO attack [3]. Even in this particular instance, the same alternative for updating all balances prior to actually transferring control to another function or contract might very well work.

Timestamp Dependency

This problem happens when a contract utilizes block factors as a call condition to play out some basic operations (e.g., sending tokens) or as a seed to produce arbitrary numbers. A few factors root in the block header, including BLOCKHASH, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT, and COINBASE, and consequently, on a basic level, they can be affected by excavators. For example, excavators have the right to set the square TIMESTAMP inside 900 seconds’ offsets. In the event that digital currency is moved dependent on block factors, excavators can take advantage of the weakness by messing with them.

A timestamp is required for any procedure on the blockchain; a smart contract obtains a timestamp that specifies the time when the block was produced. A malicious miner can use the generated block's timestamp to this advantage. The GovernMental Ponzi scheme exploited this timestamp dependence weakness . The malevolent miner engendered a block for his transaction with such an altered timestamp, causing his transaction to be the concluding one and thus allowing someone to win the funds from a smart contract.

Callstack Depth Attack Vulnerability

On Ethereum, a contract can summon different smart contracts the guidelines will not toss a special case however return deceptive with the exception. In the event that the return esteems are unchecked, the guest doesn't understand the disappointment of calling. In this way, agreements should really take a look at the return upsides of guidelines to decide if the execution is on time.

Transaction-Ordering Dependence (TOD)

On the blockchain, the exhibition of smart contracts fluctuates with various exchange successions. Lamentably, the sequences might be controlled by excavators. Consider a situation where the forthcoming exchange pool (tx pool for short) has two new exchanges and the blockchain is at state S, what's more, the state S can be changed into state S1 just if the exchange T is taken care of. Initially, T ought to be handled at state S, and in this way, the state is from S into S1.

However, diggers can manage the exchange Ti before T as per their own desires, and afterward, the state is from S into S2 rather than from S into S1. Accordingly, in case T is handled right now, the state will be changed into another new state S3. In the previously mentioned case, T is prepared in various square states furthermore, weaknesses result from the progressions of the normal exchange contracts.

Modifying the order of transactions in a single block with numerous calls to the contract causes the final output to change. This has the potential to benefit malicious miners.

This may not be obvious to users because relying on transaction ordering is troublesome for smart contracts. There are two reasons for this. First, if there are concurrent invocations, even a benign invocation of the contract may result in an unexpected result for users. Second, a malicious user can take advantage of the TOD contracts to increase profits or even steal money from other users.

Integer Overflow and Integer Underflow Vulnerabilities.

An integer Overlow is a condition in a PC program where the consequence of computation is various more modest outright qualities than the PC can really store in memory. For instance, an 8-bit system is fit for putting away unsigned whole integers going from 0–255. Any activity that creates a yield that is under 0 will result in an underflow. The impacts might be the opposite of the flood case as the deciphered outcomes would turn over and begin counting down from the most noteworthy storable worth.

The worth of number kind in coding has a reach of greatest (max) and least (min) number. The number type is unsigned on the blockchain and consequently, the base is 0. Assume a situation where the unsigned number is 8 pieces, the greatest is along these lines 28. Number Overflow and Integer Underflow Weaknesses emerge when estimation surpasses max or is beneath min on account of max + 1 → min or min − 1 → max. Storing a value in an integer variable that is larger or smaller than its limits results in integer overflow or underflow in Solidity. Attackers can use this to fraudulently syphon off funds. 

Mishandled exceptions

The mishandle exception is produced by Solidity's unpredictable exception handling, which is reliant on how each contract calls. When one contract calls another's function, it may fail due to various types of exceptions. When such an exception occurs, the mechanism for handling it is determined by how the calls are made. When an exception occurs in a chain of nested calls, where each call is a direct call to the function of a contract, all transactions (including ether transfer) are reverted. Contradictions in mishandled exceptions will cause the contract callings to be unconscious of the errors that happened during implementation.

Identifying an exception handling is clear. Recall that if an obj_callee yields an exception, it pushes 0 to the obj_caller's operand stack. Along these lines, we possibly need to check if the contract executes the ISZERO guidance (which checks if the top worth of the stack is (0) after each call. On the off chance that it doesn't, any special case that happened in the callee is overlooked. Consequently, we banner such contracts as a contract that exception handling problems.

Unchecked Send

A smart contract can call another contract using specific function calls such as send, transfer, call, and so on. Calling an external contract may cause some contract anomalies. Because execution will continue even if the called contract throws an exception. If the call fails by accident or because an attacker forces it to fail, it may result in unexpected behavior in the subsequent program logic.

Because Solidity only allows 2300 gas per send call, a computation-heavy fallback function at the receiving contract will result in the invoking send failing. Contracts that fail to handle such failed invocations correctly and allow changes to the global state following the failed send call may result in the incorrect loss of Ether . If the send method fails, the winner does not receive the money, but the prize paid out is set to True. As a result, the condition in line 1 is always False, and the true winner will never be able to claim the prize.

Failed Send

Best practices [16] recommend executing a throw after a failed send to revert the transaction. This paradigm, however, has the potential to jeopardize contracts. which depicts a DAO with a specific number of investors and is at full capacity. If a new investor offers more money than the current smallest investor, the DAO will pay the dividend to the current smallest and put the new one in, increasing its capital stake. An adversarial wallet, on the other hand, with a fallback function that takes more.

Then 2300 gallons of gas to run, can secure this function by simply investing enough to become the smallest investor. When the confrontational wallet is around to be struck off, the contract may fail, recurring the money and perplexing, and regressive all changes. As a result, the wallet remains in the hands of the investors, resulting in a financial loss for the DAO.

Incorrect Logic

There are numerous syntactically legal ways to engage in semantically unjust behavior. While there are several real-world examples for this class, we will only briefly describe four representative bugs for the sake of space. The error was produced through the typographical bug in which += is coded like =+, ensuing in no stability augmentation has been sent to the receiver.

Locked Ether

Ethereum smart contracts, like any other Ethereum account, can receive Ether. However, there are several reasons why the received funds could be permanently locked into the contract. One goal of this contract may be related to some other contract that has been obstructive using the SELFDESTRUCT instruction from EVMs, this code has been detached and its funds have been transferred. If this is the only way for such a contract to send Ether, the funds will be locked indefinitely.

Unrestricted Action

To limit the type of action that a user can take, contracts frequently perform authorization by checking the sender of the message. Typically, only the contract's owner should be able to destroy it or assign it to a new owner. Such a problem can arise not only if the developer is incompetent.

Freezing Ether.

The freezing ether contract is another type of vulnerable contract. This smart contract could together obtain and send ether to other addresses with the help delegatecall. They do not, however, include any functions for sending ether to other addresses. To put it another way, they rely solely on the code of other contracts to send ether (via delegatecall).

When the contract that provides the ether manipulation code commits suicide or self-destructs, the calling contract is unable to send ether and all of its ether is frozen. The second round of attacks on the Parity wallet vulnerability is simply because many wallet contracts can only manipulate their ether using the Parity library. When the hacker changed the parity library to a contract during initialization and then killed it. The ether in the wallet's contracts that rely on the parity library has been frozen.