【技术分享】OpenSSL握手重协商过程中存在漏洞可导致拒绝服务

阅读量187324

|

发布时间 : 2017-05-22 17:29:17

x
译文声明

本文是翻译文章,文章来源:mcafee.com

原文地址:https://securingtomorrow.mcafee.com/mcafee-labs/vulnerable-openssl-handshake-renegotiation-can-trigger-denial-service/

译文仅供参考,具体内容表达以及含义原文为准。

https://p3.ssl.qhimg.com/t01cd2278e81edf92b5.jpg

翻译:興趣使然的小胃

预估稿费:100RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


一、前言

OpenSSL是一个非常流行的通用加密库,可为Web认证服务提供SSL/TLS协议的具体实现。最近以来,人们发现OpenSSL中存在几个漏洞。我们写过几篇文章分析这些漏洞,包括“CVE-2017-3731:截断数据包可导致OpenSSL拒绝服务”、“SSL死亡警告(CVE-2016-8610)可导致OpenSSL服务器拒绝服务”等。今天,我们将要分析的是CVE-2017-3733这个高危级漏洞,即Encrypt-Then-MAC(加密后消息认证码)重新协商崩溃漏洞,可导致OpenSSL拒绝服务。

在使用SSL/TLS协议加密数据之前,OpenSSL会先发起Handshake协议(握手)以及ChangeCipherSpec协议(更改密钥规格)的处理流程。

在Handshake阶段,客户端和服务器共同协商使用哪种加密算法。一旦协商完成,客户端和服务器会各自向对方发送一个ChangedCipherSpec消息,之后通信流量会使用协商好的算法进行加密。

在SSL/TLS中,加密数据会与MAC(Message Authentication Code,消息认证码)一起,使用以下两种方式进行发送:

1、MAC-then-encrypt(消息认证码后加密):这种方式会先计算纯文本的MAC,并将其与纯文本连接,再使用加密算法生成最终的密文。

2、Encrypt-then-MAC(加密后消息认证码):这种方式会先加密纯文本,并将已加密纯文本的MAC附加在尾部,形成最终的密文。

如果ClientHello消息没有包含Encrypt-Then-Mac扩展,那么默认情况下使用的是MAC-then-encrypt模式。如果ClientHello消息包含Encrypt-Then-Mac扩展,那么服务器就会在加密数据后计算MAC。

如果客户端或服务器希望更改加密算法,它们可以重新协商之前已确认的密码套件(Cipher Suites)。重新协商过程可以发生在数据传输的任何阶段中,只需要在已有的SSL连接中发起一个初始化Handshake即可。


二、漏洞触发

关于这个漏洞,OpenSSL的官方解释如下:

“在handshake重新协商中,如果协商过程中包含Encrypt-Then-Mac扩展,而原始的handshake中不包含该扩展(反之亦然),那么OpenSSL就会崩溃(取决于所使用的密码套件)。客户端和服务器都会受到影响”。

假设客户端使用默认的MAC-then-encrypt模式发起与服务器的TLS握手流程。如果客户端使用Encrypt-then-MAC扩展发起重新协商流程,并在ChangeCipherSpec消息之前以该模式发送加密数据,那么服务器就会崩溃,导致拒绝服务。

当客户端触发这个漏洞时,服务器的崩溃点位于“ssl3_get_record”函数中,该函数位于“ssl3_record.c”文件中,如下所示:

http://p1.qhimg.com/t0194ded896d059fc7f.png

崩溃点位于352行,此时程序正在检查mac_size变量值是否小于EVP_MAX_MD_SIZE的值(64字节):

http://p4.qhimg.com/t01b659cfaba11d146a.png

if语句判断断言(assertion)语句是否成立,即判断服务器中是否设置了Encypt-then-MAC标识。if语句中的宏如下:

http://p1.qhimg.com/t01925067a33d0e6e16.png

在重新协商过程中,当使用Encrypt-then-MAC扩展发送ClientHello报文时,TLS1_FLAGS_ECRYPT_THEN_MAC标识已经被设置。因此if条件满足,程序会进入if内部的处理流程。但是由于ChangeCipherSpec消息还没有传递给服务器,服务器并不知道它必须使用Encrypt-then-MAC扩展。

在352行设置断点,检查mac_size变量的值,我们发现该至为0xffffffff,这个值比EVP_MAX_MD_SIZE的值(64字节)大。因此断言错误,导致服务器崩溃。

http://p6.qhimg.com/t017896c2bc9159a910.png

让我们好好分析一下源码,看看为什么mac_size的值会是0xffffffff。我们发现EVP_MD_CTX_size函数负责计算mac_size变量的值:

http://p2.qhimg.com/t011ead64dfee3c824a.png

上述代码中,如果md(message digest,消息摘要)的值为null,函数就会返回-1,而0xffffffff刚好是-1的二进制补码形式。这意味着“s->read_hash”语句会返回null,因为此时服务器会尝试使用MAC-then-encrypt模式计算哈希值。

以上就是OpenSSL漏洞的分析过程。

本文翻译自mcafee.com 原文链接。如若转载请注明出处。
分享到:微信
+10赞
收藏
興趣使然的小胃
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66