Recomposing EOS Security Incident and Revisiting Blockchain Security
Presented by Huobi Research, Author: Hubery Yuan, Zhiwei Hu, Hui Li
On May 29, 2018, 360 announced its discovery of a serious system vulnerability in EOSIO. This news and a follow-up series of incidents quickly became hot spots in the Blockchain field. With more and more voices and content appearing, the world has gradually become aware of this incident. We believe it is necessary to objectively re-compose and analyze this incident from a technical point of view, and to discuss the issue of Blockchain security again.
1. Replay of the incident
According to the available online public information, including blogs, code records, etc., we briefly review the technical process of this security incident:
— May 28th, Beijing time. The 360 Vulcan team contacted Daniel Larimer (bytemaster, hereinafter referred to as BM), director of the development of EOSIO, and reported on the discovered high-risk security system vulnerability.
— May 28. BM created a new issue regarding eos project on Github. On the same day, the bug described by the issue was fixed; the issue was closed
— At noon on May 29. 360 company announced through its official WeChat account information regarding the high-risk security vulnerability of Blockchain platform EOSIO.
— Later in the day. 360 company published details of the system vulnerability on its company blog “Qihoo 360 Technology Blog”
2. Technical analysis
Let’s first discuss this incidents from the technical perspective through Qihoo 360 Technology Blog’s report “EOS Node Remote Code Execution Vulnerability — EOS Smart Contract WASM Function Table Array Overrun.”
According to the report, on the code version early than the commit of ea89dce21d13d41a22b3512a27be97b4be9df755 which fixed the bug, we can see in line 76 of the libraries/chain/webassembly/binaryen.cpp file that “assert” is used to check the value of variables. However, “assert” is generally only applicable to the Debug mode of program build. It usually does not work for the “Release” mode of the official release. Therefore, it is equivalent to not checking at all, leading to potential risks in accessing arrays on line 78.
Therefore, after discovering the system vulerability, the development team has changed “assert” to a macro called “FC_ASSERT” that can be called normally.
After discovering the key problem, let’s look at the memory structure and language features of the C++ program used to write EOSIO.
The memory area of a C++ program includes a stack area, a heap area, a free memory area, a static global memory area, a constant area, and a code area. Each area has its own unique role. At the same time, C/C++ allows programmers to control and use memory very autonomously by using pointers, etc. It does not force the examining conditions such as array boundaries. Because of the extremely flexible and controllable underlying language features including memory management, C/C++ is widely used in industry with strict requirements on program execution speed due to its high performance. But because of this flexibility, C/C++ programs often suffer from memory leaks, outages, or memory out-of-bound issues due to the complexity of memory management. This is especially common in large projects.
The reason is that once the C++ program pointer accesses the corresponding memory area, it is possible to perform corresponding operations on it, so if not properly controlled, access exceeds the original “boundary” will result in out-of-bound problem: If the program pointer access the data area, It may cause program crash or reading or modifying the information that should not be accessed; If it access the code area, it may inject or change the original code. This is the basic principle of buffer overflow.
As an extremely common and powerful attack on computers and the Internet, buffer overflows can be traced back to the 1988 Morris worm attacks. It is estimated that its appearance affected 10% of computers on the Internet, causing losses of about 100,000 to 1 million US dollars. From its first appearance to today, many well-known attacks have taken the form of buffer overflows, and its influence has expanded along with the development of the Internet.
Returning to this system vulnerability of EOSIO. According to the 360 report, we can see: When the check code fails, if the offset variable is set as an arbitrary address, such as 0xfffffff, it will cause a segmentation fault and cause the program to crash; and if the contract is carefully designed, the attacker can execute malicious code by writing it into theout-of-bound memory, as shown in the attached video in the 360 report.
At the same time, if the risk can be controlled within a single machine, the impact on the overall situation is still relatively acceptable. However, because malicious code can exist as a contract on a Blockchain, EOSIO packs the contract into blocks and spreads it across the network, making all nodes controllable by this malicious code, that is, the entire network is fatally affected.
3. Construct a Blockchain Security System
From this system vulnerability incident combined with recent security incidents such as the Ethereum ERC20 system vulnerability, we should be more aware of our opinion presented in “Huobi Insights 3: Re-examining Blockchain Security Ecology Construction from ERC20 System Vulnerability”: Blockchain Security needs more than Projects Teams and developers, but the cooperation between each perspectives. This part of the essay focuses on the construction of Blockchain security ecology from three aspects: project team internal control, project ecological incentive and investor self-prevention.
3.1 improve code security review system
When we re-examine the ERC20 vulnerability events and EOSIO’s buffer overflow events, we can see that they can all be avoided through an effective code security review mechanism. Taking the ERC20 vulnerability as an example, after verification, more than 20 projects using the ERC20 protocol have similar problems.
The rapidly changing cryptocurrency industry has indeed developed too fast. Every player in this industry is hurrying to write white papers, chasing fundraising, and catching up with projects. Naturally, fewer people do tests steadily and conducts thorough security audits, this situation lead to frequent vulnerabilities and frequent security incidents.
As a distributed decentralized system, Blockchains are difficult to update once they are deployed, and only hard or soft bifurcations can upgrade the code with a high cost. The DAO incident splits Ethereum into ETH and ETC, which is a major damage to the Ethereum ecology. Therefore, before the project was released, adequate testing and code review are critical and necessary. Procedures such as multi-person code review, internal assessment team, and external expert evaluation can be implemented.
Peer Reviewing Mechanism
Because one person’s ability and cognition are always limited, different people will find different problems for the same code, and the multi-person code review mechanism can greatly reduce the BUG rate and vulnerability rate of the code. This approach is also one of the most common and effective ways for the software industry to reduce error rates.
Internal assessment team
The project team can set up an internal security assessment team to sort out the list of common security issues in the industry, and conduct security audits on the projects released one by one. Through simple analysis and evaluation, the common vulnerabilities could be eliminated, greatly increasing the reliability of the system.
External experts’ assessment
For certain novel vulnerabilities, the project team can use the help of external security experts such as third-party evaluation agencies to assess, and strive to minimize the potential safety risks before the project is released.
3.2 Develop White Hat Hacker Incentives
The world is nothing more than two poles, one is yin and one is yang, one is black and one is white. There are hackers who destroys to make a profit, and there are white hat hackers who uphold world justice. As the market value of various types of digital assets is getting higher and higher, hackers are objectively gaining more benefits. In contrast, white hat hackers are much less sufficient. This huge income gap led to more and more people joining the hacking camp, while only a few being white hat hackers. Encouraging white hat hackers to suppress or balance hackers’ increasingly unbridled destructive behavior became an effective means.
How to inspire white hat hackers to contribute to platforms? I believe we can start from two aspects: one is material incentive and the other is spiritual motivation.
Material Incentives
For the public chain that issues tokens, the most solid material incentive are naturally tokens. It is not only the value carrier of the blockchain platform, but also an important means of governing the platform. COSMOS, as an example, allows hackers to “recruit” through ReportHackTx transactions in order to encourage the behavior of discovering and promptly reporting defects; the main goal is that “this node has been attacked. Please send prize money to this address”, so hackers can receive 5% of hacked assets as bounties.
In addition, we can also encourage white hat hackers to actively exploit system vulnerabilities by setting up hacking bonus pools, hacking funds, or special advisors for projects to help the platform run permanently and safely.
Spiritual Motivation
In addition to material rewards, spiritual motivation may be a more lasting and effective incentive for Hackers, for they are a very diverse and charismatic group of people. For each hacker who contributes to the platform or project, the project team, foundation, or community should give corresponding honorary awards. It can be a leader board, contribution value, or some kind of unique title, so that it can not only be known to other members of the community, but also can be clearly distinguished the awardees from ordinary members, enhancing their sense of presence, sense of participation, and sense of honor in the community. We can also consider using a more “geek” approach as spiritual stimulation, such as recording the contribution of white hat hackers to the platform and the community on the Blockchain to form a healthy Blockchain ecosystem.
