- A+
的确，监控产品作为维护国家公共安全的重要工具，遍布国家重要机构和群众生活的各个领域，以其为入口的信息包含了从国家安全机密到普通百姓日常生活隐私的各个方面，一旦泄露，其造成的损失和未来潜在的威胁确实难以估量。
那么，是什么样的安全隐患如此高大上，可以造成这么严重的影响？让我们梳理一下这一系列的漏洞，逐一分析原理，揭开其神秘面纱，为行业提供借鉴。
从技术角度来看，本次事件暴露的问题，肯定不仅仅是像厂商所宣称的由弱口令导致，弱口令属于不安全配置(像123456,888888等有中国特色的默认口令，让人想不猜出都难)，除弱口令外，产品自身还存在若干严重漏洞，而整个系列的漏洞，都源于对RTSP请求消息的处理存在缺陷：
PLAYrtsp://X.X.X.X/litv08RTSP/1.0\r\n
CSeq:7\r\nAuthorization:BasicAAAAAAA\r\n
Content-length:10000\r\n\r\n
上图中黑色加粗部分为攻击负载，该验证代码会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。
H的RTSP请求处理程序(handler)使用了一个固定大小的缓冲区(观察到为2048字节)来接收RTSP请求的消息体(body)，但缺乏针对该缓冲区的写保护。由于消息体长度是可变的且是用户可以控制的，当攻击者构造超长的消息体时，会导致缓冲区写越界，从而造成不可预知的结果。
PLAYrtsp://X.X.X.X/litv08RTSP/1.0\r\n
CSeq:7\r\n
上图中黑色加粗部分为攻击负载，同样，该负载会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。
H厂商的RTSP请求处理程序同样使用了一个固定大小的缓冲区来处理RTSP请求中的头部字段，但缺乏针对该缓冲区的写保护。当攻击者构造了超长的头部字段时，会导致缓冲区写越界，造成不可预知的结果。
既然处理字段名有问题，那么问题来了，在处理字段值时，会不会也有同样的问题？Goodquestion，这个当然可以有。与上述漏洞相似，
CSeq: 7\r\n
Authorization: Basic AAAA...AAA(more than 1024 'A's)\r\n
上图中黑色加粗部分为攻击负载，同样，该负载会造成拒绝服务攻击。精心构造的攻击负载，会允许攻击者执行任意代码。
H厂商的RTSP请求处理程序同样使用了一个固定大小的缓冲区来处理RTSP请求中的头部字段值，但缺乏针对缓冲区的保护。当攻击者构造了超长的头部字段值时，会导致缓冲区写越界，造成不可预知的结果。
PLAYrtsp://X.X.X.X/litv08RTSP/1.0\r\n
CSeq:7Range:npt=
User-Agent:VLCmediaplayer(LIVE555StreamingMediav2010.02.10)\r\n
头部字段Range中的npt(NormalPlayTime)用来标记相对于起始位置的流的绝对位置，其取值类似于“npt=5.000-5.000”，后面跟的是一个时间范围，可以很容易的猜测，程序中用到了一个较小的缓冲区来存储该时间段，但一旦攻击者构造较长的负载，即可对该缓冲区发起溢出攻击。
另外，那位看官请等等，看看这个漏洞有什么不同？God，这个漏洞是2013年就已经发现的漏洞了，可以称得上是上面几个漏洞的老大哥，可惜，老大哥光荣牺牲了，小弟们还要前仆后继。
另外，从漏洞提交的时间来看，这些漏洞显然不是同一时间发现的，但是可以明显的看到，厂商只是机械地、被动地修复了单个漏洞，而没有对漏洞的成因进行深入的思考，没有对漏洞反映出的问题进行分析，并转化为质量改进活动，导致同类的问题层出不穷。
- 我的微信
- 这是我的微信扫一扫
-
- 我的微信公众号
- 我的微信公众号扫一扫
-
