9

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?

  • I would do it from a simple server setup made with at least an instance of a JS/[Web3] based [1] or [JSON_API][2] RPC based, "attacker" server program. This program can talk to a Geth (go-ethereum) server. Maybe it can start with a single geth with sendTransaction call and then can scale to attack from many nodes from VMs/containers. – makevoid Feb 2 '16 at 19:49
12

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.

  • 1
    +1... But I noticed a word is missing but I don't have edit privileges yet nor do I know what you meant to write exactly: near the end "...IF the smart contract developer did not about this"... Did you meant to write "did nothing about this" or "did not think about this"? – Cedric Martin Feb 6 '16 at 0:17
  • @CedricMartin thanks! Yes. Fixed it and clarified it. – Simon de la Rouviere Feb 8 '16 at 7:57
  • I am not fully understanding "parasitic contract that drains all the gas automatically". Who's gas is going to be drained? Contract's do not store gas inside, the gas is an external resource supplied to the contract. So, "not allowing send dividends" is not something that can occur. If the contract is malicious, that's another story, because it was designed to be malicious. You can send all the gas you want to the contract, but it is going to drain your own gas, not gas of the other people. Could you please elaborate on this? I can't understand how this scenario you describing is possible. – Nulik Jun 6 '18 at 12:46
4

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.

0

Calling a contract repeatedly does not block it.

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

  • 1
    What if you have a lot of ethers and you add a lot of records in a contract mapping to render it unusable, maybe a contract that has a function that has a for loop that loops on that mapping/list, and calling the function with the loop becomes very expensive so the contract method cannot be used by normal people anymore? Is this a possible case or I'm missing something? Do you think that there are other similar cases that are possible? I'm asking to anybody that has some insight. It depends a lot from the contract's code for sure. – makevoid Feb 2 '16 at 23:20
  • For example, could you stop a crowdfunding contract to be executed if you fill the map of the addresses/funds registered? – makevoid Feb 2 '16 at 23:20
  • @makevoid your concept revolves around "flooding" a map. I suggest you understand what a map actually is. You're talking about trying to use a very large address space. (Might as well "flood" Bitcoin public addresses.) – linagee Feb 3 '16 at 0:31
  • @linagee could you refrain from posting two-liners as answers. please add some more details and show some research effords. – Waqar Lim Feb 3 '16 at 9:15
  • @linagee I edited my question, In my example I don't say flooding a map, I say: render unusable a function that has a for loop that loops though the map and consumes too much gas to be used by a normal user, also I didn't want to focus on this case, but my question is: are there any contract-specific attacks? – makevoid Feb 3 '16 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.