How to prevent the next heartbleed Vulnerability

How to prevent the next heartbleed Vulnerability

I. Introduction

Open SSL-based heartbleed vulnerability is considered a serious problem of CVE-2014-0160, OpenSSL is widely used in SSL and TLS plug-ins. This article explains how the heartbleed vulnerability was exploited.

This article describes specialized tools and techniques for preventing heartbleed and similar vulnerabilities. First, I used a simple test to analyze why many tools and technologies cannot discover these vulnerabilities, so that we can better understand why previous technologies cannot discover these vulnerabilities. I also want to summarize the key points to reduce these problems. This article does not describe how to write security software. You can learn this from my book Secure Programming for Linux and Unix HOWTO or other books. In this article, I think you can develop software.

My goal is to help prevent the emergence of similar vulnerabilities and improve the development capability of security software. As Mazer Rackham, an illusory character in Orson Scott Card's Ender's Game, said, "There are no teachers, only enemies... You can only learn about your weaknesses from the enemy ." Let's take a look at these vulnerabilities and avoid the occurrence of similar vulnerabilities.

2. Why cannot this vulnerability be discovered earlier?

This OpenSSL vulnerability is caused by a very familiar problem. The key issue is the buffer read overflow caused by incorrect input. These are common problems. Many tools are dedicated to this issue. They use many tools to regularly check OpenSSL.

Kupsch and Miller found the heartbleed vulnerability. Before the vulnerability was discovered, they used many methods and did not find it, although many people and tools used it to find similar vulnerabilities. They further realized that "The heartbleed vulnerability poses a major challenge to the current ancillary software, and we do not know whether there are tools that can be used before the vulnerability is discovered ." I will emphasize other issues and my own points of view.

2.1 Static Analysis

Static analysis when this program is not executed.

The most common static analysis tools used to find vulnerabilities are source code weakness analyzers, source code security analyzers, static application security testing, static analysis code scanners, and code weakness analysis tools. Each source code analysis tool uses the type matching method to find vulnerabilities. There are many reports to evaluate these tools.

However, this vulnerability was not found using static analysis tools in the past:

1. Coverity: Coverity was unable to detect this vulnerability before the announcement of the heartbleed vulnerability. They are working hard to improve the quality of their tools, so that they can discover similar vulnerabilities in the future and use some interesting new inspiration methods.

2. HP/foreach: HP/foreach has published descriptions of some heartbleed vulnerabilities, however, I have no proof that their static analysis tool found this vulnerability before the vulnerability was published. After the vulnerability was published, they did change their dynamic testing software package, but it is different from the previous one. When they specifically discussed this issue, they had no evidence to believe that their tools had discovered this vulnerability before the announcement of the heartbleed vulnerability.

3. Klocwork: Klocwork cannot detect this vulnerability under normal configuration.

4. Grammatech: CodeSonar of Grammatech does not detect this vulnerability. They also use experiments to improve their capabilities so that they can detect similar vulnerabilities in the future.

The main controversy is that these tools cannot detect all vulnerabilities, or even specific types of vulnerabilities. The worst thing is that these terms are confusing, so we need to understand the meaning of these terms first.

In this article, when analyzing software, the tools used cannot find all the vulnerabilities, but I found the shortcomings of this analysis software. In previous articles, many people used unsound to describe tools that could not find all vulnerabilities to find them. For example, Bessey and others are analyzing Coverity's static analysis tools and said, "We also use unsound for PREfix products ." Our product does not prove that this is correct, but does our best to discover these problems. There is a lot of controversy in this research, although it has almost become the basis of practical tools for commercial software and research projects. An unsound term can lead to confusion because people use program checkers, which uses the term unsound to replace different meanings. A blog explains why the same term has two conflicting meanings. "Most program checkers prove the law. In particular, the main purpose is to prove the correctness of the program in a certain aspect. The proof of a law is to prove whether this law is true or not... People get used to this practice during program checks, so they did not consider the existence of bugs. However, the discoverer of a bug does not prove that this program is incorrect, but is used to prove that a bug exists, so that they report the detected bugs and all of them become real bugs, if there are no errors, the bug will be ignored because they cannot prove correct."

In this article, I used the NIST SAMATE SATE V Ockham Sound Analysis standard to eliminate confusion. In the NIST SAMATE language, tools cannot detect all vulnerabilities, thus proving that the program is incomplete. The following describes how NIST distinguishes program reliability and integrity: "The Code of a website may have problems. A website with bugs may have a series of problems, which means some input may cause problems. A website without Bugs will not have column problems, that is, it is secure or has no vulnerabilities... These can be learned from a website report. Or, a website has a special problem or a website has no problems... Reliability means that every discovery is correct. There is no need to use tools to generate reports for each website; this is complete ."

Why are so many source code analysis tools incomplete? First, most programming languages are not easily analyzed. Second, most software uses static analysis tools for analysis. Finally, the complete analysis tool requires more people to apply it to the program. On the contrary, incomplete analysis tools can be applied to programs immediately. They successfully used enlightening methods to identify vulnerabilities and improve analysis within a limited time period. However, there is an important warning: incomplete code analysis tools often miss vulnerabilities.

The heartbleed vulnerability is an example of an important vulnerability that cannot be found using incomplete inspiration methods. The main cause of this vulnerability is that the OpenSSL code is complex; multiple Levels of indirect addressing exceed the analytical capabilities of the tool, so that no vulnerability can be found. Limitations and deep-seated causes are that both C, C ++, and Objective-C are difficult to use static analysis; such as pointers are more difficult to use static management. This does not mean that static analysis tools are useless. Static Analysis tools can test the performance of software after a large number of inputs. The Inspiration principle of the tools limits the number of error reports. But more importantly, incomplete static analysis tools may cause errors when analyzing large vulnerabilities after using the heuristic principle.

 

2.2 Dynamic Analysis

The dynamic method is to use specific input to run a program and try to discover vulnerabilities.

The limitation of dynamic analysis is that it cannot use timelines to test any program. If a 64-bit integer is added to a trivial program, there will be 2128 possible input, and testing the input will take 13.5 100,000 million years. Even large-scale parallel computing cannot solve this problem. In reality, programs are much more complex than this, so dynamic methods cannot reflect the security of a program; they can only show vulnerabilities in the test.

However, this means that dynamic methods are useless. Dynamic methods are useful in improving security, but you need to understand their limitations.

Let's analyze the two widely used methods, but we cannot find heart bleeding vulnerabilities: mostly-positive testing and fuzzers.

2.2.1 mostly-positive automated test suite

One way is to develop a powerful automated test suite. Eric S. Raymond and some others described this as: "I think many people think this test suite cannot work well... I have learned how much traditional methods I can't do ." I agree with him that a good automated test suite is very powerful, especially when applied to non-security defects. If you do not have one or develop one, it will completely stop and we agree.

However, whether the test suite can detect a heartbleed vulnerability depends on how you develop it. Many developers have developed a test suite, which is primarily the "mostly-positive" test suite I am talking about. It may not detect a heart bleeding vulnerability. I will discuss negative testing later. This testing method may be useful, but we need to know why the general testing method cannot.

Many developers and organizers specifically test what will happen when correct input occurs. When you think this way, it makes more sense. Average users complain about whether the output is correct when the input is correct, in addition, most users do not test the program results when incorrect input. If your goal is to quickly identify problems, in most cases, people will try to control the predicted error conditions when entering the correct information. Many developers cannot think about what happens when intruders send well-designed input to exploit the program.

I will use the mostly-positive test suite method to test what will happen with the correct input. Unfortunately, to a large extent, today's software intrusion testing kits are all mostly-positive. All focus on testing the development of the mostly-positive test suite.

1. Test-driven development (TTD) is a software development process. "developers have written an automatic testing tool to improve and add new features, the minimum number of codes is used to pass the test and generate acceptance criteria for the new code." In general, these tests describe what a new function is to do, rather than what they cannot do.

2. When many standards are linked together, interactive Testing determines whether they can link and share data. Interactive testing can help developers improve a protocol standard. However, other implementation methods can also follow this rule, and other implementation methods cannot complete the "Nothing happens" test.

Mostly-positive testing is actually useless for security software. Mostly-positive tests generally do not test the right thing. For heartbleed attacks and other attacks, attackers send data in a different format. TTD and interactive testing are both good tools... But you need to enhance them to improve security software.

The code coverage tool does not help in discovering vulnerabilities. A developer may run a code override tool to check which programs are not tested, and then add a test to test most of the Code. When the test suite tests 80%-90% of the Code, many people will be very happy; generally, it will rarely reach 100% of the coverage. Test Coverage tools have some security value. For example, they can sometimes detect malware waiting for the departing user, and they can also verify that special programs can run correctly. However, a typical code overwrite tool is used to test coverage of 100%, which cannot combat the heartbleed vulnerability. The heartbleed vulnerability lacks proper input verification. Basically, a code overwrite tool does not notice the lost code, but only the code that is not tested.

I would like to say that there will be no exceptions in OpenSSL, as if an error occurs when running SSL/TLS on Apple's iOS device, it can also be verified by mostly-positive. In this vulnerability, the SSL/TLS library accepts valid proof. However, no one verifies that this library can reject some useless verifications. If you only test whether valid data will produce valid results, you cannot find security vulnerabilities, because most attacks are input when the program is not ready.

If the kit you developed can use the method described below, you can use a good test suite to discover this vulnerability. First, let's study fuzzing.

2.2.2 Fuzzers and fuzz Test

Fuzz testing is a random input, which is then sent to the program for testing to see if there is a desire. The software for fuzz testing is Fuzzers.

Fuzz testing is different from traditional testing. In traditional testing, you have a given input group and you know the output of each input. Traditional tests will become more complex as the test data increases, because you need to predict the desired output results. It is determined that the desired output result is an Oracle mechanism. Oracle problem is a question about using Oracle data as input.

Fuzz testing handles different Oracle problem because it is just trying to detect issues that can cause program crashes. This enables it to input more test data in the Fuzz test, even if the output test is less accurate. The Fuzzing test method was developed by Barton Miller at the University of Wisconsin in 1988. In http://pages.cs.wisc.edu /~ More information about the fuzz test is available on bart/fuzz.

Fuzzers is often used to detect security vulnerabilities because they can test a large amount of unimaginable input. In particular, Fuzzers is often used to detect input verification problems. The heart bleeding vulnerability is generated based on input verification errors. However, typical Fuzzers cannot detect a heartbleed vulnerability because:

1. The heartbleed vulnerability is caused by buffer read overflow, rather than buffer write overflow. Most Fuzzers only send a large amount of data and find program crashes. However, when the buffer write overflow often causes a crash, the buffer write overflow will not crash in the normal environment. In the Fuzzing process, some countermeasures may even be used to solve the write overflow, rather than read overflow, such as canary-based protection methods and non-execution stacks. Reliability is not a big problem, because there is a way to crash due to overflow, or use other testing tools to test... This will bring us a second problem.

2. OpenSSL includes its memory allocation path, which will be frequently used unless special debugging methods are used. Even worse, these special methods cannot work normally. In particular, when OpenSSL uses its own application to manage the cache to improve performance, rather than simply relying on the memory management path. This type of application management cache can block many typical cache routines, including testing tools such as electric fence, valgrind, and address sanitizer. This means that when the fuzz test is used to test the cache path, the test ignores some special situations.

 

Because encryption technology can greatly reduce fuzz test invalidity, unless fuzzer has a password and a password library dedicated to attack. There are some fuzzing statements that cannot be strictly executed in OpenSSL and some cryptographic libraries. However, there is nothing to prevent the password from being obtained by fuzzers. In addition, the heartbleed vulnerability is even detected without a password. Therefore, fuzzing becomes invalid when the overflow is read and OpenSSL uses its memory cache allocation path for joint use.

Iii. What is used to combat the vulnerability similar to heartbleed?

Here are some of the software and tools that can previously combat heartbleed vulnerabilities. I will introduce some useful and free open source and source code software.

First, there are some instructions:

Do not use only one tool or technology to develop security software. Security software development requires a collection of methods. At first, you need to know how to develop security software. Most organizations initially use concise and clear methods to develop security software, enable and pay attention to the warning signs of the editor, and use source code vulnerability analysis tools to allow multiple people to study and run fuzzers, use a large number of automated intrusion tool kits. If you only use one technology, you can only defend against the last attack instead of this attack. For example, a large amount of warning signs are ignored, and even a warning sign cannot detect heartbleed. That is to say, when an attack succeeds, the most important thing is how to improve the software. Attackers may intrude into the software in the same way. Better improvements can also defend against other attacks.

There is no list of tools and technologies. Different tools have different purposes. Refer to [BAH2009] [NIST] for details.