[OpenSSL] source code analysis of the Heartbleed Vulnerability

OpenSSL? Heartbleed vulnerability? Still panic? Calm, calm! After you understand the principles of a vulnerability, you will not fear it any more, or you will treat it more rationally after reading it. This article first introduces what is the Heartbleed vulnerability, then analyzes the vulnerability from the perspective of openssl source code, and finally summarizes what lessons we can learn from it.

OpenSSL TLS heartbeat read remote information leakage (CVE-2014-0160)

Severe OpenSSL bug allows attackers to read 64 KB of memory, fixed in half an hour in Debian

OpenSSL "heartbleed" Security Vulnerability

Provides FTP + SSL/TLS authentication through OpenSSL and implements secure data transmission.

Preface

The most popular thing in the IT field recently is the openssl heartbleed vulnerability. This article will not repeat the terrible consequences of this vulnerability. As a programmer, if we just look at this vulnerability or look at it with an indifferent attitude, then we are really a programmer.

When a vulnerability is discovered, you may first think about how to quickly fix it. But when we know what the vulnerability is, everything becomes less terrible, just like the heartbleed vulnerability in openssl.

Through this article, you can learn about the recent popular openssl heartbleed vulnerability and learn about it. After you understand the nature of this vulnerability, you will choose a more light way to fix the problem, instead of panic. Or you have fixed the vulnerability, but you are curious about the vulnerability. Why is the vulnerability name so serious? What a terrible situation is "heartbleed?

In addition, when you understand this vulnerability, you will be more rational in the face of various online rumors, you will have more judgment, such a simple vulnerability, why has it never been exposed? Why is it exposed now? How much is our private information leaked?

There may be a lot of detailed analysis on this vulnerability on the Internet, but why do I need to write this article? This article aims to describe the vulnerability in the most concise and easy-to-understand language? After reading the previous example, you can easily understand the specific source code.

Technical blogs are not about how new and profound technology is, but about how to make it easy to understand, just like the heartbleed vulnerability in openssl, although there have been a lot of good analysis articles on the internet, I would like to make more people understand the nature of this vulnerability in a simple way.

Heartbleed vulnerability Introduction

What is the heartbleed vulnerability? You may have learned about the vulnerability from different channels, but you need to briefly describe it in this article to help you better understand the vulnerability.

After both parties establish a secure connection based on openssl, the client must continuously send heartbeat information to the server to ensure that the server is available.

The basic process is: the client sends a fixed-length string to the server. After receiving the string, the server returns the fixed-length string. For example, if the client sends the "hello, world" string to the server, and the server returns the "hello, world" string as is after receiving the string, the client will think that the openssl server is available.

Assume that the heartbeat information structure sent by the client is defined:

Struct hb {
Int type;
Int length;
Unsigned char * data;
};

Type indicates the heartbeat type and length indicates the size of data. The structure of data is that the type field occupies one byte, the payload field occupies two bytes, and the rest is the specific content of payload, the specific structure information is as follows:

Byte number remarks

0 type

The size of the specific content in 1-2 data is payload.

3-len specific content pl

When the server receives the message, it will parse the message, that is, it will parse the string in the data, get the type by parsing the 0th bits, get the payload by the 1-2 bits, apply for (1 + 2 + payload) memory size, and then copy the corresponding data to the new memory.

The following is a simple example to illustrate this problem. If the data sent by the client is "006 abcdef", type = 0, payload = 06, pl = 'abcdef', apply for (1 + 2 + 6 = 9) memory, and then write type, payload, and pl to the newly applied memory.

If everyone is honest, the above process will not have any problems. However, there are always so many people in the world who don't "score". They will be very dishonest. For example, there are only six strings "abcdef" sent by the client, but I have to set payload to 500. If the server does not perform any boundary check when it is silly, directly apply for (1 + 2 + 500) memory size, in addition, all the content of "abcdef **********" is copied to the newly applied memory and sent back to the client.

In this way, the restless people will obtain a lot of sensitive information on the server, which may include bank account information, electronic transaction information, and many other security information.

So far, you may have a preliminary understanding of the heartbleed vulnerability. Next, let's take a look at what its source code looks like.

Source code analysis of the heartbleed Vulnerability

We have briefly described the heartbleed vulnerability. You should have a preliminary understanding of it. Next, let's take a look at what the heartbleed vulnerability of openssl is like.

Let's take a look at the differences between the code they recently fixed and submitted and the previous code.

--- A/ssl/d1_both.c
++ B/ssl/d1_both.c
@-1459,26 + 1459,36 @ dtls1_process_heartbeat (SSL * s)
Unsigned int payload;
Unsigned int padding = 16;/* Use minimum padding */
 
-/* Read type and payload length first */
-Hbtype = * p ++;
-N2s (p, payload );
-Pl = p;
-
If (s-> msg_callback)
S-> msg_callback (0, s-> version, TLS1_RT_HEARTBEAT,
& S-> s3-> rrec. data [0], s-> s3-> rrec. length,
S, s-> msg_callback_arg );
 
+/* Read type and payload length first */
+ If (1 + 2 + 16> s-> s3-> rrec. length)
+ Return 0;/* silently discard */
+ Hbtype = * p ++;
+ N2s (p, payload );
+ If (1 + 2 + payload + 16> s-> s3-> rrec. length)
+ Return 0;/* silently discard per RFC 6520 sec. 4 */
+ Pl = p;
+
If (hbtype = TLS1_HB_REQUEST)
{
Unsigned char * buffer, * bp;
+ Unsigned int write_length = 1/* heartbeat type */+
+ 2/* heartbeat length */+
+ Payload + padding;
Int r;
 
+ If (write_length> SSL3_RT_MAX_PLAIN_LENGTH)
+ Return 0;
+
/* Allocate memory for the response, size is 1 byte
* Message type, plus 2 bytes payload length, plus
* Payload, plus padding
*/
-Buffer = OPENSSL_malloc (1 + 2 + payload + padding );
+ Buffer = OPENSSL_malloc (write_length );
Bp = buffer;
 
/* Enter response type, length and copy payload */
@-1489,11 + 1499,11 @ dtls1_process_heartbeat (SSL * s)
/* Random padding */
Rand_pseudo _ bytes (bp, padding );
 
-R = dtls1_write_bytes (s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding );
+ R = dtls1_write_bytes (s, TLS1_RT_HEARTBEAT, buffer, write_length );
 
If (r> = 0 & s-> msg_callback)
S-> msg_callback (1, s-> version, TLS1_RT_HEARTBEAT,
-Buffer, 3 + payload + padding,
+ Buffer, write_length,
S, s-> msg_callback_arg );
 
OPENSSL_free (buffer );

From the above differences, we can see that the original method for the server to handle heartbeat is to directly parse the type and payload, and do nothing to check.

Unsigned int payload;
Unsigned int padding = 16;/* Use minimum padding */
 
-/* Read type and payload length first */
-Hbtype = * p ++;
-N2s (p, payload );
-Pl = p;
-

Next, let's take a look at how they handled the fix:

The sample code we introduced earlier differs from the data Format of openssl code in that openssl data is aligned with 16 bytes of data. Other formats are the same. The sample code is used to make everyone better understand the principle, so many details are not added, so it is difficult to understand the complexity.

Next, let's take a look at the two most important Judgment conditions added by openssl:

If (1 + 2 + 16> s-> s3-> rrec. length)
Return 0;/* silently discard */

 

The purpose of this judgment is to avoid processing the special case where the data length is 0;

If (1 + 2 + payload + 16> s-> s3-> rrec. length)
Return 0;/* silently discard per RFC 6520 sec. 4 */

From this judgment condition, we can see that the payload size is checked. If the length is exceeded, it indicates that you may be under a malicious attack and return 0 directly.

Conclusion

From the heartbleed vulnerability of openssl, we can see that despite the widely used openssl Technology and Its Application in many financial fields, there are still many fatal vulnerabilities. From the above analysis, you may find out why this vulnerability is called the heartbleed vulnerability, which is indeed too heart bleed.

If you are interested in openssl, follow-up blog posts will continue to analyze its implementation in depth.

After reading this article, many people are eager to learn about the related principles of the vulnerability and hope to have the attack sample code. This shows that everyone has understood the principles of the vulnerability through this article, it also reflected from the side that what I wrote is more concise and easy to understand. If you are interested in the attack, you can reply directly in the comments and create relevant blog posts in the future.

For more information about Heartbleed, click here.
Heartbleed: click here