被称为“核弹级别”的OpenSSL漏洞

1.首先看下新闻：

转自：http://tech.sina.com.cn/i/2014-04-09/10049307446.shtml

　新浪科技讯 北京时间4月9日上午消息，美国新闻网站Vox周二撰文，对当天公布的OpenSSL“心脏流血”漏洞进行了全面解读。

　　以下为文章全文：

　　什么是SSL？

　　SSL是一种流行的加密技术，可以保护用户通过互联网传输的隐私信息。当用户访问Gmail.com等安全网站时，就会在URL地址旁看到一个“锁”，表明你在该网站上的通讯信息都被加密。

　　这个“锁”表明，第三方无法读取你与该网站之间的任何通讯信息。在后台，通过SSL加密的数据只有接收者才能解密。如果不法分子监听了用户的对话，也只能看到一串随机字符串，而无法了解电子邮件、Facebook(59.99, 1.80, 3.09%)帖子、信用卡账号或其他隐私信息的具体内容。

　　SSL最早在1994年由网景推出，1990年代以来已经被所有主流浏览器采纳。最近几年，很多大型网络服务都已经默认利用这项技术加密数据。如今，谷歌(557.96, 3.06,0.55%)、雅虎(34.18, 0.35, 1.03%)和Facebook都在使用SSL默认对其网站和网络服务进行加密。

　　什么是“心脏出血”漏洞？

　　多数SSL加密的网站都使用名为OpenSSL的开源软件包。本周一，研究人员宣布这款软件存在严重漏洞，可能导致用户的通讯信息暴露给监听者。OpenSSL大约两年前就已经存在这一缺陷。

　　工作原理：SSL标准包含一个心跳选项，允许SSL连接一端的电脑发出一条简短的信息，确认另一端的电脑仍然在线，并获取反馈。研究人员发现，可以通过巧妙的手段发出恶意心跳信息，欺骗另一端的电脑泄露机密信息。受影响的电脑可能会因此而被骗，并发送服务器内存中的信息。

　　该漏洞的影响大不大？

　　很大，因为有很多隐私信息都存储在服务器内存中。普林斯顿大学计算机科学家艾德·菲尔腾(Ed Felten)表示，使用这项技术的攻击者可以通过模式匹配对信息进行分类整理，从而找出密钥、密码，以及信用卡号等个人信息。

　　丢失了信用卡号和密码的危害有多大，相信已经不言而喻。但密钥被盗的后果可能更加严重。这是是信息服务器用于整理加密信息的一组代码。如果攻击者获取了服务器的私钥，便可读取其收到的任何信息，甚至能够利用密钥假冒服务器，欺骗用户泄露密码和其他敏感信息。

　　谁发现的这个问题？

　　该漏洞是由Codenomicon和谷歌安全部门的研究人员独立发现的。为了将影响降到最低，研究人员已经与OpenSSL团队和其他关键的内部人士展开了合作，在公布该问题前就已经准备好修复方案。

　　谁能利用“心脏流血”漏洞？

　　“对于了解这项漏洞的人，要对其加以利用并不困难。”菲尔腾说。利用这项漏洞的软件在网上有很多，虽然这些软件并不像iPad应用那么容易使用，但任何拥有基本编程技能的人都能学会它的使用方法。

　　当然，这项漏洞对情报机构的价值或许最大，他们拥有足够的基础设施来对用户流量展开大规模拦截。我们知道，美国国家安全局(以下简称“NSA”)已经与美国电信运营商签订了秘密协议，可以进入到互联网的骨干网中。用户或许认为，Gmail和Facebook等网站上的SSL加密技术可以保护他们不受监听，但NSA 却可以借助“心脏流血”漏洞获取解密通讯信息的私钥。

　　虽然现在还不能确定，但如果NSA在“心脏流血”漏洞公之于众前就已经发现这一漏洞，也并不出人意料。OpenSSL是当今应用最广泛的加密软件之一，所以可以肯定的是，NSA的安全专家已经非常细致地研究过它的源代码。‘

　　有多少网站受到影响？

　　目前还没有具体的统计数据，但发现该漏洞的研究人员指出，当今最热门的两大网络服务器Apache和nginx都使用OpenSSL。总体来看，这两种服务器约占全球网站总数的三分之二。SSL还被用在其他互联网软件中，比如桌面电子邮件客户端和聊天软件。

　　发现该漏洞的研究人员几天前就已经通知OpenSSL团队和重要的利益相关者。这让OpenSSL得以在漏洞公布当天就发布了修复版本。为了解决该问题，各大网站需要尽快安装最新版OpenSSL。

　　雅虎发言人表示：“我们的团队已经在雅虎的主要资产中(包括雅虎主页、雅虎搜索、雅虎电邮、雅虎财经、雅虎体育、雅虎美食、雅虎科技、Flickr和Tumblr)成功部署了适当的修复措施，我们目前正在努力为旗下的其他网站部署修复措施。”

　　谷歌表示：“我们已经评估了SSL漏洞，并且给谷歌的关键服务打上了补丁。”Facebook称，在该漏洞公开时，该公司已经解决了这一问题。

　　微软(40.22, 0.40, 1.00%)发言人也表示：“我们正在关注OpenSSL问题的报道。如果确实对我们的设备和服务有影响，我们会采取必要措施保护用户。”

　　用户应当如何应对该问题？

　　不幸的是，如果访问了受影响的网站，用户无法采取任何自保措施。受影响的网站的管理员需要升级软件，才能为用户提供适当的保护。

　　不过，一旦受影响的网站修复了这一问题，用户便可以通过修改密码来保护自己。攻击者或许已经拦截了用户的密码，但用户无法知道自己的密码是否已被他人窃取。(书聿)

2.关于OpenSSL介绍：

转自：http://zh.wikipedia.org/wiki/OpenSSL

OpenSSL是套开放源代码的SSL套件，其函式库是以C语言所写成，实作了基本的传输层资料加密功能。

此软件是以Eric Young以及Tim Hudson两人所写的SSLeay为基础所发展的，SSLeay随着两人前往RSA公司任职而停止开发。

虽然此软件是开放源代码的，但其授权书条款与GPL有冲突之处，故GPL软件使用OpenSSL时（如Wget）必须对OpenSSL给予例外。

OpenSSL版本历史 ^[2]

版本	发布时间	备注
0.9.1c	1998年12月23日
0.9.2c	1999年3月22日	取代0.9.1c
0.9.3	1999年5月25日	取代0.9.2b
0.9.4	1999年8月9日	取代0.9.3a
0.9.5	2000年2月28日	取代0.9.4
0.9.6	2000年9月25日	取代0.9.5a
0.9.7	2002年12月31日	取代0.9.6h
0.9.8	2005年7月5日	取代0.9.7h
1.0.0	2010年3月29日	取代0.9.8x
1.0.1	2012年3月14日	取代1.0.0e 支持TLS v1.2 SRP支持
1.0.1g	2014年4月7日	当前版本

老版本

当前版本

未来版本

OpenSSL支持多种不同的加密算法

加密：

AES,  Blowfish,  Camellia,  SEED,  CAST-128,  DES,  IDEA,  RC2,  RC4,  RC5,  Triple DES,  GOST 28147-89 ^[3]

散列函数：

MD5,  MD2,  SHA-1,  SHA-2,  RIPEMD-160,  MDC-2,  GOST R 34.11-94 ^[3]

公开密钥加密：

RSA, DSA, Diffie–Hellman key exchange, Elliptic curve, GOST R 34.10-2001^[3]

3.关于事件的分析：

转自：http://daily.zhihu.com/story/3823890?utm_campaign=in_app_share&utm_medium=Android

作者：Evi1m0

2014 年 4 月 8 日，XP 宣布正式停止服务的日子，也是 Openssl 爆出大漏洞的日子。

整个下午我们都处于应急状态中，精神紧绷，这个漏洞影响 30-50%比例使用 https 的网站，其中包括大家经常访问的：支付宝、微信、淘宝、网银、社交、门户等知名网站。

只要访问 https 的网站便有可能存在被嗅探数据的风险，下午 5 点左右ZoomEye完成了这个数据扫描：全国 443 端口：1601250，有 33303 个受本次 OpenSSL 漏洞影响！不知道放眼世界，有多少使用 https 的受到威胁。

OpenSSL 是什么？

他为网络通信提供安全及数据完整性的一种安全协议，囊括了主要的密码算法、常用的密钥和证书封装管理功能以及 SSL 协议，并提供了丰富的应用程序供测试或其它目的使用。

OpenSSL 漏洞

OpenSSL 是一种开放源码的 SSL 实现，用来实现网络通信的高强度加密，现在被广泛地用于各种网络应用程序中。OpenSSL Heartbleed 模块存在一个 BUG，当攻击者构造一个特殊的数据包，满足用户心跳包中无法提供足够多的数据会导致 memcpy 把 SSLv3 记录之后的数据直接输出，该漏洞导致攻击者可以远程读取存在漏洞版本的 openssl 服务器内存中长大 64K 的数据。

存在该漏洞的版本

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable

简单的说，黑客可以对使用 https(存在此漏洞)的网站发起攻击，每次读取服务器内存中 64K 数据，不断的迭代获取，内存中可能会含有程序源码、用户 http 原始请求、用户 cookie 甚至明文帐号密码等。

漏洞爆发后

甲方公司运维、安全开始紧急预警修复升级，乙方公司忙着帮互联网去测试有多少网站受影响以及推出检测脚本，网民们却不知情。只能傻傻的看着微博满屏的 OpenSSL 暴漏洞了！ 黑客们开始搞起来吧！但这确实是一个不眠之夜，太多的网站受到影响，很多用户不知情仍然在访问着老虎嘴中的站点。

懂技术的人开始研究这个漏洞并编写起自己的检测脚本以及嗅探程序，不懂的小黑客们也照猫画虎的玩起这个漏洞，归根结底受害的还是蒙在鼓里的人们。

这个漏洞影响究竟有多大？

收到这个漏洞后我们最先测试了https://alipay.com 确认存在此漏洞，发起检测。

之后我们又发现雅虎门户主页、微信公众号、微信网页版、YY 语言、淘宝、网银、陌陌、社交、门户网站存在此漏洞。

上面是嗅探到陌陌的部分数据，整个数据包里面包含详细经纬度、陌陌 UID、版本、手机型号等详细信息。

同样，在另外一个社交网站中我获取到了用户登录的帐号以及密码甚至是安全问题与答案，这里的密码使用的明文传输，以至于通过这样的漏洞攻击我成功的登录了上百个账户，当然我什么都没做，出于测试而已。

用户修改密码、发送消息、登录等请求以及很多操作全部在数据包中暴露出来，这里我就不列举更多受影响的网站了。其实这个漏洞据说早在 2012 年就被挖掘出来，直到昨天 CVE 纳入编号 CVE-2014-0160，8 号才正式爆发。使用 HTTPS 的网站大多是因为数据需加密防止嗅探等攻击的发生，漏洞爆发后彻底将这层大门打破，于是很多网站处于被监听的状态中。

此漏洞 POC 早已有人公布，所以导致 WooYun 漏洞平台上很多白帽子开始对大范围网站进行了测试刷分，场面颇为壮观：

因此漏洞非用户安全所致，只要网站使用了存在漏洞的 OpenSSL 版本，用户登录该网站时就可能被黑客实时监控到登录账号和密码，此漏洞应由服务商尽快提供 OpenSSL 的升级。

可喜的是诸如腾讯、网易、淘宝这些大的厂商对安全问题的应急相应速度很快，很多存在 OpenSSL 问题的网站已经修复，剩下一些相信也会通过白帽子们的努力很快修复。

截止 8 号 23：00，L 对我说：不少大型网站的数据还在不断嗅探录入。

4.关于漏洞的分析与修复：

转自：http://drops.wooyun.org/papers/1381

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

当我分析GnuTLS的漏洞的时候，我曾经说过，那不会是我们看到的最后一个TLS栈上的严重bug。然而我没想到这次OpenSSL的bug会如此严重。

OpenSSL“心脏出血”漏洞是一个非常严重的问题。这个漏洞使攻击者能够从内存中读取多达64 KB的数据。一些安全研究员表示：

无需任何特权信息或身份验证，我们就可以从我们自己的（测试机上）偷来X.509证书的私钥、用户名与密码、聊天工具的消息、电子邮件以及重要的商业文档和通信等数据。

这一切是如何发生的呢？让我们一起从代码中一探究竟吧。

0x01 Bug

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

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记录所遵循的存储格式请参见下文分析）：

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：

/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;

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

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

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是用来访问这段内存区域的指针。

/* 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 漏洞修补

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

/* 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的心跳包，然后第二步检查确保了心跳包足够长。就这么简单。

0x02 前车之鉴

我们能从这个漏洞中学到什么呢？

我是C的粉丝。这是我最早接触的编程语言，也是我在工作中使用的第一门得心应手的语言。但是和之前相比，现在我更清楚地看到了C语言的局限性。

从GnuTLS漏洞和这个漏洞出发，我认为我们应当做到下面三条：

花钱请人对像OpenSSL这样的关键安全基础设施进行安全审计；
为这些库写大量的单元测试和综合测试；
开始在更安全的语言中编写替代品。

考虑到使用C语言进行安全编程的困难性，我不认为还有什么其他的解决方案。我会试着做这些，你呢？

作者简介：Sean是一位关于如何把事儿干好的软件工程师。现在他在Squadron工作。Squadron是一个专为SaaS应用程序准备的配置与发布管理工具。

测试版本的结果以及检测工具：

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable