這是一個由三部分組成的系列文章，內容涉及：利用WebRTC中的BUG和利用Messenger應用程序。本系列文章重點闡述了當應用程序不能應用于WebRTC補丁程序以及通信和安全問題通知中斷時可能出問題的方面。

文 /?Natalie Silvanovich

原文鏈接：

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

Part 1: First Attempts

WebRTC是一種開放源代碼視頻會議解決方案，可用于各種軟件。包括瀏覽器，消息客戶端和流媒體服務。雖然Zero Project過去曾報道過WebRTC中的多個BUG，但尚不清楚這些BUG是否可利用，尤其是在瀏覽器之外的BUG。我調查了流行的Android消息傳遞應用程序中最近的兩個不知能否利用的bug。

The Bugs

我首先嘗試利用兩個BUG：CVE-2020-6389和CVE-2020-6387。

這兩個BUG都在WebRTC的遠程傳輸協議（RTP）的處理中。RTP是WebRTC用于從點對點傳輸音頻和視頻內容的協議。RTP支持擴展，擴展是可以包含在每個數據包中的額外數據段，以便告訴目標對等方如何顯示或處理數據。例如，存在一個擴展，其中包含有關發送設備的屏幕方向的信息，而其中另一個包含音量級別。這兩個BUG都發生在2019年實現的WebRTC的擴展中。

CVE-2020-6389發生在幀標記擴展中，該擴展包含有關如何將視頻內容拆分為幀的信息的內容。BUG在于處理層信息的方式：WebRTC僅支持五層，但是層號在擴展中是一個三位字段，這意味著它可以高達七層。這導致在以下代碼中寫越界。從擴展名中的層號設置temporal_idx。

?

if (layer_info_it->second[temporal_idx] != -1 && AheadOf<uint16_t>(layer_info_it->second[temporal_idx], frame->id.picture_id)) { ????? // Not a newer frame. No subsequent layer info needs update. ???? ?break; ???} ??... ???layer_info_it->second[temporal_idx] = frame->id.picture_id;

代碼的最后一行是發生越界時寫入的地方，因為該數組僅包含五個元素。這個BUG也有一些局限性，雖然從上面的代碼中看得不太明顯。首先，在寫的操作之前先進行檢查，檢查內存的當前值（轉換為16位無符號整數）是否大于當前序列號。僅在為真時才執行寫的操作。實際上，這并不是什么限制，當我測試它時，崩潰通常發生在兩到三遍之后。一個更為嚴重的限制是layer_info_it-> second字段具有64位整數類型，而frame-> id.picture_id是16位整數。這意味著盡管此BUG使攻擊者可以在固定大小的堆緩沖區之外最多寫入三個64位整數，但是可以寫入的值非常有限，并且太小而無法表示指針。

CVE-2020-6387是前向糾錯（FEC）如何處理視頻定時擴展的錯誤。? FEC復制傳入RTP數據包，然后在嘗試更正錯誤時清除某些擴展名。發生此BUG的原因是：在清除視頻定時類型的擴展名之前，未驗證它們是否具有預期的長度。導致此錯誤的代碼如下：

case RTPExtensionType::kRtpExtensionVideoTiming: { ???????// Nullify 3 last entries: packetization delay and 2 network timestamps. ???????// Each of them is 2 bytes. ???????uint8_t* p = WriteAt(extension.offset) + VideoSendTiming::kPacerExitDeltaOffset; ???????memset( ???????????p, ???????????0, 6); ???????break; ?????}

VideoSendTiming :: kPacerExitDeltaOffset的值為7，因此此代碼從數據包擴展名的起始位置開始，將在偏移量7到偏移量13之間寫入六個零。但是，卻不檢查擴展數據的長度是否超過13個字節，甚至不檢查數據包是否剩下此字節數。該BUG的結果是，攻擊者可以在一個可變大小的堆緩沖區最多偏移七個字節的情況下，向堆中寫入最多六個零。該BUG在某些方面優于CVE-2020-6389，但在其他方面則更糟。更好的是，可以溢出的堆緩沖區是可變大小的，這提供了更多關于此BUG可以覆蓋堆的選項。偏移量還為寫入零的位置提供了一定的靈活性，并且寫入時也不必對齊。而CVE-2020-6389需要64位對齊。該錯誤更嚴重，因為寫入的值必須為零，并且可以寫入的區域的大小較小（六個字節對24個字節）。

Moving the Instruction Pointer

我首先查看是否有可能使用這些BUG之一來移動指令指針。現代Android使用jemalloc，這是一個平板分配器，它不使用內聯堆頭，因此破壞堆元數據不是一種選擇。相反，我使用符號編譯了適用于Android的WebRTC，并將其加載到IDA中。然后，我瀏覽了可用的對象類型，以查看是否存在明顯可用于移動指令指針或改善錯誤功能的東西。結果，我什么都沒找到。

我以為也許我可以使用CVE-2020-6389覆蓋長度并導致更大的溢出，但這存在一些問題。首先，該BUG會寫入一個64位整數，而很多長度字段都是32位整數，這意味著該寫入操作還會覆蓋其他內容，并且如果長度是64位對齊的，則只能寫入一個非零值。BUG在處理中的位置也是有問題的，因為它會在即將處理的傳入數據包的末尾進行覆蓋，這意味著在此之后許多對象將不再被訪問，因此任何覆蓋的內存都將不再使用。? CVE-2020-6389還覆蓋了固定大小為80的堆緩沖區，這限制了可能受此錯誤影響的對象類型。我也不認為CVE-2020-6387可以達到這個目的，因為它只能寫零，而這只能使長度變短。

?

我不確定現在要進行什么操作，所以我在Android上觸發了數十次CVE-2020-6389，以查看是否存在超過16位寬的地址崩潰，希望它們能為我提供一些方法在除了覆蓋無效的16位值的指針之外，此錯誤可能會影響代碼的行為。令我驚訝的是，它崩潰了，而且指令指針設置為一個值，該值顯然已從堆中讀取了大約20次。

?

分析崩潰后，結果發現在溢出區域之后分配了一個StunMessage對象。? StunMessage類的成員如下。

protected: ??std::vector<std::unique_ptr<StunAttribute>> attrs_; ?... ?private: ??... ??uint16_t type_; ??uint16_t length_; ??std::string transaction_id_; ??uint32_t reduced_transaction_id_; ??uint32_t stun_magic_cookie_;

因此，在vtable之后，第一個成員是向量。向量如何在內存中布置？原來它的前兩個成員如下。

? pointer __begin_; ??pointer __end_;

這些指針指向內存中向量內容的開頭和結尾。在崩潰期間，__end_成員被一個小的16位整數覆蓋。向量迭代的工作方式是從__begin_指針開始，然后遞增直到達到__end_指針，因此，此更改意味著通常下次在析構函數中對向量進行迭代時，它將超出范圍。由于此向量包含StunAttribute類型的虛擬對象，因此它將對每個元素執行虛擬調用，以調用它的析構函數。對越界內存的虛擬調用正是為什么移動指令指針的原因。

除以下的這個問題外，這似乎是控制指令指針的一種合理方法：在典型配置中，WebRTC連接一端的攻擊者無法將STUN發送給另一端的用戶，而是他們各自與自己的STUN服務器進行通信。我問webrtchacks的Philipp Hancke是否知道某種方法。他建議使用此方法，該方法涉及將攻擊者控制的TCP服務器指定為兩個對等方（稱為ICE候選方）之間潛在的可路由路徑。然后，攻擊者和目標設備都將通過此服務器進行通信，包括STUN消息。

這使我能夠發送具有異常大量屬性的STUN消息。這是必要的，因為為了控制指令指針，我將需要能夠控制STUN屬性向量之后在內存中顯示的內容。? jemalloc分配相似大小的分配，這由連續內存運行中的預定義大小類確定。大小類使用的次數越少，相同大小類的兩個對象被一個接一個地分配的可能性就越大。

通常，STUN消息具有少量屬性，這些屬性轉換為32或64字節的向量緩沖區大小，它們都是非常常用的大小類。相反，我發送了具有128個屬性的STUN消息，這些消息轉換為1024字節的向量緩沖區大小，而這恰好是WebRTC中不常用的大小類。通過發送許多具有此數量屬性的STUN消息，同時發送大小為1024的RTP數據包，其中包含所需的指針值，并散布著包含BUG的數據包，我能夠對該指針值進行約1的虛擬調用五次。這足以在BUG利用中使用，所以我決定繼續攻克ASLR。

?

Breaking ASLR

在此攻擊中，有兩種可能的方法可以破解ASLR。?一種是使用上述BUG之一讀取內存，然后以某種方式將其發送回攻擊者設備或TCP服務器，另一種是使用某種故障預兆來確定內存布局。

?

我首先查看是否有可能使用這些BUG之一從目標設備遠程中讀取內存。馬克·布蘭德（Mark Brand）建議，可以使用CVE-2020-6387來實現這一點，方法是將指向傳出數據的指針的低位字節設置為零，從而導致發送越界數據而不是實際數據。這似乎是一種很有希望的方法，因此我使用IDA尋找潛在的對象。

?

結果發現有不少，他們都有問題。我花了一些時間在SendPacketMessageData和DataReceivedMessageData上。這些對象用于在隊列中存儲指向傳出RTP數據的指針。它們包含一個CopyOnWriteBuffer對象，并且它的第一個成員是指向rtc :: Buffer對象的引用計數的指針。使用CVE-2020-6387可以將此指針的最低字節設置為零。不幸的是，rtc :: Buffer的結構使以這種方式顯示內存具有挑戰性。

RefCountedObject vtable; size_t size_; size_t capacity_; std::unique_ptr<T[]> data_;

我希望有可能使指向該結構的裁剪指針指向堆上的其他對象，該對象在data_指針的位置具有一個指針，而該數據將被發送。但是，事實證明，在發送數據的過程中，上面對象的所有四個成員都可以訪問，并且需要合理有效。我遍歷了與rtc :: Buffer類相同大小的所有可用對象，但是找不到具有這些確切屬性的對象。

然后，我考慮使用一個已經釋放的rtc :: Buffer對象，而不是使用其他對象，而使用特定的后備緩沖區大小，可以使用堆操作將其替換為包含指針的對象。這也沒有解決。這在很大程度上是可靠性的問題。首先，一個rtc :: Buffer對象是36個字節，這在jemalloc中轉換為48個大小類，這意味著分配了48個字節。想象一下這種類型的一些連續分配，地址如下：

0x[...]0000? ? ? buffer 0 0x[...]0030? ? ? buffer 1 0x[...]0060? ? ? buffer 2 0x[...]0090? ? ? buffer 3 0x[...]00c0? ? ? buffer 4 0x[...]00f0 ? ? ? buffer 5 0x[...]0120? ? ? buffer 6 ...

如果該BUG將緩沖區0到5的第一個字節設置為零，則它們將落在有效緩沖區上，但是如果緩沖區6設置為零，則它將不起作用，因為256不會平均分配為48。所以結果是，每次BUG碰到SendPacketMessageData對象時，只有三分之一的機會最終會指向有效的rtc :: Buffer。首先，擊中對象也是不可靠的，因為WebRTC正在進行許多其他類似大小的分配。通過使用TCP服務器使連接非常慢，可以增加堆上這些對象的數量和發送它們之前的時間量，但即使這樣，我也只能在不到10%的時間內命中結構。必須操縱堆，以便首先在一行中有許多釋放的rtc :: Buffer對象，并且支持已被包含指針的東西替換。但這卻增加了更多的不可靠性。我最終放棄了這種方法，因為我認為我可能既無法做到足夠可靠，也無法通過合理的努力將其用于BUG利用程序中。同樣地，被攻擊的應用程序的崩潰行為也很重要。這可能可以適用于在崩潰的情況下立即重生的應用程序，但是對于停止重生的應用程序實用性卻要差很多，除非存在一定的延遲，而這在Android上很常見。

我還大量研究了WebRTC如何生成傳出數據包，尤其是對等端始終發送的遠程傳輸控制協議（RTCP），即使它只是接收音頻或視頻。但是，大多數傳出數據包都是在堆棧上生成的，因此無法使用堆損壞BUG對其進行更改。

我還考慮過使用崩潰Oracle來破解ASLR，但我認為使用這些特定的錯誤不太可能成功。首先，與它們進行堆分配是不可靠的，因此很難判斷是由于特定情況還是僅由于BUG失敗而導致崩潰。考慮到這些BUG的功能有限，我還不確定是否有可能創建可檢測的條件。

我還考慮過使用CVE-2020-6387更改vtable或函數指針以讀取內存，導致崩潰Oracle可以檢測到的行為或執行不需要破壞ASLR的基于偏移的利用。我決定不走這條路，因為最終結果將取決于哪些函數和vtables在以零結尾的位置上加載，而這在各個版本之間差異很大。使用此方法編寫的BUG利用程序需要進行大量修改才能在WebRTC的稍微不同的版本上運行，并且無法保證它完全可以運行。

我決定在這一點上，我需要尋找可能破壞ASLR的新BUG，因為我最近發現的兩個BUG都無法輕易做到。

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的使用WebRTC开发Android Messenger：第1部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。