Miners have the ability to manipulate block.timestamp so it can be exploited if there is an incentive to do so. There are some restrictions on how miners can change block.timestamp: It has to be greater than the last parent block and it can not be too far in the future otherwise other nodes will reject … Read more
These attacks can leave a contract inoperable either temporarily or permanently. There are many ways a contract can become inoperable; some are presented below: External function calls: An external function may maliciously use all gas when called, making a contract temporarily or even permanently inoperable. For example, the TrickleWallet at https://github.com/sigp/solidity-security-blog#the-vulnerability-10 issues a function call … Read more
Miners get to choose what transaction they would pick up from the pool to form a block and this means the transactions that carry a high gasPrice will likely be picked up first. A Race condition occurs when an attacker can read a transaction on the blockchain and create a similar transaction with a higher … Read more
We can use .transfer() to send Ether which is considered safe as it reverts in case the transfer fails. We can also use .send() and .call() to transfer Ether but they only return a value of false if they fail. This creates a security vulnerability where an attacker can target a transaction that should have … Read more
Prior to Solidity v0.5.0, Smart Contracts suffered from vulnerability resulting from attacker using a shorter than required address as function parameter. The vulnerability resulted from EVM’s tendency to append zero’s at the end of calldata in case a parameter(in this case, an address) was shorter in length than it is by definition. Looking at example … Read more
There is no random() function in Solidity so the developers end up using other means of achieving randomness such as using hash of next block as a random value. If this source of entropy is not selected carefully, it can be used by an attacker to predict the next “random” value and exploit a contract.
Earlier version of solidity did not enforce defining visibility on functions. This created situations where an attacker would be able to call a function that he/she shouldn’t be. Recent Solidity versions enforce setting up visibility on every function so this vulnerability has been mitigated. However it is still important to review the visibility of all … Read more
There are two kinds of low level functions invocations: call() and delegatecall(). The latter is used when we wish to execute an external function in the context of the caller contract. This means the target function can manipulate the state variables of the caller contract. So, if contract A issues a delegatecall to B.foo(), then … Read more
A contract may be vulnerable if it incorrectly uses address(this).balance. I modified the EtherGame contract from https://github.com/sigp/solidity-security-blog#3-unexpected-ether-1 wrote the Player and Attacker contact to demonstrate this vulnerability. How to Test: Deploy EtherGame and note the contract’s address Deploy the Player contract with 5 Ether and pass the address of EtherGame’s address to the constructor Deploy … Read more
Prior to v0.8.1, Solidity contracts were vulnerable to over/underflow attacks. This vulnerability caused mathematical operations of +, – and * to be exploited if the attacker can control the value of at least one operand. A demo for over/underflow behaviour is provided below: To see the vulnerability in action, lets see the contract from one … Read more