Smart contracts security problems

I will consider the problems that developers encounter when creating smart contracts, not the security of the platform itself.

Let’s divide these problems into the following types:

problems with smart contract code problems with a development process problems with the language problems with the concept

1. Problems with smart contract code

By problems with smart contract code I mean problems that can be solved by editing .sol file, including but not limited to:

known vulnerabilities (e.g., re-entrancy)

Real-life example : re-entrancy or Checks-Effects-Interactions pattern violation — even well-known (and previously exploited) vulnerabilities can still be found in new contracts.

: re-entrancy or Checks-Effects-Interactions pattern violation — even well-known (and previously exploited) vulnerabilities can still be found in new contracts. original vulnerabilities (in particular, mistakes in code logic)

Real-life example: MultiSig wallet, which is actually not MultiSig. To transfer funds one needs the transaction to be signed with required or more owners’ signatures. At the same time, one needs only one signature to change required. Thus, one can change it to 1 and after that transfer funds by him/herself.

“Thus, one can change it to 1 and after that transfer funds by him/herself”.

bad architecture

Real-life example : token, wallet, and key storage implemented in one contract. As a result, the contract is too complicated and the code is hard to maintain, audit, modify. Thus, code security suffers too.

: token, wallet, and key storage implemented in one contract. As a result, the contract is too complicated and the code is hard to maintain, audit, modify. Thus, code security suffers too. poor code quality

Real-life example: contracts with arbitrary indentation, newlines, and spaces. The code is hard to read, which is also bad for code security. And this happens in the world, where Solidity linters already exist (Solium, Solhint).

Problems with smart contract code lead directly to attacks and loss of funds. The good news is that problems with smart contract code can be found during the audit and eliminated. However, it is important to understand where they come from to avoid further ones. That’s why we get to the next point.

2. Problems with a development process

Problems with the code are caused foremost by the poorly organized development process.

It would seem that software development is a well-studied field with long-established best practices. Nevertheless, the fact that smart contracts are a new area with the unproportional amount of money and hype in it leads to people neglecting standard procedures for various reasons. This often gives rise to serious problems. Here are some of the most typical mistakes:

Specification: most of Ethereum smart contracts are developed without a specification. The consequences are obvious.

Development time: too little time is usually given for development — about a month. An extreme example from my practice: client asked a developer to create a smart contract three days before the ICO.

Developer skill level: a lot of new people come to the area, including those with no programming background.

Ecosystem understanding: even developers with a strong background in other languages often do not understand smart contracts deeply enough.

Development price: there are still not enough smart contract developers; there are even less good ones. Hence the unreasonably high price of their work.

3. Problems with the language

Also, some problems come from Solidity language itself. Initially, it was created rather for the rapid spread of Solidity than for smart contracts development being more convenient and secure. Here are some of its features that complicate secure development:

Multiple inheritance, using for, call/delegate call — all these constructions execute code not from the current source code file. This reduces code readability and thus security.

Checks-Effects-Interactions pattern. If constructions that violate CEI are insecure, why are they (and some other) not prohibited at the language level?

When calling another contract, one can accidentally get into its fallback function with unexpected consequences.

It is clear that everything cannot be taken into account in a brand new area (which smart contracts are). Ethereum project and in particular Solidity language continue developing. However, developers have to keep in mind many language peculiar properties and to take additional measures to make their smart contract more secure.

4. Problems with the concept

However, the most serious problem lies even deeper. Many smart contract users and developers do not understand properly what task smart contracts solve, what they can and cannot and how they work. In the worst, case it leads to:

a smart contract being not smart:

a smart contract is poorly developed: it runs exactly as programmed, but not as intended to run;

a smart contract strongly depends on backend and/or frontend: backend and frontend code is not a smart contract and is executed in a usual way; its execution is controlled by the server administrator;

2. a smart contract being not a contract:

a smart contract does not set the obligations of the parties: for example, ICO contract sells tokens for ETH, but tokens, in fact, do not impose any obligations on token issuers;

a smart contract allows unilateral changes: one party of the contract (usually, contract owner) can change the contract after it is signed without the consent of other parties;

Real-life example: contract owner can arbitrarily change capitalization, exchange rate and tokensale duration:

3. a smart contract being not needed at all:

a smart contract is created not because it is necessary for technical reasons, but because the authors are trying to create just something with smart contracts to get hype;

authors are trying to think up how to add a smart contract to the project that already exists without it.