首页 > 代码库 > OpenSSL再曝CCS注入漏洞-心伤未愈又成筛子
OpenSSL再曝CCS注入漏洞-心伤未愈又成筛子
太戏剧了，昨晚看了佳片有约，还不错，2012版的《完美回忆》，像我这种人依然选择用电视或者去影院看电影，在没有中间插播广告的时候，体验憋尿得过程中，总是能突然有很多的想法，这是用电脑或者手机看电影所体会不到的。看完以后已经12点半了，突然想再看一遍《黑客帝国》，这下不用电脑不行了，因为电视上没得播...结果正在缓冲的时候，突然看到了旁边的小公告：“OpenSSL再爆严重安全漏洞--CCS注入”，完了，电影看不成了，不是说不想看了，突然感觉自己比神还无耻，怎么人家曝出漏洞会这么高兴啊，关掉已经缓冲完毕的电影，就想看一下OpenSSL的笑话，同时心里还极度扭曲地想，我不最近在搞基于OpenSSL的一个修改么，向OpenSSL这种代码，就我这种垃圾coder配得上它，因为我的垃圾代码和它很般配...
当我看了一篇博客《How I discovered CCS Injection Vulnerability (CVE-2014-0224)》后，我觉得我错怪OpenSSL了，这次也许真的不是OpenSSL的错，而是RFC的错，即这次的这个漏洞不是实现问题，更多的是协议本身的设计问题。如果你还没有读过上面我提到的那篇博客，一定要看一下，如果看过了，我们就接着往下走，看看这个漏洞的一些细节。
我们知道，OpenSSL协议分了两个层次，一个是记录协议层，一个是数据协议层，后者包含了握手协议，告警协议，CCS协议等，注意这个“等”字，搞知道国密标准的应该知道这个等字的含义，不知道国密标准的人奉劝永远都不要知道，这次的CCS漏洞本质上就和这个“等”字有关。言归正传，SSL/TLS的安全通道通过握手协议建立，安全通道上通行的数据显然是加密的，而在握手过程中，在密钥等安全参数没有协商完成之前，数据都是明文的，那么在握手状态机中就肯定有那么一个点，在该点之前数据是明文的，而在该点之后数据是加密的，这个点就是接收到ChangeCipherSpec消息，问题是，这个消息在握手状态机中交换，但是却不在握手协议中定义，它被定义为一个单独的协议，不属于握手协议。这样做的理由，按照漏洞发现者Masashi Kikuchi在RFC挖掘出的理由那就是：
Note: To help avoid pipeline stalls, ChangeCipherSpec is
an independent SSL Protocol content type, and is not
actually an SSL handshake message.
这是一个什么理由？显然没有考虑安全因素。那么问题就来了，既然CCS独立于握手状态机，那么它便可以在握手过程中的任何一点收发，在协议层面并没有强制CCS必须要在master keys在握手协议中已经完备的情况下才能发送，如果那样强制，就是两个协议之间的交叠。事实上，依照规范而言，SSL/TLS的握手中，CCS的位置是被严格规定的，即master keys准备好之后，Finish消息之前，那么安全机制就必须由实现者自己负责。稍有不慎，关于握手协议和CCS之间的关系就会处理不好造成可以利用的漏洞。在一篇文章《Early ChangeCipherSpec Attack 》中，作者披露了OpenSSL1.0.1h是如何解决这个问题的，实际上加了不多的几行代码，其中之一就是ssl3_do_change_cipher_spec函数中的一个判断：
在之前的漏洞影响的版本中，并没有确认master_key_length不为0，这就意味着即便master key还没有准备好，也是可以发送CCS的，而这样的话，所谓的密钥也没有秘密可言了。CCS的发送时间并没有强制要求，但是要求master keys必须准备好！以下是一个基于中间人攻击的漏洞利用场景，中间人在作为server的时候，在ServerHelloDone完成后即发送一个CCS，注意此时还没有生成master keys，因此使用一个空值代替，由于OpenSSL在收到CCS的时候并没有检查自己的握手状态机处于哪一步骤，因此会无条件接收，此时它也没有master key，后面的事情就是使用不是密钥的密钥对数据进行加密，注意，由于OpenSSL的实现原因，只要已经经过了key的计算，在一个session中以后就不会再次计算，因此下面的代码(同样处于ssl3_do_change_cipher_spec中)事实上助长了漏洞：
关于SSL/TLS规范中将CCS设计成独立的一个数据协议，我在《TCP/IP协议族》这本经典教材中找到了更真切的理由，那就是它将发送方和接收方分割成了两个状态，按照分权原则，这个事不能在握手协议本身完成。
漏洞发现者Masashi Kikuchi所述，只要保证几点即可，非常简单：
IMHO, this sentence is the very cause of the vulnerability. According to it, the reason that CCS is assigned an independent record type is to avoid a stall. This is the point where the most complex synchronization is required in TLS/SSL handshake. First, you need to wait until the handshake proceeds to the proper phase. Then, you need to check whether the handshake receives CCS before Finish.
More precisely, when accepting CCS, you must verify the following three conditions (*):
the handshake proceeds to the proper phase, i.e., just before to receive Finished,
no fragments from the handshake remains,
and, the next message is Finished.
Being more careful, you should also check
no Alert fragment remains (they can be rejected in the first place),
and, no Heartbeat fragment remains
事实很简单，保证CCS发送的时候，master keys真的已经准备好了，这实际上就是CCS本身的意思，如果我能跟我的三岁的小小讲清楚这个，她肯定会说她的口头禅：难道不是吗？
一个独立的CCS协议，独立于握手协议的CCS协议，在SSL/TLS中必然不可能是完全独立的，协议封装上是独立的，语义却不可能是独立的，否则，我在ClientHello后发送一个CCS，可否？唉，心病还未痊愈，CCS又来捣乱，如果说心脏出血是OpenSSL的问题的话(它实际上是一个低级的代码级错误)，CCS漏洞则是一个协议层面的问题，这个问题可不低级！我相信不止OpenSSL的实现会有这个问题。
当我看了一篇博客《How I discovered CCS Injection Vulnerability (CVE-2014-0224)》后，我觉得我错怪OpenSSL了，这次也许真的不是OpenSSL的错，而是RFC的错，即这次的这个漏洞不是实现问题，更多的是协议本身的设计问题。如果你还没有读过上面我提到的那篇博客，一定要看一下，如果看过了，我们就接着往下走，看看这个漏洞的一些细节。
我们知道，OpenSSL协议分了两个层次，一个是记录协议层，一个是数据协议层，后者包含了握手协议，告警协议，CCS协议等，注意这个“等”字，搞知道国密标准的应该知道这个等字的含义，不知道国密标准的人奉劝永远都不要知道，这次的CCS漏洞本质上就和这个“等”字有关。言归正传，SSL/TLS的安全通道通过握手协议建立，安全通道上通行的数据显然是加密的，而在握手过程中，在密钥等安全参数没有协商完成之前，数据都是明文的，那么在握手状态机中就肯定有那么一个点，在该点之前数据是明文的，而在该点之后数据是加密的，这个点就是接收到ChangeCipherSpec消息，问题是，这个消息在握手状态机中交换，但是却不在握手协议中定义，它被定义为一个单独的协议，不属于握手协议。这样做的理由，按照漏洞发现者Masashi Kikuchi在RFC挖掘出的理由那就是：
Note: To help avoid pipeline stalls, ChangeCipherSpec is
an independent SSL Protocol content type, and is not
actually an SSL handshake message.
这是一个什么理由？显然没有考虑安全因素。那么问题就来了，既然CCS独立于握手状态机，那么它便可以在握手过程中的任何一点收发，在协议层面并没有强制CCS必须要在master keys在握手协议中已经完备的情况下才能发送，如果那样强制，就是两个协议之间的交叠。事实上，依照规范而言，SSL/TLS的握手中，CCS的位置是被严格规定的，即master keys准备好之后，Finish消息之前，那么安全机制就必须由实现者自己负责。稍有不慎，关于握手协议和CCS之间的关系就会处理不好造成可以利用的漏洞。在一篇文章《Early ChangeCipherSpec Attack 》中，作者披露了OpenSSL1.0.1h是如何解决这个问题的，实际上加了不多的几行代码，其中之一就是ssl3_do_change_cipher_spec函数中的一个判断：
if (s->session == NULL || s->session->master_key_length == 0)
{
/* might happen if dtls1_read_bytes() calls this */
SSLerr(SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC,SSL_R_CCS_RECEIVED_EARLY);
return (0);
}在之前的漏洞影响的版本中，并没有确认master_key_length不为0，这就意味着即便master key还没有准备好，也是可以发送CCS的，而这样的话，所谓的密钥也没有秘密可言了。CCS的发送时间并没有强制要求，但是要求master keys必须准备好！以下是一个基于中间人攻击的漏洞利用场景，中间人在作为server的时候，在ServerHelloDone完成后即发送一个CCS，注意此时还没有生成master keys，因此使用一个空值代替，由于OpenSSL在收到CCS的时候并没有检查自己的握手状态机处于哪一步骤，因此会无条件接收，此时它也没有master key，后面的事情就是使用不是密钥的密钥对数据进行加密，注意，由于OpenSSL的实现原因，只要已经经过了key的计算，在一个session中以后就不会再次计算，因此下面的代码(同样处于ssl3_do_change_cipher_spec中)事实上助长了漏洞：
if (s->s3->tmp.key_block == NULL)
{
if (s->session == NULL)
{
/* might happen if dtls1_read_bytes() calls this */
SSLerr(SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC,SSL_R_CCS_RECEIVED_EARLY);
return (0);
}
s->session->cipher=s->s3->tmp.new_cipher;
if (!s->method->ssl3_enc->setup_key_block(s)) return(0);
}关于SSL/TLS规范中将CCS设计成独立的一个数据协议，我在《TCP/IP协议族》这本经典教材中找到了更真切的理由，那就是它将发送方和接收方分割成了两个状态，按照分权原则，这个事不能在握手协议本身完成。
漏洞发现者Masashi Kikuchi所述，只要保证几点即可，非常简单：
IMHO, this sentence is the very cause of the vulnerability. According to it, the reason that CCS is assigned an independent record type is to avoid a stall. This is the point where the most complex synchronization is required in TLS/SSL handshake. First, you need to wait until the handshake proceeds to the proper phase. Then, you need to check whether the handshake receives CCS before Finish.
More precisely, when accepting CCS, you must verify the following three conditions (*):
the handshake proceeds to the proper phase, i.e., just before to receive Finished,
no fragments from the handshake remains,
and, the next message is Finished.
Being more careful, you should also check
no Alert fragment remains (they can be rejected in the first place),
and, no Heartbeat fragment remains
事实很简单，保证CCS发送的时候，master keys真的已经准备好了，这实际上就是CCS本身的意思，如果我能跟我的三岁的小小讲清楚这个，她肯定会说她的口头禅：难道不是吗？
一个独立的CCS协议，独立于握手协议的CCS协议，在SSL/TLS中必然不可能是完全独立的，协议封装上是独立的，语义却不可能是独立的，否则，我在ClientHello后发送一个CCS，可否？唉，心病还未痊愈，CCS又来捣乱，如果说心脏出血是OpenSSL的问题的话(它实际上是一个低级的代码级错误)，CCS漏洞则是一个协议层面的问题，这个问题可不低级！我相信不止OpenSSL的实现会有这个问题。
我不再吐嘈了，但是我想澄清互联网时代系统两种死法的不同之处，对于安全而已，死法也只有两种，我举一个现实中的例子，一种是生病或中毒而死，一种是外力置死，比如车祸，地震，或者被砍死，这两种本质是不同的，第一种是你自身出了问题，第二种则是外部原因导致。映射到互联网，对于密码被破解，CCS漏洞之类的，这就是第一类的，这类问题一般都是系统本身的设计问题，而对于像栈溢出，Heartbleed，堆溢出之类的，则属于第二类，这类问题一旦碰到，很公平，但是不属于系统设计的问题，只是实现问题。再说一下现实世界，即便吃再安全的食品，也怕菜刀，但是可以请保镖，武夫之流能挡刀，但是最终可能会由于吃了太多的不健康的油而致癌...
做个广告，最好的筛子：OpenSSL
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。