使用WebRTC開發(fā)Android Messenger的方法解析

WebRTC是一種開放源代碼視頻會議解決方案，可用于各種軟件。包括瀏覽器，消息客戶端和流媒體服務。雖然Zero Project過去曾報道過WebRTC中的多個BUG，但尚不清楚這些BUG是否可利用，尤其是在瀏覽器之外的BUG。我調(diào)查了流行的Android消息傳遞應用程序中最近的兩個不知能否利用的bug。 The Bugs 我首先嘗試利用兩個BUG：CVE-2020-6389和CVE-2020-6387。 這兩個BUG都在WebRTC的遠程傳輸協(xié)議（RTP）的處理中。RTP是WebRTC用于從點對點傳輸音頻和視頻內(nèi)容的協(xié)議。RTP支持擴展，擴展是可以包含在每個數(shù)據(jù)包中的額外數(shù)據(jù)段，以便告訴目標對等方如何顯示或處理數(shù)據(jù)。例如，存在一個擴展，其中包含有關發(fā)送設備的屏幕方向的信息，而其中另一個包含音量級別。這兩個BUG都發(fā)生在2019年實現(xiàn)的WebRTC的擴展中。 CVE-2020-6389發(fā)生在幀標記擴展中，該擴展包含有關如何將視頻內(nèi)容拆分為幀的信息的內(nèi)容。BUG在于處理層信息的方式：WebRTC僅支持五層，但是層號在擴展中是一個三位字段，這意味著它可以高達七層。這導致在以下代碼中寫越界。從擴展名中的層號設置temporal_idx。

代碼的最后一行是發(fā)生越界時寫入的地方，因為該數(shù)組僅包含五個元素。這個BUG也有一些局限性，雖然從上面的代碼中看得不太明顯。首先，在寫的操作之前先進行檢查，檢查內(nèi)存的當前值（轉(zhuǎn)換為16位無符號整數(shù)）是否大于當前序列號。僅在為真時才執(zhí)行寫的操作。實際上，這并不是什么限制，當我測試它時，崩潰通常發(fā)生在兩到三遍之后。一個更為嚴重的限制是layer_info_it-> second字段具有64位整數(shù)類型，而frame-> id.picture_id是16位整數(shù)。這意味著盡管此BUG使攻擊者可以在固定大小的堆緩沖區(qū)之外最多寫入三個64位整數(shù)，但是可以寫入的值非常有限，并且太小而無法表示指針。 CVE-2020-6387是前向糾錯（FEC）如何處理視頻定時擴展的錯誤。 FEC復制傳入RTP數(shù)據(jù)包，然后在嘗試更正錯誤時清除某些擴展名。發(fā)生此BUG的原因是：在清除視頻定時類型的擴展名之前，未驗證它們是否具有預期的長度。導致此錯誤的代碼如下：

VideoSendTiming :: kPacerExitDeltaOffset的值為7，因此此代碼從數(shù)據(jù)包擴展名的起始位置開始，將在偏移量7到偏移量13之間寫入六個零。但是，卻不檢查擴展數(shù)據(jù)的長度是否超過13個字節(jié)，甚至不檢查數(shù)據(jù)包是否剩下此字節(jié)數(shù)。該BUG的結果是，攻擊者可以在一個可變大小的堆緩沖區(qū)最多偏移七個字節(jié)的情況下，向堆中寫入最多六個零。該BUG在某些方面優(yōu)于CVE-2020-6389，但在其他方面則更糟。更好的是，可以溢出的堆緩沖區(qū)是可變大小的，這提供了更多關于此BUG可以覆蓋堆的選項。偏移量還為寫入零的位置提供了一定的靈活性，并且寫入時也不必對齊。而CVE-2020-6389需要64位對齊。該錯誤更嚴重，因為寫入的值必須為零，并且可以寫入的區(qū)域的大小較小（六個字節(jié)對24個字節(jié)）。 Moving the Instruction Pointer 我首先查看是否有可能使用這些BUG之一來移動指令指針。現(xiàn)代Android使用jemalloc，這是一個平板分配器，它不使用內(nèi)聯(lián)堆頭，因此破壞堆元數(shù)據(jù)不是一種選擇。相反，我使用符號編譯了適用于Android的WebRTC，并將其加載到IDA中。然后，我瀏覽了可用的對象類型，以查看是否存在明顯可用于移動指令指針或改善錯誤功能的東西。結果，我什么都沒找到。 我以為也許我可以使用CVE-2020-6389覆蓋長度并導致更大的溢出，但這存在一些問題。首先，該BUG會寫入一個64位整數(shù)，而很多長度字段都是32位整數(shù)，這意味著該寫入操作還會覆蓋其他內(nèi)容，并且如果長度是64位對齊的，則只能寫入一個非零值。BUG在處理中的位置也是有問題的，因為它會在即將處理的傳入數(shù)據(jù)包的末尾進行覆蓋，這意味著在此之后許多對象將不再被訪問，因此任何覆蓋的內(nèi)存都將不再使用。 CVE-2020-6389還覆蓋了固定大小為80的堆緩沖區(qū)，這限制了可能受此錯誤影響的對象類型。我也不認為CVE-2020-6387可以達到這個目的，因為它只能寫零，而這只能使長度變短。 我不確定現(xiàn)在要進行什么操作，所以我在Android上觸發(fā)了數(shù)十次CVE-2020-6389，以查看是否存在超過16位寬的地址崩潰，希望它們能為我提供一些方法在除了覆蓋無效的16位值的指針之外，此錯誤可能會影響代碼的行為。令我驚訝的是，它崩潰了，而且指令指針設置為一個值，該值顯然已從堆中讀取了大約20次。 分析崩潰后，結果發(fā)現(xiàn)在溢出區(qū)域之后分配了一個StunMessage對象。 StunMessage類的成員如下。

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

這些指針指向內(nèi)存中向量內(nèi)容的開頭和結尾。在崩潰期間，__end_成員被一個小的16位整數(shù)覆蓋。向量迭代的工作方式是從__begin_指針開始，然后遞增直到達到__end_指針，因此，此更改意味著通常下次在析構函數(shù)中對向量進行迭代時，它將超出范圍。由于此向量包含StunAttribute類型的虛擬對象，因此它將對每個元素執(zhí)行虛擬調(diào)用，以調(diào)用它的析構函數(shù)。對越界內(nèi)存的虛擬調(diào)用正是為什么移動指令指針的原因。 除以下的這個問題外，這似乎是控制指令指針的一種合理方法：在典型配置中，WebRTC連接一端的攻擊者無法將STUN發(fā)送給另一端的用戶，而是他們各自與自己的STUN服務器進行通信。我問webrtchacks的Philipp Hancke是否知道某種方法。他建議使用此方法，該方法涉及將攻擊者控制的TCP服務器指定為兩個對等方（稱為ICE候選方）之間潛在的可路由路徑。然后，攻擊者和目標設備都將通過此服務器進行通信，包括STUN消息。 這使我能夠發(fā)送具有異常大量屬性的STUN消息。這是必要的，因為為了控制指令指針，我將需要能夠控制STUN屬性向量之后在內(nèi)存中顯示的內(nèi)容。 jemalloc分配相似大小的分配，這由連續(xù)內(nèi)存運行中的預定義大小類確定。大小類使用的次數(shù)越少，相同大小類的兩個對象被一個接一個地分配的可能性就越大。 通常，STUN消息具有少量屬性，這些屬性轉(zhuǎn)換為32或64字節(jié)的向量緩沖區(qū)大小，它們都是非常常用的大小類。相反，我發(fā)送了具有128個屬性的STUN消息，這些消息轉(zhuǎn)換為1024字節(jié)的向量緩沖區(qū)大小，而這恰好是WebRTC中不常用的大小類。通過發(fā)送許多具有此數(shù)量屬性的STUN消息，同時發(fā)送大小為1024的RTP數(shù)據(jù)包，其中包含所需的指針值，并散布著包含BUG的數(shù)據(jù)包，我能夠?qū)υ撝羔樦颠M行約1的虛擬調(diào)用五次。這足以在BUG利用中使用，所以我決定繼續(xù)攻克ASLR。 Breaking ASLR 在此攻擊中，有兩種可能的方法可以破解ASLR。一種是使用上述BUG之一讀取內(nèi)存，然后以某種方式將其發(fā)送回攻擊者設備或TCP服務器，另一種是使用某種故障預兆來確定內(nèi)存布局。 我首先查看是否有可能使用這些BUG之一從目標設備遠程中讀取內(nèi)存。馬克·布蘭德（Mark Brand）建議，可以使用CVE-2020-6387來實現(xiàn)這一點，方法是將指向傳出數(shù)據(jù)的指針的低位字節(jié)設置為零，從而導致發(fā)送越界數(shù)據(jù)而不是實際數(shù)據(jù)。這似乎是一種很有希望的方法，因此我使用IDA尋找潛在的對象。 結果發(fā)現(xiàn)有不少，他們都有問題。我花了一些時間在SendPacketMessageData和DataReceivedMessageData上。這些對象用于在隊列中存儲指向傳出RTP數(shù)據(jù)的指針。它們包含一個CopyOnWriteBuffer對象，并且它的第一個成員是指向rtc :: Buffer對象的引用計數(shù)的指針。使用CVE-2020-6387可以將此指針的最低字節(jié)設置為零。不幸的是，rtc :: Buffer的結構使以這種方式顯示內(nèi)存具有挑戰(zhàn)性。

我希望有可能使指向該結構的裁剪指針指向堆上的其他對象，該對象在data_指針的位置具有一個指針，而該數(shù)據(jù)將被發(fā)送。但是，事實證明，在發(fā)送數(shù)據(jù)的過程中，上面對象的所有四個成員都可以訪問，并且需要合理有效。我遍歷了與rtc :: Buffer類相同大小的所有可用對象，但是找不到具有這些確切屬性的對象。 然后，我考慮使用一個已經(jīng)釋放的rtc :: Buffer對象，而不是使用其他對象，而使用特定的后備緩沖區(qū)大小，可以使用堆操作將其替換為包含指針的對象。這也沒有解決。這在很大程度上是可靠性的問題。首先，一個rtc :: Buffer對象是36個字節(jié)，這在jemalloc中轉(zhuǎn)換為48個大小類，這意味著分配了48個字節(jié)。想象一下這種類型的一些連續(xù)分配，地址如下：

如果該BUG將緩沖區(qū)0到5的第一個字節(jié)設置為零，則它們將落在有效緩沖區(qū)上，但是如果緩沖區(qū)6設置為零，則它將不起作用，因為256不會平均分配為48。所以結果是，每次BUG碰到SendPacketMessageData對象時，只有三分之一的機會最終會指向有效的rtc :: Buffer。首先，擊中對象也是不可靠的，因為WebRTC正在進行許多其他類似大小的分配。通過使用TCP服務器使連接非常慢，可以增加堆上這些對象的數(shù)量和發(fā)送它們之前的時間量，但即使這樣，我也只能在不到10%的時間內(nèi)命中結構。必須操縱堆，以便首先在一行中有許多釋放的rtc :: Buffer對象，并且支持已被包含指針的東西替換。但這卻增加了更多的不可靠性。我最終放棄了這種方法，因為我認為我可能既無法做到足夠可靠，也無法通過合理的努力將其用于BUG利用程序中。同樣地，被攻擊的應用程序的崩潰行為也很重要。這可能可以適用于在崩潰的情況下立即重生的應用程序，但是對于停止重生的應用程序?qū)嵱眯詤s要差很多，除非存在一定的延遲，而這在Android上很常見。 我還大量研究了WebRTC如何生成傳出數(shù)據(jù)包，尤其是對等端始終發(fā)送的遠程傳輸控制協(xié)議（RTCP），即使它只是接收音頻或視頻。但是，大多數(shù)傳出數(shù)據(jù)包都是在堆棧上生成的，因此無法使用堆損壞BUG對其進行更改。 我還考慮過使用崩潰Oracle來破解ASLR，但我認為使用這些特定的錯誤不太可能成功。首先，與它們進行堆分配是不可靠的，因此很難判斷是由于特定情況還是僅由于BUG失敗而導致崩潰。考慮到這些BUG的功能有限，我還不確定是否有可能創(chuàng)建可檢測的條件。 我還考慮過使用CVE-2020-6387更改vtable或函數(shù)指針以讀取內(nèi)存，導致崩潰Oracle可以檢測到的行為或執(zhí)行不需要破壞ASLR的基于偏移的利用。我決定不走這條路，因為最終結果將取決于哪些函數(shù)和vtables在以零結尾的位置上加載，而這在各個版本之間差異很大。使用此方法編寫的BUG利用程序需要進行大量修改才能在WebRTC的稍微不同的版本上運行，并且無法保證它完全可以運行。 我決定在這一點上，我需要尋找可能破壞ASLR的新BUG，因為我最近發(fā)現(xiàn)的兩個BUG都無法輕易做到。