Can you attack/ddos/spam a single contract?

Question

Can you make a denial of service attack against a Contract? By blocking a single contract (or ethereum-object) instance so it can't be executed? For example spamming it in some way, like repeadetly calling a method of a single contract that modifies the internal values of the contract?

---

Is it possible to be able to find a way to spam the contract first because it's easier/cheaper to spam it and block it individually instead of spamming the whole network? How much do you need to roughly spend in ethers?

An example attack I have in mind would be to call a specific transactional method (sendTransaction to a method that stores data into a contract) in an Ethereum contract repeadetly, to see if you can block a normal user from executing the contract, because of increased gas cost or for other reasons.

How much Ethereum is resistant to attacks like that? Are there any other attacks that can render a contract completely blocked or unusable instead, is it much cheaper/easier to run such an attack instead of a broad spam of the whole network, is the potential cost different/cheaper?

Answer 1

There's no concept of DDOS in contracts in the same vein as a web server in Ethereum. You can send as many transactions as you want, but you won't be able to block access to it, simply by flooding it with transactions. To DDOS, you would have to try and DDOS the whole Ethereum network. In this attack, you essentially send so many transactions that you fill up the gas limit in each block, such that people who pay normal fees for gas, won't get their transactions included until later blocks. The gas limit would increase per each block (due to Ethereum's dynamic block sizes) and thus the attack would become increasingly costly over time. This is generally, an expensive attack to maintain as you would have to pay for all the gas each time. At 50 shannon per gas & 2usd/ether, it would amount to about $1600 per day to keep blocks filled up at current rate (3.14 million gas per block * 50 shannon = 0.157 ether * ~5083 blocks per day * ~2$/ether). (Correct me if my calculations are wrong).

There are other attacks one could do on contracts if it is not coded correctly. You are correct at inferring that if a contract loops through addresses and you could just add new ones, then at some point, the contract won't be able to execute a transaction within the current gas limit. Which would block access.

Another attack is to create a parasitic contract that drains all the gas automatically, rendering service unusable for other participants. For example, if you use address.call.value (and not send() in Solidity) to send funds to another contract/address, then you could maliciously just drain all gas. For example, let's say you want to send dividends to participants. The 3rd person down the line, put in this attack, draining all the gas, thus not allowing any other people to receive any dividends.

There are other attacks as well such as the call stack attack, where you basically fill up the stack BEFORE issuing a call to another contract. This could be damaging if not properly checked/accounted for. See more here: http://martin.swende.se/blog/Devcon1-and-contract-security.html

So, yes, there are ways to make current contracts unusable IF the smart contract developer did not know about these potential attacks. Solidity has some checks in place to protect against some of this (use send() when possible for example), but not all possibilities are mitigated.

Answer 2

Contracts can't be DDOS, because doing so means attacking the entire peer-to-peer network, since every node makes the contract available.

The possibility of an "attack" on a contract depends on the contract's code. If a contract carelessly iterates over some data structure, then yes it's possible for an attacker to fill it up so that the cost of iteration can exceed the block gas limit, and the iteration and related functionality will be unusable. It highly depends on the contract's code, including its dependencies: which contracts it calls, and what they call, and so on. If one has written a contract carefully, but down the line it makes a call to a contract that is vulnerable to becoming unusable, then one's contract can also become unusable.

Another "attack" is what is performed before calling the contract. But it is not the responsibility of the contract to ensure that enough gas has been provided to it. If a caller of the contract doesn't specify enough gas, or performs other operations, or calls an attacker's contract that drains the caller of gas, it's the "fault" of the caller. A related area that should be the responsibility of the contract however, is to handle call-depth limit errors. If the depth of calls exceeds 1024, the contract should fail responsibly. Still, this falls in the realm of what the caller does before calling the contract, and a depth limit of 1024 appears to be generous for practical purposes. Solidity recommends that for more complex operations, loops should be preferred over recursive calls.

One of the Ethereum audits discusses related topics such as the call-depth limit (also discussed by this blog) and hazards of composing contracts.

Answer 3

Calling a contract repeatedly does not block it.

You would spend a lot of ether for all the gas used in the transactions.