Open Source Software Source Code Security Vulnerability Analysis Report

——Blockchain Special Topic

National Internet Emergency Center Laboratory
October 2016

Table of contents

1 Overview…… ...
2 Tested open source software……………………………………………………………………………………………… 2
3 Test content…………………………………………………………………………………………………………………… 4
3.1 Types of security vulnerabilities……………………………………………………………………………………. 4
3.2 Security Vulnerability Level…………………………………………………………………………………………. 6
4 Security vulnerabilities of open source blockchain software projects……………………………………………………………… 7
4.1 Overview of Security Vulnerabilities……………………………………………………………………………… 7
4.2 Distribution of High-risk Security Vulnerabilities…………………………………………………………………….. 9
4.3 Overall Distribution of Security Vulnerabilities………………………………………………………… 12
5 Notes on this report………………………………………………………………………………………… 15

1 Overview

With the rapid development of software technology, open source software has been widely used around the world. Data shows that since 2012, more than 80% of commercial software has used open source software. Once there is a security problem in the code of open source software, it will inevitably cause widespread and serious impact. In order to understand the security status of open source software, the laboratory continues to analyze the source code security vulnerabilities of widely used well-known open source software and publishes quarterly security vulnerability analysis reports.

At present, blockchain technology has undoubtedly become the hottest new technology in the field of science and technology and finance. Blockchain technology is a solution for collectively maintaining a reliable database (ledger) in a decentralized and trustless manner. Due to its high efficiency, convenience and security, blockchain technology has received widespread attention in the financial industry. At this year's Washington International Finance Annual Meeting, the Federal Reserve commented that blockchain "may represent the most significant development in the field of payment, clearing and settlement in many years."

It is reported that major financial giants around the world are making a big move into the field of blockchain technology. Major stock and commodity exchanges have been actively researching blockchain through experiments and investments. For example, Nasdaq launched its blockchain project Linq last fall. As early as December 30 last year, Nasdaq completed the first securities transaction based on the blockchain technology platform. Central banks around the world, including my country, are also intensively carrying out research and application pilots related to blockchain technology. In January this year, several world-class investment banks including JPMorgan Chase, Citigroup, Deutsche Börse Group, etc. jointly invested in blockchain projects, aiming to plan and build a more efficient and secure blockchain-related financial product portfolio. In addition, nine global top banks such as Barclays Bank and Credit Suisse Group have begun to formulate industry standards and protocols for the use of blockchain technology in the banking industry. It is estimated that by 2017, the global banking industry's investment in blockchain technology development will exceed US$1 billion, leading the development speed of all enterprise software sectors.

In June this year, representatives from central banks and regulatory agencies from 90 countries, including Chinese representatives, gathered at the Federal Reserve headquarters in Washington to discuss the development and application of blockchain technology. It can be seen that the importance of blockchain has been recognized by financial regulators, and the global interest in blockchain is no longer limited to a certain institution, and large-scale collaborative exploration has begun. The security of blockchain technology is a key issue of concern. Once there are loopholes in the relevant software, it will cause huge property losses.

This quarter, the lab focused on well-known open source software in the blockchain field. Combining the results of vulnerability scanning tools and manual audits, this vulnerability analysis report was formed. This test found a total of 746 high-risk security vulnerabilities and security risks at the code level. From the results, it can be seen that open source blockchain software has serious security risks that cannot be ignored.

2 Open Source Software Tested

Taking into account the number of users, the degree of attention, and the frequency of updates, the laboratory selected 25 representative blockchain software. Table 1 lists the overview of the open source blockchain software projects tested this time. The software tested this time covers programming languages ​​such as C, C++, Java, Python, and PHP. These open source software projects are well-known internationally and domestically, with a wide range of users, and some of them are developed by well-known software companies. Since most of these software are related to asset and currency transactions, once a vulnerability occurs, it may lead to a serious risk of property loss.

Table 1 Overview of the open source software projects tested

1It is generally believed that the higher the star of a project, the more developers will pay attention to it and the greater its influence.



3 Test content

3.1 Types of security vulnerabilities

This test covers various common security vulnerabilities. Based on the causes of security vulnerabilities, the possibility of being exploited, the degree of harm caused, and the difficulty of solving them, common security vulnerabilities can be divided into nine categories:

1) Input Validation and Representation

Input validation and representation problems are usually caused by special characters, encodings, and digital representations. These problems occur due to trust in input. These problems include: buffer overflow, cross-site scripting, SQL injection, command injection, etc.

2) API Abuse

API is an agreement between the caller and the callee. Most API abuses are caused by the caller not understanding the purpose of the agreement. When API is used improperly, it can also cause security issues.

3) Security Features: This category mainly includes vulnerabilities in authentication, access control, confidentiality, password usage and privilege management.

4) Memory Management is a general term for a class of vulnerabilities related to memory operations. Common vulnerabilities include memory leaks, use after free, double free, etc. This type of vulnerability usually leads to system performance degradation, program crashes, etc. It is a common type of vulnerability in C/C++ language.

5) Time and State Distributed computing is related to time and state. The interaction between threads and processes and the time order of executing tasks are often determined by shared states, such as semaphores, variables, file systems, etc. Vulnerabilities related to distributed computing include race conditions, misuse of blocking, etc.

6) Error and exception handling flaws (Errors) This type of vulnerability is related to error and exception handling. The most common vulnerability is that the error is not handled properly (or no error is handled), resulting in the unexpected termination of the program. Another vulnerability is that the errors generated provide too much information to potential attackers.

7) Code Quality

Poor code quality can lead to unpredictable behavior. For attackers, poor code allows them to threaten the system in unexpected ways. Common vulnerabilities in this category include dead code, null pointer dereference, resource leaks, etc.

8) Encapsulation and hiding defects (Encapsulation) Reasonable encapsulation means distinguishing between verified and unverified data, distinguishing between data of different users, or distinguishing between data that users can see and cannot see, etc. Common vulnerabilities include hidden fields, information leakage, cross-site request forgery, etc.

9) Defects in the code running environment (Environment) This type of vulnerability is a problem outside the source code, such as running environment configuration problems, sensitive information management problems, etc., which are still crucial to product security.

The first eight types of vulnerabilities are related to security flaws in the source code. They can become targets of malicious attacks and once exploited, they can cause serious consequences such as information leakage, privilege escalation, and command execution. The last type of vulnerability describes security issues outside the actual code, which can easily cause serious problems such as software operation anomalies and data loss.

3.2 Security Vulnerability Level

We classify source code security issues into three levels: high, medium, and low. The criteria for measuring the level include two dimensions: confidence and severity. Confidence refers to the probability that the problem found is accurate. For example, the confidence level of marking every strcpy() call as a buffer overflow vulnerability is very low. Severity refers to the severity of the problem detected assuming that the testing technology is authentic. For example, buffer overflow is usually a more serious security issue than null pointer dereference. Combining these two factors can accurately classify security issues, as shown in Figure 1.



Figure 1 Relationship between vulnerability level, severity and confidence level

4 Security vulnerabilities of open source blockchain software projects

This section first shows the number of security vulnerabilities detected from the tested projects, thereby roughly evaluating the security of the tested projects. Then it further discusses the distribution of security vulnerabilities in the tested projects to understand the security issues that appear frequently and are easily overlooked in the projects.

4.1 Overview of security vulnerabilities

Since high-risk and medium-risk security vulnerabilities are more harmful and can better reflect the security issues that need to be urgently addressed in the software, this section shows the detection of these two levels of vulnerabilities in the tested projects, thereby roughly evaluating the security of the tested projects. Figure 2 shows the medium- and high-risk security vulnerabilities detected in the tested projects, and sorts the projects according to the number of vulnerabilities. The figure also uses a red line chart to show the number of vulnerabilities per thousand lines2.

2 Calculation method for the number of vulnerabilities per thousand lines: total number of vulnerabilities/number of lines of code*1000, accurate to two decimal places

Figure 2 High-risk vulnerabilities in open source software projects

It can be seen that the selected blockchain software all have different degrees of security issues. A total of 746 high-risk vulnerabilities and 3,497 medium-risk vulnerabilities were found in these projects. The projects with the highest number of vulnerabilities are in a state where they are easily exploited by attackers, and actual users urgently need to repair and upgrade them by installing patches or updating versions.

Among all the tested software, the blockchain payment network Ripple has relatively serious security risks in general, with高危漏洞223 . It is worth noting that this software is likely to be the most famous, most widely used and most widely used blockchain-related software tested this time. It is reported that as of press time, the company that owns this software has received a total of US$100 million in investment from Google, Accenture and others, and some large banks have announced that they will join its payment network, including Standard Chartered, Westpac Bank, National Australia Bank and Shanghai Huarui Bank. Considering that this software directly handles financial assets and has such a large number of users, once these vulnerabilities are exploited by hackers, it will cause immeasurable losses.

The second-highest overall security risk is the Ethereumj project, which is a Java implementation of Ethereum, a distributed application platform based on blockchain. Testing shows that the project contains 110 high-risk vulnerabilities and has a high security risk.

Among all the tested software, the one with the most vulnerabilities is the blockchain-based financial service software BitShares. Its latest version contains 669 medium- and high-risk vulnerabilities, including 4 high-risk vulnerabilities and 665 medium-risk vulnerabilities. Although it has been significantly improved compared to the earlier version (BitShares-0.x contains 25 high-risk vulnerabilities and 1,236 medium-risk vulnerabilities), there are still significant security risks.

In terms of vulnerability distribution density, the blockchain browser Bitcoin Block Explorer has the highest vulnerability density. The software is relatively small, with only 984 lines of code, but on average there is one high-risk vulnerability in every 11 lines of code. It should be noted that the software has stopped updating and running since September 2015, and its source code is currently mainly used for learning and reference. To avoid introducing unnecessary security risks, developers who follow this project (Github star number is 141) should be aware of the potential security risks in its code.

Among all the tested software, there are two softwares that do not have high-risk vulnerabilities, namely Ethereum Wallet and Hlp-candidate (blockchain-based digital assets). In addition, OmniJ, the Java implementation of the digital asset and currency trading platform Omni, has only one high-risk vulnerability, and its overall security is good.

4.2 Distribution of high-risk security vulnerabilities

A large number of high-risk vulnerabilities were found in this test. Figure 3 shows the distribution of the major categories of high-risk vulnerabilities in the tested projects. The data shows that most of the vulnerabilities are "input validation and representation" vulnerabilities, which are mainly caused by insufficient validation of user input. Once the attacker constructs malicious input, it may cause serious security issues such as arbitrary command execution and arbitrary file reading. In addition to traditional "input validation and representation" vulnerabilities such as cross-site scripting, one reason for the high occurrence of this type of vulnerability is that some Java-based blockchain software (such as Ripple) uses the JNI framework and uses other languages ​​(such as C and C++) to directly manipulate operating system resources such as memory, bypassing Java's memory protection mechanism, making the program vulnerable to attacks such as buffer overflows.

There are also many vulnerabilities of "code quality issues". The main reason is that developers lack security awareness and the code is not written in a standardized manner. Such vulnerabilities can lead to security risks such as memory overflow and resource exhaustion. In serious cases, it can cause system operation abnormalities or even system crashes. Since blockchain software often runs directly in important systems such as the financial field, once the system crashes, it will bring intolerable huge losses.

"Security feature" vulnerabilities also account for a certain share. These vulnerabilities mainly cover issues such as identity authentication, permission management, and password management. Attackers can use these vulnerabilities to achieve unauthorized access and steal private information. For blockchain software, encryption is the core function to maintain the security of the entire open database (ledger). However, according to the test results, multiple software have a certain number of "insecure random number" problems, which will seriously reduce the software's ability to resist encryption attacks.

Figure 4 further shows the distribution of various specific high-risk security vulnerabilities in the tested projects. Among the 25 projects tested, the two most common types of vulnerabilities are insecure JNI (16.22%, 121) and insecure random numbers (21.72%, 162). The following is a brief description of these two vulnerabilities and provides prevention suggestions.



Figure 4 Distribution of high-risk security vulnerabilities in the tested projects (by specific vulnerability)

1) Insecure JNI (input validation and representation vulnerabilities)
When Java applications use JNI to call code written in other programming languages, improper application can make Java applications vulnerable to security vulnerabilities in other languages. Although there is a memory protection mechanism provided by Java, this protection mechanism does not apply to source code written in other languages ​​and accessed through the Java Native Interface (JNI).

Prevention: The operations performed by the native language contained in the Java code should be carefully checked, and strict input validation should be performed.

2) Insecure random numbers (security feature vulnerabilities) In an environment with high security requirements, using a function that can generate predictable values ​​as a random data source will reduce the system's ability to resist encryption attacks, leading to serious vulnerabilities such as easy-to-guess passwords, predictable encryption keys, session hijacking attacks, and DNS spoofing.

Prevention: Use a cryptographic pseudo-random number generator and use the information with the largest information entropy as the seed of the cryptographic pseudo-random number generator. If information entropy is not available, you can change the seed of the cryptographic pseudo-random number generator when using it to reduce the threat.

4.3 Overall distribution of security vulnerabilities

The above article analyzes the security status of the project based on the detection of high-risk vulnerabilities in the tested project. Generally speaking, compared with high-risk vulnerabilities, medium- and low-risk vulnerabilities are relatively less harmful in the actual operating environment, but they can still reflect the code quality of the project and the degree of attention paid by developers to code security issues to a certain extent. In order to have a more comprehensive understanding of the security status of the tested project, this section further shows the overall distribution of all levels of security vulnerabilities, including medium- and low-risk vulnerabilities.

Figure 5 shows the distribution of security vulnerabilities in the tested projects. Compared with the distribution of high-risk vulnerabilities, the proportion of code quality issues has increased significantly. Looking at the specific vulnerability types, it can be found that the projects contain a large number of uninitialized variables, unused variables or functions, dead code, lack of null pointer judgment and other problems, reflecting that the code quality of these software needs to be improved urgently. Although these problems will not lead to direct serious security vulnerabilities, there are still obvious security risks. Once exploited, they may also cause serious risks such as program crashes. One possible reason for the large number of code quality vulnerabilities is that some of the projects tested this time are intermediate versions that have not yet been officially released, so the code itself has not yet reached a stable state, resulting in a large number of incomplete "process codes" remaining.

In addition, there are a considerable number of improper API usage issues in the project, such as unsafe use of string processing functions, ignoring the return value of specific APIs, etc. Failure to use the API in accordance with the agreement may cause unexpected exceptions in program operation, thus affecting the correctness of program logic or system stability.

Compared with the distribution of high-risk vulnerabilities, there are more "error and exception handling" vulnerabilities. Looking at the specific vulnerability types, we can find that there are a certain number of "empty exception handling code blocks" and "capturing overly general exceptions" in the project, which will cause the program to be unable to properly respond to unexpected situations, making the system fragile and unstable. Once the system fails, such sloppy exception handling will also make it difficult to trace and solve the fault problem. In fact, any attack on the system is an "abnormal" situation that violates the developer's assumptions. Especially for industries such as financial systems that have extremely high requirements for stability and availability, good error and exception handling is a necessary condition to ensure system security and stability.

Figure 6 further shows the distribution of various specific security vulnerabilities in the tested projects. It should be noted that 87 medium- and low-risk vulnerabilities that only appeared no more than 10 times appeared in the test results, such as "inappropriate type conversion", "legacy debugging information" and other code quality and API usage related vulnerabilities. For the convenience of data presentation, they are uniformly classified as "other" type vulnerabilities in the figure. Among the 25 projects tested, the two most common vulnerabilities are unused local variables (13.94%, 1181) and unsafe string processing functions (13.20%, 1118). The following is a brief description of these two vulnerabilities and provides prevention suggestions.

Figure 5 Distribution of all security vulnerabilities in the tested projects (by major category)

Figure 6 Distribution of all security vulnerabilities in the tested projects (by specific security vulnerabilities)

1) Unused local variables (code quality vulnerabilities) Local variables are not used after being declared in the code. This problem does not cause direct harm, but usually means that there may be logical errors in the code writing process, such as using the wrong variable due to copy and paste errors, or related variable assignment statements are commented out by mistake.

Prevention: Developers should check the integrity and correctness of the code logic and delete redundant variable declarations. 2) Unsafe string processing functions (API misuse vulnerabilities) Some standard string processing functions do not perform strict boundary checks and have serious buffer overflow risks, such as C language gets(), strcpy(), strcat(), sprintf(), scanf(), etc.

Prevention: Avoid using these functions as much as possible and use safer alternative functions, such as replacing gets() with fgets(), and perform strict boundary checks.

5 Notes on this report

1. This report only analyzes vulnerabilities from the perspective of code. The vulnerabilities counted in this report refer to security risks that may be exploited by attackers due to improper code writing. In actual systems, due to limitations in the actual software deployment environment and security equipment, some vulnerabilities may not be verified through penetration testing.

2. The vulnerabilities in this report are only applicable to the specific software versions listed in Table 1. This report is no longer applicable when the software version is updated, modified, or optimized.

3. This report has been partially supported by data from 360 Code Guard, and we would like to express our gratitude.