當應用程序不能應用于WebRTC補丁程序以及通信和安全問題通知中斷時可能出問題

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

文 /Natalie Silvanovich

原文鏈接： https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-2.html

Part 3: Which Messengers? 在使用WebRTC開發(fā)Android Messenger：第2部分中，我描述了Android上對WebRTC的一個應用。在本節(jié)中，我將探索它用于哪些應用程序。 The exploit 在編寫這個BUG時，我最初通過修改WebRTC的源代碼并重新編譯它來修改發(fā)送到目標設備的SCTP數(shù)據(jù)包。這對于攻擊封閉源代碼的應用程序是不實際的，因此我最終改用使用Frida來掛接攻擊設備的二進制文件。 Frida的掛鉤功能允許在調(diào)用特定的本機函數(shù)之前和之后執(zhí)行代碼，這允許我的BUG改變傳出的SCTP包以及檢查傳入的包。從功能上講，這相當于改變攻擊客戶機的源代碼，但是這些改變不是在編譯時在源代碼中進行的，而是由Frida在運行時動態(tài)地進行的。 該BUG的源代碼可以在這里找到： https://bugs.chromium.org/p/project-zero/issues/detail?id=2034#c6 攻擊設備需要掛載7個函數(shù)，如下所示。

這些函數(shù)可以作為符號連接，或者作為二進制中的偏移量。 目標設備的二進制文件還有三個地址偏移量，這是利用BUG進行攻擊所必需的。系統(tǒng)函數(shù)和malloc函數(shù)之間的偏移量，以及上一篇文章中描述的gadget和malloc函數(shù)之間的偏移量就是其中兩個。這些偏移量在libc中，libc是一個Android系統(tǒng)庫，因此需要根據(jù)目標設備的Android版本來確定。還需要從cricket:：SctpTransport vtable的位置到全局偏移表中malloc位置的偏移量。這必須由被攻擊應用程序中包含WebRTC的二進制文件確定。 請注意，所提供的利用BUG腳本有一個嚴重的限制：每次讀取內(nèi)存時，只有在設置了指針的第31位時才有效。第2部分解釋了其原因。利用BUG腳本提供了一個示例，說明如何修復此問題并使用FWD TSN塊讀取任何指針，但這并不是針對每次讀取都實現(xiàn)的。出于測試目的，我重置設備，直到WebRTC庫映射到一個有利的位置。 Android Applications 通過在googleplay的APK文件中搜索usrsctp中的特定字符串，確定了集成WebRTC的流行Android應用程序列表。大約200個用戶超過500萬的應用程序似乎在使用WebRTC。我評估了這些應用程序，以確定它們是否可能受到BUG攻擊中的BUG的影響，以及影響會是什么。 事實證明，應用程序使用WebRTC的方式多種多樣，但可以分為四大類。 l 投影：在用戶同意的情況下，將移動應用程序的屏幕和控件投影到桌面瀏覽器中，以增強可用性 l 流：音頻和視頻內(nèi)容從一個用戶發(fā)送到多個用戶。通常有一個中間服務器，因此發(fā)件人不需要管理可能的數(shù)千個對等方，并且會記錄內(nèi)容以便以后查看 l 瀏覽器：所有主要的瀏覽器都包含WebRTC以實現(xiàn)JavaScript WebRTC API l 會議：兩個或更多用戶通過音頻或視頻進行實時通信 對于每種類別，利用BUG的影響是不同的。投影是低風險的，因為建立WebRTC連接需要大量用戶交互，并且用戶首先可以訪問連接的兩面，因此通過損害另一面幾乎無濟于事。 流媒體的風險也相當?shù)?。盡管某些應用程序在流的觀看者數(shù)量較少時有可能使用對等連接，但它們通常使用中間服務器，該服務器終止發(fā)送對等方的WebRTC連接，并開始與接收對等方的新連接。這意味著攻擊者通常無法將格式錯誤的數(shù)據(jù)包直接發(fā)送到對等方。即使采用點對點流傳輸?shù)脑O置，目標用戶也需要用戶交互才能查看流，并且通常無法限制誰可以訪問流。因此，RTC應用程序可能沒有針對性地使用Web流攻擊。當然，這些BUG可能會影響流服務使用的服務器，但是本研究未對此進行調(diào)查。 瀏覽器幾乎可以肯定會受到WebRTC中大多數(shù)錯誤的攻擊，因為它們允許對配置方式進行大量控制。要利用瀏覽器中的此類錯誤，攻擊者需要設置一個主機，該主機的行為與對等連接中的其他對等主機相同，并誘使目標用戶訪問啟動對該主機的調(diào)用的網(wǎng)頁。在這種情況下，該BUG將與JavaScript中的其他內(nèi)存損壞BUG具有類似的影響。 會議是WebRTC的最高風險使用方法，但BUG的實際影響取決于應用程序用戶之間的聯(lián)系方式。最高風險的設計是一個應用程序，在這個程序中任何用戶都可以根據(jù)標識符與任何其他用戶聯(lián)系。有些應用程序要求被調(diào)用者在進行呼叫之前必須以特定的方式與調(diào)用者進行交互，這使得用戶很難聯(lián)系到目標，并且通常會降低風險。有些應用程序要求用戶輸入代碼或訪問鏈接來啟動調(diào)用和發(fā)起呼叫，這也有類似的效果。還有一大堆很難或不可能呼叫特定用戶的應用程序，例如聊天輪盤賭應用程序，以及具有允許用戶啟動呼叫客戶支持功能的功能的應用程序。 在這項研究中，我把重點放在允許用戶與特定的其他用戶聯(lián)系的會議應用程序上。這將我的200個應用程序列表減少到14個應用程序，如下所示：

該列表是在2020年6月18日編制的。請注意，一些應用被刪除是因為它們的服務器當天未運行，或者它們很難測試（例如，需要觀看多個廣告才能進行一次呼叫）。 由于在測試過程中發(fā)現(xiàn)了一個嚴重的其他BUG，該BUG尚未修復或未達到披露的最終期限，因此在此博客文章中將不會標識已測試的一個應用程序。披露截止日期過去后，將更新此博客文章。 Testing the Exploit 以下部分描述了我針對上述應用程序測試BUG利用的嘗試。請注意，由于應用程序數(shù)量眾多，每個應用程序花費的時間有限，因此無法保證會考慮針對WebRTC的每種攻擊。盡管我非常確信可以被利用的應用程序確實可以被利用，但是我對被發(fā)現(xiàn)無法利用的應用程序沒有把握。如果出于保護用戶的目的，您需要了解特定應用程序是否易受攻擊，請與供應商聯(lián)系，而不是依賴此帖子。 Signal 我從測試Signal開始，因為它是此列表中唯一的開源應用程序。Signal將WebRTC集成為稱為ringrtc的庫的一部分。我先構(gòu)建了ringrtc，然后構(gòu)建了帶有符號的Signal，然后將所需的符號與Frida腳本掛鉤在攻擊者設備上。我嘗試了該BUG利用，并且大約90％的時間都有效！ **視頻1：https://youtu.be/YGK_SmVzVkE 此攻擊不需要用戶與目標設備進行任何交互，因為Signal在接聽來電之前啟動了WebRTC連接，并且該連接可以接受傳入的RTP和SCTP。該BUG在Signal和其他目標上并非100％可靠，因為錯誤376要求將釋放的堆分配替換為該線程執(zhí)行的具有相同大小的下一個分配，并且有時另一個線程會在該線程中進行相同大小的分配。與此同時。故障會導致崩潰，這通常對用戶不可見，因為該過程會重啟，但會出現(xiàn)未接來電。 此BUG攻擊是在2020年1月13日發(fā)布的Signal 4.53.6上執(zhí)行的，因為在我完成該BUG攻擊時，Bug 376已經(jīng)在Signal中進行了修補。CVE-2020-6514在更高版本中也得到了修復，并且ASCONF在usrsctp中也已被禁用，因此導致Bug 376的代碼不再可訪問。Signal最近還實現(xiàn)了一項功能，當呼叫者不在被呼叫者的聯(lián)系人中時，要求用戶進行交互才能啟動WebRTC連接。Signal也已停止在其Beta版本中使用SCTP，并計劃在測試該更改后將其添加到發(fā)行客戶端。此BUG的來源可在此處獲得。 Google Duo Duo也是一個有趣的目標，因為它已預裝在許多Android設備上。它可以動態(tài)鏈接Android WebRTC庫libjingle_peerconnection_so.so，而無需進行明顯的修改。我在IDA中對該庫進行了反向工程，以查找所有需要掛接的函數(shù)的位置，然后修改Frida腳本以根據(jù)它們與導出符號的偏移量來掛接它們。我還修改了cricket ::SctpTransport vtable和全局偏移量表之間的偏移量，因為它與Signal中的有所不同。該BUG也適用于Duo。DuoBUG利用的源代碼在這里。 **視頻2：https://youtu.be/fBuFFmRg_LA 此BUG不需要任何用戶交互，就像Signal一樣，Duo在應答呼叫之前啟動WebRTC連接。 該BUG利用程序已于2019年12月15日發(fā)布的68.0.284888502.DR68_RC09版本進行了測試。此BUG已得到修復。同樣，在發(fā)布此應用程序時，Duo可以調(diào)用任何安裝了Google Play服務的Android設備，而不管是否已安裝Duo?，F(xiàn)在已經(jīng)不是這樣了。用戶現(xiàn)在需要設置Duo，并將呼叫者放在他們的聯(lián)系人中，以便接收來電。 Google Hangouts Google Hangouts使用WebRTC時，它不使用數(shù)據(jù)通道，也不交換SDP來建立呼叫，因此沒有明顯的方法可從對等方啟用它們。因此，該BUG無法在Hangouts中使用。 Facebook Messenger Facebook Messenger是另一個有趣的目標。它擁有大量用戶，根據(jù)其文檔，任何用戶都可以根據(jù)他們的手機號碼呼叫任何其他用戶。Facebook Messenger將WebRTC集成到名為librtcR11.so的庫中，該庫從另一個庫libxplat_third-party_usrsctp_usrsctpAndroid.so動態(tài)鏈接到usrsctp。Facebook Messenger會動態(tài)下載這些庫，而不是將它們包含在APK中，因此很難識別我檢查過的版本，但它是在2020年6月22日下載的。 librtcR11.so庫似乎使用的WebRTC版本大約有六年的歷史，因此早于cricket :: SctpTransport類就已經(jīng)存在。就是說，類似的cricket :: DataMediaChannel類似乎容易受到CVE-2020-6514的攻擊。libxplat_third-party_usrsctp_usrsctpAndroid.so庫似乎更現(xiàn)代，但是包含Bug 376的易受攻擊的代碼。也就是說，似乎不可能從Facebook Messenger獲取此代碼，因為它被設置為使用RTP數(shù)據(jù)通道而不是SCTP數(shù)據(jù)通道，并且不接受通過會話描述協(xié)議（SDP）更改信道類型的嘗試。雖然還不清楚這種設計背后的動機是否是安全性，但這是一個很好的例子，說明了限制攻擊者對功能的訪問可以如何減少應用程序的BUG。Facebook在啟動WebRTC連接之前也會等待一個呼叫被應答，這進一步降低了任何影響它的WebRTCBUG的可利用性。 有趣的是，F(xiàn)acebook Messenger在名為librtcR20.so的庫中還包含WebRTC的更現(xiàn)代版本，但該應用程序似乎未使用它。通過在Android上設置系統(tǒng)屬性，可以使Facebook Messenger使用備用庫，但我找不到攻擊者可以讓設備切換庫的方法。 Viber 與Facebook Messenger一樣，Viber 13.3.0.5版似乎包含易受攻擊的代碼，但是在創(chuàng)建PeerConnectionFactory時，該應用程序會禁用SCTP。這意味著攻擊者無法訪問易受攻擊的代碼。 VK VK是Mail.ru發(fā)布的社交網(wǎng)絡應用程序，其中用戶必須明確允許特定的其他用戶與他們聯(lián)系，然后才允許每個用戶呼叫他們。我針對VK測試了我的BUG，并且需要進行一些修改才能起作用。首先，VK不會將數(shù)據(jù)通道用作其WebRTC連接的一部分，因此我必須啟用它。為此，我編寫了一個Frida腳本，該腳本將Java中的nativeCreateOffer掛鉤，并在創(chuàng)建要約之前調(diào)用createDataChannel。這足以在兩個設備上啟用SCTP，因為目標設備會根據(jù)攻擊者提供的SDP確定是否啟用SCTP。WebRTC的版本也比我為該BUG編寫的版本要老。WebRTC不包含任何版本信息，因此很難確定，但是根據(jù)日志條目來看，該庫至少已有一年的歷史。這意味著利用BUG利用的“假對象”中的某些偏移量是不同的。進行了一些更改，我就可以利用VK。 VK將SDP報價發(fā)送到目標設備以啟動呼叫，但是目標用戶直到用戶接受呼叫后才返回SDP應答，這意味著利用此BUG需要目標在WebRTC連接啟動之前應答呼叫。這意味著除非目標手動應答呼叫，否則攻擊不會起作用。在下面的視頻中，該BUG利用程序/攻擊 在用戶回答后需要相當長的時間才能運行。這是由于我設計BUG利用程序的方式，而不是由于BUG利用的基本限制。尤其是，利用BUG利用程序會等待usrsctp生成特定的數(shù)據(jù)包，即使它們可以通過利用BUG腳本更快地生成，也可以使用延遲來避免在可以檢查響應時對數(shù)據(jù)包進行重新排序。經(jīng)過充分的努力，此攻擊可能會在不到五秒鐘的時間內(nèi)運行。還要注意，我更改了BUG利用程序，使其只能處理一個來電，而不是上述BUG利用中的兩個來電，因為期望目標快速連續(xù)兩次接聽電話是不現(xiàn)實的。盡管這樣做確實使BUG利用代碼更加復雜且難以調(diào)試，但并不需要對BUG利用的工作方式進行重大更改。 **視頻3：https://youtu.be/hoigoOeaeYE 不管怎樣，與沒有這些功能的應用程序相比，用戶必須選擇接受來自攻擊者的呼叫，然后才能進行呼叫，再加上要求用戶應答呼叫并保持在線幾秒鐘的要求，這一BUG利用對VK的作用大大降低。 針對VK 6.7（5631）進行了測試。像Facebook一樣，VK動態(tài)下載其WebRTC版本，因此很難指定其版本，但是測試于2020年7月13日進行。VK自此更新了服務器，以使用戶無法使用包含數(shù)據(jù)通道的SDP發(fā)起呼叫 ，因此該BUG利用不再有效。請注意，VK不會將WebRTC用于兩方通話，而僅用于群組通話，因此我使用群組通話測試了此BUG利用。該BUG的來源可在此處獲得。 OK and TamTam OK和Tamtam是同一供應商（也是Mail.ru）發(fā)布的類似消息傳遞應用程序。他們使用動態(tài)下載的WebRTC版本，該版本與VK使用的版本相同。由于庫是完全一樣的，因此我的BUG利用也可以正常工作，并且我也不必費心測試TamTam，因為它是如此相似。 **視頻4：https://youtu.be/5ZoYQ9QhUzU 與VK一樣，OK和TamTam在目標通過與電話交互應答呼叫之前不會返回SDP應答，因此這不是對OK和TamTam的完全遠程攻擊?！按_定”還要求用戶選擇接受其他用戶的消息，然后該用戶才能呼叫他們。TamTam更為寬松，例如，如果用戶驗證了電話號碼，則擁有其電話號碼的任何用戶都可以與他們聯(lián)系。 測試于7月13日星期一在OK的20.7.7版本上進行。僅SDP測試在TamTam 2.14.0版本上進行。從那時起，這些應用程序的服務器已更新，因此無法使用包含數(shù)據(jù)通道的SDP來發(fā)起呼叫，因此該BUG利用不再起作用。 Discord Discord已徹底記錄了其對WebRTC的使用。應用程序?qū)⒅虚g服務器用于WebRTC連接，這意味著對等方不可能向另一方發(fā)送原始SCTP，而這是利用BUG所必需的。不和諧也需要點擊幾下才能進入通話?；谶@些原因，不和諧不受本文討論的BUG的影響。 JioChat JioChat是一個消息傳遞應用程序，它允許任何用戶基于電話號碼呼叫任何其他用戶。分析版本3.2.7.4.0211，它的WebRTC集成似乎同時包含兩個BUG，并且應用程序在被叫方接受傳入呼叫之前交換SDP提供和應答，因此我希望該BUG能夠在沒有用戶交互的情況下起作用。但是，當我進行測試時情況并非如此，事實證明JioChat使用了不同的策略來阻止WebRTC連接開始，直到被叫方接受了呼叫。我能夠輕松繞過該策略，并獲得在JioChat上運行的BUG。 **視頻5：https://youtu.be/PC1kIrDeOOA 不幸的是，JioChat的連接延遲策略引入了另一個BUG，該BUG已得到修復，但披露期限尚未到期。因此，此博客文章中不會共享有關(guān)如何繞過它的詳細信息。沒有此功能的BUG利用源可在此處獲得。JioChat最近更新了其服務器，因此無法使用包含數(shù)據(jù)通道的SDP來啟動呼叫，這意味著該BUG利用不再適用于JioChat。 Slack and ICQ Slack和ICQ相似之處在于它們都集成了WebRTC，但是沒有使用庫的傳輸功能（請注意，Slack并不直接集成WebRTC進行音頻呼叫，而是集成了Amazon Chime，后者集成了WebRTC）。他們倆都只使用WebRTC進行音頻處理，但實現(xiàn)了自己的傳輸層，并且不使用WebRTC的RTP和SCTP實現(xiàn)。因此，他們不容易受到本博客文章中討論的錯誤以及許多其他WebRTC錯誤的影響。 BOTIM BOTIM具有不尋常的設計，可阻止BUG利用。與調(diào)用createOffer和交換SDP不同，每個對等方基于來自對等方的少量信息生成自己的SDP。默認情況下，此應用程序不使用SCTP，并且無法使用SDP打開它。因此，不可能使用此BUG。BOTIM看起來確實有一種模式，它可以與對等方交換SDP，但我不知道如何啟用它。 Other Application 該BUG利用程序在另一個應用程序上以完全遠程的方式工作，但是對BUG利用程序的設置顯示該應用程序中存在明顯的其他嚴重BUG。該BUG的披露期限到期后，將釋放該BUG在應用程序上的行為的詳細信息。 DiscussionThe Risk of WebRTC 在分析的14個應用程序中，WebRTC對四個應用程序啟用了完全遠程利用，而對另外兩個應用程序啟用了一鍵式攻擊。這凸顯了將WebRTC包含在移動應用程序中的風險。與其他視頻會議解決方案相比，WebRTC不會帶來實質(zhì)性的風險，但在應用程序中包含視頻會議的決定引入了一個巨大的遠程攻擊面，否則將不會出現(xiàn)這種情況。WebRTC是移動應用程序（通常是Android）中為數(shù)不多的完全遠程攻擊面之一。在幾乎所有將其用于視頻會議的應用程序中，它可能都是風險最高的組件。 視頻會議對于某些應用程序的功能至關(guān)重要，但在另一些應用程序中，它卻是很少使用的“額外功能”。低使用率不會使視頻會議對用戶造成任何風險。對于軟件制造商來說，重要的是要考慮視頻會議是否是其應用程序中真正必要的部分，并充分了解視頻會議給用戶帶來的風險。 WebRTC Patching 這項研究表明，許多應用程序在向WebRTC應用安全更新方面落后。Bug376在2019年9月被修復，但在分析的14個應用程序中，只有兩個修補了它。有幾個因素導致了這一點。 首先，usrsctp沒有用于識別和傳達BUG的正式流程。相反，bug376與其他任何bug一樣已得到修復，因此該代碼直到2020年3月10日才被引入到WebRTC中。即使在修補之后，這個bug也沒有在Chrome穩(wěn)定通道的安全提示中被注意到，WebRTC告訴開發(fā)者在這里尋找安全更新。告訴開發(fā)人員尋找安全更新。這意味著，使用舊版本W(wǎng)ebRTC和cherry pick修復程序的應用程序的開發(fā)人員，或者與WebRTC分開包含usrsctp的應用程序的開發(fā)人員不會意識到需要應用此補丁程序。 不過，這還不是全部，因為許多應用程序都將WebRTC作為未修改的庫包含在內(nèi)，并且自2020年3月以來，Chrome安全說明中還包含其他WebRTCBUG。另一個促成因素是，直到2019年，WebRTC都沒有向集成商提供任何安全修補指導，實際上，他們的網(wǎng)站不準確地表示，該庫中從未報告過BUG，這是因為WebRTC安全BUG通常存儲在Chromium錯誤跟蹤器中，并且沒有考慮這些BUG對非當時的瀏覽器集成商。我分析的許多應用程序都具有早于此的WebRTC版本，因此，此不正確指南的遺留之處很可能仍然導致應用程序無法更新WebRTC。盡管WebRTC已經(jīng)做了很多工作，使集成商可以更輕松地修補WebRTC，例如允許大型集成商申請BUG的預先通知，但集成商仍然有很多人只看到了舊指南。當然，如果有更好的指導，也不能保證集成商會遵循更好的指導，但考慮到長期以來集成商很難知道何時以及如何更新WebRTC，即使他們愿意，這很可能會產(chǎn)生影響。 集成商還有責任使WebRTC保持最新的安全修復程序，其中許多在此方面都失敗了。令人驚訝的是，看到這么多版本的WebRTC已經(jīng)使用了一年多。開發(fā)人員應該監(jiān)視他們集成的每個庫中的安全更新，并及時應用它們。 Application Design 應用程序設計會影響WebRTC帶來的風險，并且對許多研究的應用程序進行了精心設計。限制WebRTC的安全影響的最簡單，最重要的方法是，在被叫方通過與設備進行交互來接受呼叫之前，避免啟動WebRTC連接。這會將可能迅速危害任何用戶的攻擊轉(zhuǎn)化為需要用戶交互的攻擊，并且不會在每個目標上都成功。這也使得質(zhì)量較低的BUG實際上不可利用，因為雖然完全遠程攻擊可以多次嘗試而用戶不會注意到，但需要用戶應答呼叫的攻擊需要嘗試少量嘗試。 延遲啟動WebRTC連接會影響性能，并且會妨礙或排除某些功能，例如為被呼叫者提供呼叫預覽。該BUG利用的應用程序中，有兩個在沒有用戶交互的情況下啟動了連接，還有兩個需要用戶交互。JioChat和我們尚未確定的應用程序試圖使用獨特的技巧來延遲連接，直到用戶接受呼叫為止，而不會影響性能，但結(jié)果引入了BUG。開發(fā)人員應該知道，延遲WebRTC連接的最佳方法是避免在用戶接受調(diào)用之前調(diào)用setRemoteDescription。其他方法可能實際上不會延遲連接，并可能導致其他安全問題。 降低WebRTC安全風險的另一種方法是限制攻擊者可以呼叫的人，例如，要求被呼叫方在其聯(lián)系人列表中包含該用戶，或者只允許同意在應用程序中互相發(fā)送消息的用戶之間進行呼叫。就像延遲連接一樣，這大大減少了攻擊者不費吹灰之力就能到達的目標。 最后，集成商應將攻擊者可以使用的WebRTC功能限制為應用程序所需的功能。許多應用程序不容易受到此特定攻擊的影響，因為它們已有效禁用了SCTP。其他人沒有使用SCTP，但是沒有以阻止攻擊者使用它的方式禁用它，而我能夠啟用它。禁用WebRTC中功能的最好方法是在編譯時將其刪除，某些編解碼器支持此功能。也可以通過PeerConnection和PeerConnectionFactory禁用某些功能，這也非常有效。特性也可以通過過濾SDP來禁用，但重要的是要確保過濾器是健壯的并經(jīng)過徹底測試。 Conclusion 我為Android的WebRTC編寫了一個BUG攻擊，涉及usrsctp中的兩個BUG。這個BUG在Signal、googleduo、JioChat和另一個應用程序上是完全遠程的，需要用戶在VK、OK和TamTam上進行交互。其他休閑包沒有受到影響，因為他們有效地禁用了SCTP。多個應用程序使用的WebRTC版本不包含針對BUG利用的任何BUG的修補程序。一個仍未修補。補丁程序吸收率低的部分原因是WebRTC歷史上提供的補丁程序指導不力。集成商可以通過要求用戶交互來啟動WebRTC連接，限制用戶可以輕松調(diào)用的用戶并禁用未使用的功能來降低WebRTC的風險。他們還應該考慮視頻會議是否是其應用程序的重要和必要功能。 Vendor Response 在這篇博客文章中提到的軟件供應商在這篇文章公開發(fā)布之前被給予了一個審閱的機會，并提供了一些回復，如下： WebRTC 修復了用于繞過ASLR和移動指令指針的WebRTC錯誤。WebRTC不再直接將SctpTransport指針傳遞到usrsctp，而是使用映射到SctpTransport的不透明標識符，而忽略無效值。我們已經(jīng)識別并修補了每一個受影響的Google產(chǎn)品，并使用WebRTC聯(lián)系了50個應用程序和集成商，包括本文分析的所有應用程序。對于所有尚未修補該BUG的應用程序和集成器，我們建議更新到WebRTC M85分支，或修補以下兩個問題。 Mail.ru 用戶安全是所有Mail.ru G集團的產(chǎn)品（包括VK，OK，TamTam等產(chǎn)品）的最高優(yōu)先事項。根據(jù)我們收到的有關(guān)BUG的信息，我們立即開始將移動應用程序更新為最新版本的WebRTC的過程。此更新當前正在進行中。我們還在我們的服務器上實現(xiàn)了算法，不再允許在我們的產(chǎn)品中利用此BUG。此操作使我們能夠在收到利用BUG演示的信息后3小時內(nèi)為所有用戶修復該問題。 Signal 我們感謝在發(fā)現(xiàn)這些BUG和改進WebRTC生態(tài)系統(tǒng)安全性方面所做的努力。Signal在被發(fā)現(xiàn)之前已經(jīng)發(fā)布了一個防御補丁來保護用戶免受此攻擊。除了對調(diào)用庫進行例行更新外，我們還將繼續(xù)采取主動措施，以減輕未來WebRTC錯誤的影響。 Slack 我們很高興看到這份報告得出結(jié)論，Slack不受引用的WebRTC BUG和BUG攻擊的影響。在了解到這一風險后，我們進行了額外的調(diào)查，并確認我們的整個呼叫服務沒有受到此處描述的BUG和調(diào)查結(jié)果的影響。

原文標題：使用WebRTC開發(fā)Android Messenger：第3部分

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。