使用WebRTC开发Android Messenger：第2部分

这是一个由三部分组成的系列文章，内容涉及：利用WebRTC中的BUG和利用Messenger应用程序。本系列文章重点阐述了当应用程序不能应用于WebRTC补丁程序以及通信和安全问题通知中断时可能出问题的方面。

文 / Natalie Silvanovich

原文链接：

https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-2.html

 

Part 2: A Better Bug

在使用WebRTC开发Android Messenger：第1部分中，我探讨了是否有可能在RTP处理中使用两个内存损坏bug来利用WebRTC。当我成功移动指令指针时，我无法破解ASLR，因此我决定寻找更适合此目的的漏洞。

 

usrsctp

我首先浏览了过去提交的WebRTC bugs，以查看是否有可能破坏ASLR。 即使很早就修复了bug，它也表明可能在何处发现了类似的漏洞。这样的bug是CVE-2020-6831，该漏洞在usrsctp中的越界读取。

usrsctp是WebRTC使用的流控制传输协议（SCTP）的实现。使用WebRTC的应用程序可以打开数据通道，该通道允许将文本或二进制数据从对等方传输。数据通道通常用于允许在视频通话期间交换文本消息，或在发生某些事件时告诉对等方，例如另一个对等方禁用其摄像头。  SCTP是数据通道的基础协议。在WebRTC中，SCTP类似于RTP，其中RTP用于音频和视频内容，SCTP用于数据。

我花了一些时间检查usrsctp代码中的漏洞。 我最终找到了CVE-2020-6831，这是从usrsctp中的堆栈缓冲区溢出。该bug使攻击者可以完全控制溢出的大小和内容。 Samuel Groß建议，这个bug可以用来破坏ASLR，方法是覆盖堆栈cookie，然后一次覆盖一个字节的返回地址，并根据应用程序是否崩溃来检测值是否正确。不幸的是，事实证明，此bug无法通过WebRTC访问，因为它需要客户端套接字连接到侦听套接字，而在WebRTC中，两个套接字都是客户端套接字。

我一直在寻找，最终找到了CVE-2020-6514。 这是WebRTC如何与usrsctp交互的一个非常不寻常的bug。  usrsctp支持自定义传输，在这种情况下，集成商需要为每个连接提供一对无效指针，以提供源地址和目标地址。 这些指针的未取消引用的值随后被usrsctp用作地址，这意味着该值包含在某些数据包中。 在WebRTC中，地址指针设置为WebRTC使用的SctpTransport实例的地址。 结果是在每个SCTP连接期间，此对象在内存中的位置将发送到远程对等方。从技术上讲，这是WebRTC中的bug，尽管usrsctp的设计也有缺陷，因为对自定义地址使用void*类型会强烈鼓励集成器使用该值的指针，尽管这是不安全的。

我希望此bug足以破解ASLR，但事实并非如此。对于漏洞利用，我需要一个已加载库的位置以及堆的位置，因此我在Android设备上进行了一系列测试，以查看这些位置之间是否存在任何关联，结果是没有任何关联。堆指针的位置不足以确定加载的库的位置。

 

我一直在寻找，我注意到usrsctp处理ASCONF块的方式中存在一个漏洞，这些块用于管理动态IP地址。该错误的来源如下：

if (param_length > sizeof(aparam_buf)) { SCTPDBG(SCTP_DEBUG_ASCONF1, "handle_asconf: param length (%u) larger than buffer size!\n", param_length); sctp_m_freem(m_ack); return; } if (param_length <= sizeof(struct sctp_paramhdr)) { SCTPDBG(SCTP_DEBUG_ASCONF1, "handle_asconf: param length (%u) too short\n", param_length); sctp