翻译:興趣使然的小胃
预估稿费: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”文件中,如下所示:
崩溃点位于352行,此时程序正在检查mac_size变量值是否小于EVP_MAX_MD_SIZE的值(64字节):
if语句判断断言(assertion)语句是否成立,即判断服务器中是否设置了Encypt-then-MAC标识。if语句中的宏如下:
在重新协商过程中,当使用Encrypt-then-MAC扩展发送ClientHello报文时,TLS1_FLAGS_ECRYPT_THEN_MAC标识已经被设置。因此if条件满足,程序会进入if内部的处理流程。但是由于ChangeCipherSpec消息还没有传递给服务器,服务器并不知道它必须使用Encrypt-then-MAC扩展。
在352行设置断点,检查mac_size变量的值,我们发现该至为0xffffffff,这个值比EVP_MAX_MD_SIZE的值(64字节)大。因此断言错误,导致服务器崩溃。
让我们好好分析一下源码,看看为什么mac_size的值会是0xffffffff。我们发现EVP_MD_CTX_size函数负责计算mac_size变量的值:
上述代码中,如果md(message digest,消息摘要)的值为null,函数就会返回-1,而0xffffffff刚好是-1的二进制补码形式。这意味着“s->read_hash”语句会返回null,因为此时服务器会尝试使用MAC-then-encrypt模式计算哈希值。
以上就是OpenSSL漏洞的分析过程。
发表评论
您还未登录,请先登录。
登录