新闻链接：http://www.freebuf.com/vuls/59681.html
新闻时间：2015-03-06
新闻正文：
背景

江苏省公安厅2月27日紧急通知，由于国内某知名供应商监控设备存在巨大安全隐患，要求对该供应商的监控设备进行全面清查。消息一出，舆论哗然，有媒体将该事件称为“棱镜门”后最严重的信息安全事故，认为该事件的影响深远或超乎想象。

的确，监控产品作为维护国家公共安全的重要工具，遍布国家重要机构和群众生活的各个领域，以其为入口的信息包含了从国家安全机密到普通百姓日常生活隐私的各个方面，一旦泄露，其造成的损失和未来潜在的威胁确实难以估量。

那么，是什么样的安全隐患如此高大上，可以造成这么严重的影响？让我们梳理一下这一系列的漏洞，逐一分析原理，揭开其神秘面纱，为行业提供借鉴。

分析

从技术角度来看，本次事件暴露的问题，肯定不仅仅是像厂商所宣称的由弱口令导致，弱口令属于不安全配置(像123456,888888等有中国特色的默认口令，让人想不猜出都难)，除弱口令外，产品自身还存在若干严重漏洞，而整个系列的漏洞，都源于对RTSP请求消息的处理存在缺陷：

2.1 CVE-2014-4878

CVE-2014-4878是由于处理RTSP请求消息体不当造成的。我们构造如下验证代码：

PLAY rtsp://X.X.X.X/litv08 RTSP/1.0\r\n
CSeq: 7\r\n Authorization: Basic AAAAAAA\r\n
Content-length: 10000\r\n\r\n
AAAAAA….AAAA(10,000 continuous 'A's )

上图中黑色加粗部分为攻击负载，该验证代码会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。

H的RTSP请求处理程序(handler)使用了一个固定大小的缓冲区(观察到为2048字节)来接收RTSP请求的消息体(body)，但缺乏针对该缓冲区的写保护。由于消息体长度是可变的且是用户可以控制的，当攻击者构造超长的消息体时，会导致缓冲区写越界，从而造成不可预知的结果。

2.2 CVE-2014-4879

与上个漏洞相似，CVE-2014-4879是由于处理RTSP请求的头部字段不当造成的，我们构造如下验证代码：

PLAY rtsp://X.X.X.X/litv08 RTSP/1.0\r\n
CSeq: 7\r\n
AuthorizationAAAA…AAA(more than 1024 'A's): Basic AAAAAAA\r\n

上图中黑色加粗部分为攻击负载，同样，该负载会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。

H厂商的RTSP请求处理程序同样使用了一个固定大小的缓冲区来处理RTSP请求中的头部字段，但缺乏针对该缓冲区的写保护。当攻击者构造了超长的头部字段时，会导致缓冲区写越界，造成不可预知的结果。

2.3 CVE-2014-4880

既然处理字段名有问题，那么问题来了，在处理字段值时，会不会也有同样的问题？Good question，这个当然可以有。与上述漏洞相似，CVE-2014-4880是由于处理RTSP请求的头部字段值不当造成的，我们构造如下验证代码：

PLAY rtsp://X.X.X.X/litv08 RTSP/1.0\r\n
CSeq: 7\r\n
Authorization: Basic AAAA...AAA(more than 1024 'A's)\r\n
上图中黑色加粗部分为攻击负载，同样，该负载会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。

H厂商的RTSP请求处理程序同样使用了一个固定大小的缓冲区来处理RTSP请求中的头部字段值，但缺乏针对缓冲区的保护。当攻击者构造了超长的头部字段值时，会导致缓冲区写越界，造成不可预知的结果。

2.4 CVE-2013-4977

这个漏洞可以说是CVE-2014-4880的孪生兄弟，只是穿上了不同的马甲。我们来看看这个漏洞是如何形成的，构造如下验证代码：

PLAY rtsp://X.X.X.X/litv08 RTSP/1.0\r\n
CSeq: 7 Range: npt=Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9aLSaLSaLS\r\n
User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10)\r\n

头部字段Range中的npt(Normal Play Time)用来标记相对于起始位置的流的绝对位置，其取值类似于“npt=5.000-5.000”，后面跟的是一个时间范围，可以很容易的猜测，程序中用到了一个较小的缓冲区来存储该时间段，但一旦攻击者构造较长的负载，即可对该缓冲区发起溢出攻击。

另外，那位看官请等等，看看这个漏洞有什么不同？God，这个漏洞是2013年就已经发现的漏洞了，可以称得上是上面几个漏洞的老大哥，可惜，老大哥光荣牺牲了，小弟们还要前仆后继。

总结

可以看到，漏洞尽管体现为系列漏洞，但本质都可以归结为一个再简单不过的原因：对缓冲区的写保护不够。有过开发经验的同仁都知道，这是最初级和低级的编程问题，在大家愈发重视代码质量的今天，这样的问题已经很少见了。

另外，从漏洞提交的时间来看，这些漏洞显然不是同一时间发现的，但是可以明显的看到，厂商只是机械地、被动地修复了单个漏洞，而没有对漏洞的成因进行深入的思考，没有对漏洞反映出的问题进行分析，并转化为质量改进活动，导致同类的问题层出不穷。

一个不经意的错误，会导致及其严重的后果。但是，与暴露的具体问题相比，厂商安全意识的薄弱，对产品质量态度的漠然，是真正让人担心的，希望此次事件能给国内的一些企业敲响警钟，重视安全，重视质量，重视信誉，重视客户！ （转自FreeBuf黑客与极客）

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)