WebRTC模糊测试

111

在开始之前

一切都开始于Google Project Zero,结果可以在Github 目录中,里面包含测试RTP流的工具(和一些记录的bug)。

一些值得注意的:

  1. 这些bug很重要,尝试修复它们。
  2. 这不是世界末日。一些bug已经被发现。很多bug存在已久,每天都在发生,有一些bug很麻烦
  3. 这些不是WebRTC的最后一个,也不是最严重的bug。你可以借鉴NewVoiceMedia,查看它们最近的音频问题。

什么是模糊测试:

维基百科对此的解释:

模糊测试是一个自动化的软件测试技术,包括提供无效,不被期待的,或随机数据作为计算机程序的输入。接着监测程序,找到例外,例如崩溃,失败的内置代码断言,或潜在的内存泄露。

对我来说,模糊测试是为了得到异常输入的结果,这些结果是开发者不期待的,或没有测试过的。这将会导致未定义的行为,说得好听一点就是bug。在某些情况,bug无所谓,某些情况,使人讨厌,带来麻烦:

  1. 它可能导致软件崩溃
  2. 读写它不应该去的地方(溢出)
  3. 死锁
  4. 内存泄露

Bug的类型是各种各样的。

一个好的异常输入理论上可以被用来授予你管理员权限,或允许你读取你不应该接触到的内存区域。

一个简单的解释是:假设你的软件期待用户邮件长度为40个字符长。比它短没问题,但是如果长度超过40字符呢?某些地方,会存在一段代码,检查长度并且表明长度过长。如果没有的话,我们就接触到了未被定义和潜在的安全漏洞。

同样的事情可以发生在网络协议中。机器需要解析数据的结构。所以如果你改变数据,接近期待的结构,但是偏离了一点,你将会接触到未定义的漏洞。

模糊测试就是用来发现这些问题的,在正确的地方添加随机性,来发现未定义的软件行为。

让我给你讲个睡前故事

222

我模糊的生活起始于芬兰,尽管我从未到过那里。

在奥卢大学,某一天,一个叫做PROTOS Test Suite的词被创建出来。在那时,我是领导开发维护RADVISION的H.323协议栈的项目经理。许多供应商都使用我们的源代码建立VoIP产品。

PROTOS Test-Suite就是安全测试。试图发现导致崩溃的崩溃。它们选择最好的接入点。它们被这样形容:

测试单元的目的是评估H.225.0的实施级安全性和稳定性。它是一个负责发信和建立H.323通信的协议。

我加粗了重要部分。奥卢的人决定跟随H.323的拾取线,并尝试找出令人讨厌的将会混淆H.323设备的设置信息。

它们确实混淆了。PROTOS有4497设置信息。我第一次运行的时候,50%导致H.323栈崩溃。我花了一周时间编写软件来自动修复它产生的所有麻烦事。我钦佩它们的工作,和让我做的工作。

这产生了它自己的CERT漏洞记录,我们花了很长时间帮助顾客更新栈,并使它可以正常进行安全修复。

我相信我们的一些顾客实际上就是因为这点才更新升级系统的。我也确定有些人不是因为这点。我还假设一些客户的客户没有升级他们自己的部署设备。

所有这些发生在2004年。在WebRTC之前,在云出现之前,在移动端出现之前。使用了我们今天在WebRTC中也用到的RTP/RTCP协议,还有VoIP中相同的技术和机制。

人们那时为什么不关注RTP的易受攻击点呢?我们会讨论的。

Google的Project Zero和视频会议

今年,Google的Project Zero决定转向视频会议。方向是WebRTC. Natalie Silvanovich负责此事并连续写了5篇文章:首先是关于她的选择和WebRTC本身带来的挑战。在文章中,她写到:

我从WebRTC的发信阶段出发,因为它是一个不需要用户交互的攻击层,WebRTC使用SDP发信。
我查阅了WebRTC SDP解析器代码,但是没有找到任何漏洞。我还对其进行编译,使得它能在命令行接收SDP文件,并进行模糊化,但是我仍然没找到任何漏洞。
我决定查看WebRTC如何对RTP进行处理。尽管RTP不是一个少交互的攻击层,因为用户经常在RTP流量处理之前接收通话,但是接收通话显然对用户来说是一个合理的动作。建立端对端模糊化显然更费时间。

在此需要提醒几点:

  1. WebRTC对发信层(SDP解析器)能够有效的抵抗这些攻击。
  2. 发信和SDP,对于奥卢的人员使用他们的测试单元来说是等价的。
  3. 有一个词汇叫应答。这不是WebRTC做的。它连接了各个session。有时直接连接,有时间接连接。在所有情形下,在RTP上面都存在用户需要首先通过的层。
  4. 创建这样一个测试,在RTP层进行端对端模糊化测试是费时间的。

RTP不是第一个攻击层,也不是第一交互层的事实使如何探索它不太明显。

这两点结合起来,费时,探索方式不清晰,使人们直到今天也不愿意花时间在上面。

WebRTC行业的模糊感受

一个例子是Philipp Hancke着眼于Janus媒体服务器并模糊化REMB RTCP信息。

他的攻击因为以下几点而非常成功:

  1. 他具有Janus的源代码,能够对想要攻击的区域进行隔离。这样攻击起来就比Project Zero的做法更容易。
  2. 他选择了一个目标,它会多次崩溃,它是一条信息,埋藏在协议内部,目标是会话连接之后会多次发生的控制逻辑。

你应该让模糊测试远离你的WebRTC App么?

或许不应该。

让我们看:在你想要做但今天不做的测试列表中,模糊测试恰好适合那些你从未找到时间和优先级去处理的事情。

好事?对我们中的大多数,模糊测试是其它人应该正在做着的事情。

如果你在使用CPaaS供应商,他的任务是保护发信和媒体服务器免受这样的攻击。

如果你在浏览器上运行,那些维护浏览器的WebRTC代码的人需要对此负责。

你应该考虑你自己App逻辑下的模糊测试,还有在你控制下的,但是WebRTC呢?还有RTP呢?那些不是你应该做的。

你的任务是询问供应商,它们是否进行了安全测试,它们已经做了什么。

谁应该关心模糊测试?

以下是应该处理模糊测试的人们:

  • 如果你开发,部署自己的媒体服务器和客户端框架,你应该关心。
  • 如果你正在使用第三方,你需要确保你经常更新。
  • CPaaS供应商。
  • 浏览器供应商。

WebRTC 中文社区由

运营