In early March Fujitsu release a press note stating the following:

Fujitsu Develops Technology to Verify Blockchain Risks. Risk detection is automatic and comprehensive to improve safety of smart contracts.

There should have been more responses and questions coming from the cryptosphere because we keep on finding new security holes (luckily there were not exploited) and know that thousands of smart contracts are faulty. However, the main attention unfortunately lies on more sexy topics and there was all eyes on Binance because of the attempt of stealing of quite a lot of funds.

The implications of research regarding the security of smart contracts are not to be tossed aside lightly as it is affecting one of the very key fundamental aspects of the Ethereum blockchain! Making sure that there is no reasonable doubt that smart contracts are safe and secure on a larger scale should be a cause for celebration and create a lot of positive feedback. So lets take a closer look at what the team found.

What are the identified risks in smart contracts?

Before I start to talk about the findings of Zhou et al., I want to have a little excursion into what possibles risks there are for smart contracts. I will not get into the debate about implementation and intent but focus on identified risks and vulnerabilities. Atzei, Bartoletti and Cimoli (2017) classify a total of 12 causes of vulnerabilities onto the three Ethereum blockchain layers:

Tab.1: Taxonomy of vulnerabilities in Ethereum smart contracts according to Atzei, Bartoletti and Cimoli (2017)

These causes represent possibilities for malicious (or unknowing) players to attack Ethereum smart contracts. They range in scope and scale and use different mechanism and attack points. Discussing those is a whole project in itself, which is why I will not further discuss them at this point.

Luu et al. build an open source tool called OYENTE to find security bugs in smart contracts, identifying four types of vulnerabilities:

Transaction-ordering dependence: Imagine a new block including two transactions of the same contract by two seperate individuals A and B. Neither A nor B know the state of the contract when their individual invocation is executed. The miner of the block is responsible for the order and could therefore manipulate the order to achieve a preferred, potentially malicious order.

Timestamp dependence: Contracts can have a block timestamp as a trigger event to perform a certain action e.g. send money at a timestamp x. The Ethereum blockchain allows for a variation of the miner’s local systems timestamp (around 900 seconds), which a malicious actor could use as an attack point. A different timestamp than the actual could be chosen in order to manipulate “ the outcome of timestamp-dependent contracts”.

Mishandled exceptions: When an exception is thrown in a smart contract through a call from another contract, “the callee contract terminates,reverts its state and returns false”. When these exception are not managed properly by the caller (e.g. not checking the return value), they open up a range of vulnerabilities famously shown by the KingOfTheEtherThrone.

Reentrancy vulnerability: Probably the most widely known vulnerability as it led to the DAO hack/exploitation. When being called by another contract, Ethereum smart contracts have to wait for the call to finish. This intermediate state can be exploited.

Sidenote: The paper is worth a read, the group ran OYENTE on 19,366 smart contracts from the first 1,460,00 block in Ethereum and found 8,833 potentially vulnerable contracts.

The Fujitsu team built on top of OYENTE and classified risks into six categories:

Fig.1: Risk classification of smart contracts by Fujitsu

The fields highlighted in light red are the vulnerabilities identified and examined by OYENTE (where call stack restrictions = mishandled exception). The bright red fields are the additional risks that Zhou et al. can detect with their tool which they called SASC (Security Assurance for Smart Contract) and will publish on Github in the near future.

What are the improvements of SASC?

As seen in fig.1, Zhou et al. found additional risks when it comes to timestamps and defined two additional vulnerabilities of smart contracts as defined by Luu et al.:

Expanded Timestamp Risk: In addition to the timestamp risk explained earlier, Zhou et al. found an additional attack angel where “block.timestamp as a factor could be used to do some complex risk affairs without asset transfer”.

Tx.origin Risk: A has written a contract that uses tx.origin for authorization and B wants to interact with A’s contract. Zhou et al. found a way that enables A to construct an attack that would drain all funds from B’s wallet.

Zero Division Risk: Before Solidity version 0.4, division by 0 will not throw an exception but rather give the result 0. This was fixed by throwing a runtime error from version 0.4.15 but older versions are still vulnerable to attacks of that nature.

How does SASC work?

In order to enable a relationship analysis between contracts, the team defined four types of meta data that can be retrieved from a contracts source code: A function list, event list, modifier list and variable list. Within each kind of meta data type there are four parameters that are supposed to ensure the uniqueness of said meta data: Meta name, structure type (contract or library), file name and structure name. This leads to the following structure of meta data used by SASC:

Fig.2: Structure of meta data

The resulting meta data repository extracted from a smart contract was then used to engage in a invocation relationship analyses. In order to engage in the analysis and pinpoint where in the source code the meta data comes from, the Fujitsu team used the Solidity-parser, a number of invocation rules regarding modifiers as well as search scope determination (restricting the search for meta data to its inherited contracts).

For Zhou et al. to be able to locate the line in the source code the vulnerability originated from, they added detection rules for the risks into the symbolic execution model proposed by Luu et al.. Additionally a mapping mechanism for opcodes was implemented and to fit risk and function together the location of all functions was combined with the location information of the risk opcodes.

That enabled Zhou et al. to not only find out whether there is a vulnerability but at the same time find out exactly where in the source code it is.

What did SASC find?

Zhou et al. looked at 4,777 smart contracts with verified source codes including a total of 10,973,029 transactions. Taking an average of roughly 10 minutes per contract, SASC ran 502 hours to analyze these contract. Fig.2 shows the results:

Fig.2: Number of risks and potentially vulnerable contracts found

Please keep in mind that an identified risk does not automatically state that the contract is faulty! It is an indicator for a possible vulnerability that needs to be checked by the developer of the smart contract.

Nevertheless, the findings are astounding. A staggering 61.79% of analyzed contracts showed a potential vulnerability (notice that double entries are possible, meaning that a single contract can show multiple vulnerabilities). More than 40% of identified risks (and more than 50% of risky contracts) stem from call stacks but then again, call functions also occur very often. Timestamp risks made up 25,5% and reentrancy risks about 18%. With Tx.origin risks only occuring in earlier Solidity versions, the number of actual findings are as low as one would hope. However, nearly 1% of contracts were vulnerable, meaning 1 out of 100 contracts is still vulnerable to a know attack! Think about it this way, Visa is potentially capable of handling around 56.000 tx/s. Very simplified, that would mean that 560 tx/s were vulnerable to a known and patched attack.

Where do we go from here?

The research done by teams such as Luu et al., Zhou et al. and others is only the beginning as we see both research interest and blockchain actors interest in security increase. SASC is a very helpful tool in identifying potential vulnerabilities but once more, keep in mind that the risks that SASC finds are not necessary errors. They are indicators of potential risks in a smart contract that still need to be manually checked and corrected where necessary.

There are two paths that need to be followed simultaneously: distribution and implementation of existing research and broadening the research base.

Distribution and implementation of existing research: As shown to a small degree by the tx.origin vulnerability, knowledge about a risk and an available solution are worthless without correct implementation. We need to establish a smart contract safety standard (SCSS if you will) and make the existing research available to as many developers as possible. Things like the Building Security In Maturity Model or an ISO standard come to mind. Ideally, we need a independent governing body (an Ethereum Smart Contract Safety Council ESCSC for example) that issues requirements and best-practices for the SCSS and is ultimately capable of issuing compliance certificates. That is obviously a long-term solution that needs to be addressed rather sooner than later.

Broadening the research base: As pointed out earlier, finding potential vulnerabilities is made possible by SASC but correcting those is still manual work. Mechanism are needed to not only find but also correct correctly identified risks. That means that not only finding a way to automatically change the source code is wanted and make comments so that the original developer can see what was corrected. It also means that the number of false positives need to be first analyzed and ultimately reduced. Zhou et al. state it themselves that there is the need to “consider how to generate test cases automatically based on the analyzed topology diagram and the detected risk functions”.

Additionally, new approaches need to be sought. Dickerson et al. (2017) for example propose a method for the parallel execution of smart contracts, thereby potentially eliminating threats that arise e.g. from transaction-ordering dependence. A proposal to change the opentimestamps-client pull-request to display bitcoin timestamps on a day level would potentially minimize the timestamp dependence vulnerability on the bitcoin blockchain.

What I am trying to show with these examples is, that there is a need to not only work on enhancing existing technologies and methods to increase security but to also think outside the box and challenge the way certain aspects of the blockchain run. Ideally, the proposed ESCSC could identify and propagate potential enhancements in order to raise awareness about the need for further research. Think of a database of known threats and new ways of addressing these threats that is available to everyone. Researchers and individuals alike can see where there is a need, see what others have contributed and try to collectively solve an issue. Possibly one could also involve bounties or research grants in order to push certain issue forward.

Are there any projects working on smart contract security?

A number of blockchain projects have identified smart contract security as a market need and have set up a business model auditing and reviewing smart contracts.

Quantstamp is trying to create a fully automated audit process with automated checks and property verification that ultimately aims at becoming a fundamental protocol of the Ethereum blockchain. Fig3.: shows the simplified workflow from their white paper:

Fig.3 Quantstamp’s audit workflow

Other projects usually follow a similar, simplified work flow which is why I wanted to show the figure as an example.

Research done regarding security issues will find it’s way into Quantstamps security library and therefore aid every smart contract that will be audited by them. That means that should Quantstamp really become a foundational layer of Ethereum at one point, every audit would automatically be checked for potential errors on the basis of the collective blockchain security research.

Solidified is trying to harness to power of the masses by crowdsourcing the auditing process. The developer has to make a deposit and make the source code available the Solidified experts. They check the code and issue a standardized review. Once the developer has integrated changes and both sides agree on fulfillment, the smart contract gets certified.

Smartdec offer a whole bouquet of services around smart contracts. That includes a SmartCheck Tool that works similarly to SASC in that it also checks and highlightes code for vulnerabilities. Additionally, manual checking of contracts is also available.

Experfy checks smart contracts against a vulnerability library, similar to Quantstamp. In addition to auditing only the contract itself, Experfy also tries to make a prognosis how a contract would affect the Ethereum blockchain as a whole. Furthermore, an analysis with regard to transaction fees puts a focus on the minimization of gas spending.

Zeppelin Solutions and Hosho are also widely know projects focusing smart contract auditing.

Conclusion

Zhou et al.’s SASC builds on Luu et al.’s OYENTE and added two vulnerability categories and enhanced one category defined by Luu et al.. Not only can SASC find potential vulnerabilities, it also is able to point to the place in the source code where the vulnerability lies. Running SASC on 4,777 smart contracts the team found that 2952 (61.79%) of them were potentially vulnerable.

This research is but a first step and building block towards more security in smart contracts. There are a number of researchers and groups taking on the topic of smart contract security as well as for-profit blockchain projects such as Quantstamp, that made smart contract security their business model.

There is an urgent need to distribute and implement the findings from OYENTE and SASC while simultaneously widen the scope of smart contract security research. A very roughly proposed governing body ESCSC should be put into place that can issue requirements, best-practices and a maturity model for smart contract security while at the same time promoting and rewarding new research appraoches.

In addition to that, it is my strong believe that we will see even more for-profit projects take on auditing smart contracts and we will see different approaches of doing so. The security of smart contracts, the very fundamental idea of what makes Ethereum run, is of the utmost significance and will become an ever-increasing factor in the success of individual projects and the blockchain as a whole.

— — — — — — — — — — — — — — — — — —

Sources:

Atzei, N., Bartoletti, M., Cimoli, T. (2017)“A survey of attacks on Ethereum smart contracts,” Principles of Security and Trust (POST). LNCS, 2017, vol. 10204, pp. 164–186.

Dickerson T., Gazzillo P., Herlihy M. et al. (2017): “Adding Concurrency to Smart Contracts,” arXiv preprint arXiv:1702.04467.

Luu L., Chu D. H., Olickel H. et al. (2016): “Making smart contracts smarter,” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016, pp. 254–269.

Zhou, E., Hua, S., Pi, B., Sun, J., Nomura, Y., Yamashita, K. and Kurihara, H. (2018): Security Assurance for Smart Contract, to be published.