Beware the DApp: Security issues with Turing Complete languages

The ICO gold rush in DApps (pronounced DEE-Apps, short for Distributed Applications) has generated over $1B in 2017 alone, and shows no sign of letting up. Unfortunately, many of those DApps are built using the Solidity language (or another Turing Complete language) and thus are fundamentally insecure. That’s the finding by two different groups of security researchers who published papers on this topic.

Making Smart Contracts Smarter” by Loi Luu, Duc-Hiep Chu, Hrisi Olickel, Prateek Saxena, and Aquinas Hobor

A survey of attacks on Ethereum smart contracts” by Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli

The paper by Luu, et al was published in 2016 and described a tool that the authors built called OYENTE which revealed potential security bugs that would allow an adversary to “manipulate smart contract execution to gain profit.” The researchers ran it against 19,366 existing Ethereum contracts and OYENTE flagged 8,853 of them as vulnerable including TheDAO that suffered a security breach so large (worth approximately $50M) that the Ethereum Foundation took the controversial step of hard-forking the blockchain so that the stolen funds became useless.

The Atzei, et al paper was published in 2017 and provided a vulnerability taxonomy of the Solidity language; the principal programming language used for building DApps on the Ethereum network. Here’s one that caught my eye -

Once a contract is published on the blockchain, it can no longer be altered. Hence, users can trust that if the contract implements their intended functionality, then its runtime behaviour will be the expected one as well, since this is ensured by the consensus protocol. The drawback is that if a contract contains a bug, there is no direct way to patch it. (emphasis added)

Hmmm, no way to patch a discovered vulnerability? Woo Hoo! Let’s build a multi-million dollar ICO around THAT programming language! You may think I’m being sarcastic (I am), but in fact thousands of apps have been built on the Ethereum blockchain using Solidity and are promoted as secure. How many of those popped under OYENTE, I wonder?

The Only Problem That Matters

There are a lot of problems with Initial Coin Offerings (the popular albeit inaccurate term) or Token Generating Events (the politically correct term) such as differentiating them from fiat currency fundraising so as to avoid SEC regulations, or protecting purchasers of tokens from unscrupulous crypto startups that will vanish with their money. I know first-hand since, like many others, I’m fascinated by the astounding potential of a decentralized, transparent digital currency that is programmable and spent the last month learning about the pros and cons to help me evaluate my own proposed venture as well as those of others that I’ve spoken to.

Source: “A Survey Of Attacks On Ethereum Smart Contracts”, Atzei N., et al, 2017

If you’re looking to invest in an ICO, first identify if a Turing Complete language was used to build their DApp. If yes, ask the developers if they used OYENTE to test its security and what the results were. Ask how they intend to patch discovered bugs after they launch, or address any of the other vulnerabilities addressed by Atzei, et al in the above table.

Let’s not keep repeating the same mistakes with Smart Contracts and ERC20 tokens that we’ve made time and again with software development during the past 40 years. Let’s put security first for a change and then build the DApps that will change the world.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.