概述

OpenSSL 心血(HeartBleed)漏洞 是openssl 在 2014-04-07 公布的重大安全漏洞（CVE-2014-0160）这个漏洞使攻击者能够从服务器内存中读取64 KB的数据，甚至获取到加密流量的密钥，用户的名字和密码，以及访问的内容。

主要影响版本 OpenSSL 1.0.1 到 OpenSSL 1.0.1f  以及 OpenSSL 1.0.2 Beta1

不受此漏洞影响的 OpenSSL版本信息：
OpenSSL 1.0.1g 已修复该漏洞 
OpenSSL 1.0.0 分支版本不受此漏洞影响 
OpenSSL 0.9.8 分支版本不受此漏洞影响 
OpenSSL 1.0.2 Beta2 不受此漏洞影响

 

 

确认站点是否存在此漏洞

1.可以直接利用在线工具检测 https站点是否存在此漏洞(快捷、准确)

https://www.trustasia.com/tools/bleed-checker/

 

 

未受此漏洞影响的站点：

 

 

 

受此漏洞影响的站点： 

2.查看提供加密服务的OpenSSL版本是否在受影响的版本范围 ( 1.0.1—1.0.1f / 1.0.2 Beta1 )

 

操作系统openssl版本查看：

命令：openssl version

结果：OpenSSL 1.0.0-fips 29 Mar 2010

 

nginx openssl版本查看：

 

命令： nginx –V

结果：

nginx version: nginx/1.5.13

built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)

TLS SNI support enabled

configure arguments: --prefix=/usr/local/nginx-1.5.13 --with-select_module --with-http_ssl_module --with-openssl=/home/user/openssl-1.0.1g --with-http_spdy_module --with-pcre=/home/user/pcre-8.33 --with-zlib=/home/user/zlib-1.2.8

 

windows Apache openssl版本查看：

命令：D:\httpd-2.4.7-x64\Apache24\bin>openssl version

结果：

WARNING: can't open config file: /apache24/conf/openssl.cnf

OpenSSL 1.0.1e 11 Feb 2013

 

 

 

修复方案

Openssl:

升级OpenSSL 1.0.1g

 

Nginx:

官方在 2014-04-08 发布了最新版本 1.5.13 修复了此漏洞请升级至最新版本

 

Apache：

建议下载最新版本openssl 和 Apache

重新编译安装。

 

其他受影响的WebServer：

建议到官方更新不受此漏洞影响的版本

 

 

漏洞分析

OpenSSL是Apache和nginx网络服务器的默认安全协议，此外大量操作系统、电子邮件和即时通讯系统也采用OpenSSL加密用户数据 通讯。而此次发现的bug已经存在两年之久，这意味着攻击者可以利用该bug获取大量互联网服务器与用户之间的数字证书私钥，从而获取用户账户密码等敏感 数据。由于攻击者不会在服务器日志中留下痕迹，因此网站系统管理员将无法得知系统漏洞是否已经被黑客利用，也无从得知用户数据和账号是否已经被黑客扫描获

 

OpenSSL已经发布了1.0.1g修正bug，Debian发行版也在半小时修复了bug，Fedora发布了一个权宜的修正方案。 该bug是在2011年引入到OpenSSL中，使用OpenSSL 0.9.8的发行版不受影响，但Debian Wheezy、Ubuntu 12.04.4、 Centos 6.5、Fedora 18、SuSE 12.2、OpenBSD 5.4、FreeBSD 8.4和NetBSD 5.0.2之后的版本都受到影响。如果你运行存在该bug的系统，那么最好废除所有密钥。

 

 

源码分析

原作者：Sean Cassidy 原作者Twitter：@ex509 原作者博客：http://blog.existentialize.com 来源：http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

0x01 Bug

请看ssl/dl_both.c，漏洞的补丁从这行语句开始：

1

2

3

4

5

6

7

int            

dtls1_process_heartbeat(SSL *s)

    {          

    unsigned char *p = &s->s3->rrec.data[0], *pl;

    unsigned short hbtype;

    unsigned int payload;

    unsigned int padding = 16; /* Use minimum padding */

一上来我们就拿到了一个指向一条SSLv3记录中数据的指针。结构体SSL3_RECORD的定义如下（译者注：结构体SSL3_RECORD不是SSLv3记录的实际存储格式。一条SSLv3记录所遵循的存储格式请参见下文分析）：

1

2

3

4

5

6

7

8

9

10

11

typedef struct ssl3_record_st

    {

        int type;               /* type of record */

        unsigned int length;    /* How many bytes available */

        unsigned int off;       /* read/write offset into 'buf' */

        unsigned char *data;    /* pointer to the record data */

        unsigned char *input;   /* where the decode bytes are */

        unsigned char *comp;    /* only used with decompression - malloc()ed */

        unsigned long epoch;    /* epoch number, needed by DTLS1 */

        unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */

    } SSL3_RECORD;

每条SSLv3记录中包含一个类型域（type）、一个长度域（length）和一个指向记录数据的指针（data）。我们回头去看dtls1_process_heartbeat：

1

2

3

4

/* Read type and payload length first */

hbtype = *p++;

n2s(p, payload);

pl = p;

SSLv3记录的第一个字节标明了心跳包的类型。宏n2s从指针p指向的数组中取出前两个字节，并把它们存入变量payload中——这实际上是心跳包载荷的长度域（length）。注意程序并没有检查这条SSLv3记录的实际长度。变量pl则指向由访问者提供的心跳包数据。

这个函数的后面进行了以下工作：

1

2

3

4

5

6

7

8

9

unsigned char *buffer, *bp;

int r;

 

/* 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);

bp = buffer;

所以程序将分配一段由访问者指定大小的内存区域，这段内存区域最大为 (65535 + 1 + 2 + 16) 个字节。变量bp是用来访问这段内存区域的指针。

1

2

3

4

/* Enter response type, length and copy payload */

*bp++ = TLS1_HB_RESPONSE;

s2n(payload, bp);

memcpy(bp, pl, payload);

宏s2n与宏n2s干的事情正好相反：s2n读入一个16 bit长的值，然后将它存成双字节值，所以s2n会将与请求的心跳包载荷长度相同的长度值存入变量payload。然后程序从pl处开始复制payload个字节到新分配的bp数组中——pl指向了用户提供的心跳包数据。最后，程序将所有数据发回给用户。那么Bug在哪里呢？

0x01a 用户可以控制变量payload和pl

如果用户并没有在心跳包中提供足够多的数据，会导致什么问题？比如pl指向的数据实际上只有一个字节，那么memcpy会把这条SSLv3记录之后的数据——无论那些数据是什么——都复制出来。

很明显，SSLv3记录附近有不少东西。

说实话，我对发现了OpenSSL“心脏出血”漏洞的那些人的声明感到吃惊。当我听到他们的声明时，我认为64 KB数据根本不足以推算出像私钥一类的数据。至少在x86上，堆是向高地址增长的，所以我认为对指针pl的读取只能读到新分配的内存区域，例如指针bp指向的区域。存储私钥和其它信息的内存区域的分配早于对指针pl指向的内存区域的分配，所以攻击者是无法读到那些敏感数据的。当然，考虑到现代malloc的各种神奇实现，我的推断并不总是成立的。

当然，你也没办法读取其它进程的数据，所以“重要的商业文档”必须位于当前进程的内存区域中、小于64 KB，并且刚好位于指针pl指向的内存块附近。

研究者声称他们成功恢复了密钥，我希望能看到PoC。如果你找到了PoC，请联系我。

0x01b 漏洞修补

修复代码中最重要的一部分如下：

1

2

3

4

5

6

7

8

/* 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;

这段代码干了两件事情：首先第一行语句抛弃了长度为0的心跳包，然后第二步检查确保了心跳包足够长。就这么简单。