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

文 /?Natalie Silvanovich

原文鏈接：

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

?

Part 2: A Better Bug

在使用WebRTC開(kāi)發(fā)Android Messenger：第1部分中，我探討了是否有可能在RTP處理中使用兩個(gè)內(nèi)存損壞bug來(lái)利用WebRTC。當(dāng)我成功移動(dòng)指令指針時(shí)，我無(wú)法破解ASLR，因此我決定尋找更適合此目的的漏洞。

?

usrsctp

我首先瀏覽了過(guò)去提交的WebRTC bugs，以查看是否有可能破壞ASLR。 即使很早就修復(fù)了bug，它也表明可能在何處發(fā)現(xiàn)了類(lèi)似的漏洞。這樣的bug是CVE-2020-6831，該漏洞在usrsctp中的越界讀取。

usrsctp是WebRTC使用的流控制傳輸協(xié)議（SCTP）的實(shí)現(xiàn)。使用WebRTC的應(yīng)用程序可以打開(kāi)數(shù)據(jù)通道，該通道允許將文本或二進(jìn)制數(shù)據(jù)從對(duì)等方傳輸。數(shù)據(jù)通道通常用于允許在視頻通話(huà)期間交換文本消息，或在發(fā)生某些事件時(shí)告訴對(duì)等方，例如另一個(gè)對(duì)等方禁用其攝像頭。? SCTP是數(shù)據(jù)通道的基礎(chǔ)協(xié)議。在WebRTC中，SCTP類(lèi)似于RTP，其中RTP用于音頻和視頻內(nèi)容，SCTP用于數(shù)據(jù)。

我花了一些時(shí)間檢查usrsctp代碼中的漏洞。 我最終找到了CVE-2020-6831，這是從usrsctp中的堆棧緩沖區(qū)溢出。該bug使攻擊者可以完全控制溢出的大小和內(nèi)容。 Samuel Gro?建議，這個(gè)bug可以用來(lái)破壞ASLR，方法是覆蓋堆棧cookie，然后一次覆蓋一個(gè)字節(jié)的返回地址，并根據(jù)應(yīng)用程序是否崩潰來(lái)檢測(cè)值是否正確。不幸的是，事實(shí)證明，此bug無(wú)法通過(guò)WebRTC訪(fǎng)問(wèn)，因?yàn)樗枰蛻?hù)端套接字連接到偵聽(tīng)套接字，而在WebRTC中，兩個(gè)套接字都是客戶(hù)端套接字。

我一直在尋找，最終找到了CVE-2020-6514。 這是WebRTC如何與usrsctp交互的一個(gè)非常不尋常的bug。? usrsctp支持自定義傳輸，在這種情況下，集成商需要為每個(gè)連接提供一對(duì)無(wú)效指針，以提供源地址和目標(biāo)地址。 這些指針的未取消引用的值隨后被usrsctp用作地址，這意味著該值包含在某些數(shù)據(jù)包中。 在WebRTC中，地址指針設(shè)置為WebRTC使用的SctpTransport實(shí)例的地址。 結(jié)果是在每個(gè)SCTP連接期間，此對(duì)象在內(nèi)存中的位置將發(fā)送到遠(yuǎn)程對(duì)等方。從技術(shù)上講，這是WebRTC中的bug，盡管usrsctp的設(shè)計(jì)也有缺陷，因?yàn)閷?duì)自定義地址使用void*類(lèi)型會(huì)強(qiáng)烈鼓勵(lì)集成器使用該值的指針，盡管這是不安全的。

我希望此bug足以破解ASLR，但事實(shí)并非如此。對(duì)于漏洞利用，我需要一個(gè)已加載庫(kù)的位置以及堆的位置，因此我在Android設(shè)備上進(jìn)行了一系列測(cè)試，以查看這些位置之間是否存在任何關(guān)聯(lián)，結(jié)果是沒(méi)有任何關(guān)聯(lián)。堆指針的位置不足以確定加載的庫(kù)的位置。

?

我一直在尋找，我注意到usrsctp處理ASCONF塊的方式中存在一個(gè)漏洞，這些塊用于管理動(dòng)態(tài)IP地址。該錯(cuò)誤的來(lái)源如下：

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_m_freem(m_ack); }

請(qǐng)注意，對(duì)sctp_m_freem的第二次調(diào)用缺少了一個(gè)返回值，因此m_ack變量可以在釋放后使用。發(fā)現(xiàn)此漏洞后，我注意到該bug已在usrsctp和WebRTC的較新版本中進(jìn)行了修補(bǔ)。后來(lái)我得知，另一位Google員工Mark Wodrich在2019年9月19日將其報(bào)告為usrsctp中的Bug 376。

?

Revealing Memory with Bug376

在分析一個(gè)“后用”bug時(shí)，兩個(gè)重要的問(wèn)題是釋放了什么，以及如何使用它。在Bug 376中，釋放的對(duì)象是一個(gè)mbuf結(jié)構(gòu)，一種用于存儲(chǔ)入站和出站數(shù)據(jù)包內(nèi)容的類(lèi)型。

mbuf結(jié)構(gòu)從一個(gè)子結(jié)構(gòu)m_hdr開(kāi)始，它的定義如下：

?

struct m_hdr { struct mbuf *mh_next; /* next buffer in chain */ struct mbuf *mh_nextpkt; /* next chain in queue/record */ caddr_t ?mh_data; /* location of data */ int ?mh_len; /* amount of data in this mbuf */ int ?mh_flags; /* flags; see below */ short ?mh_type; /* type of data in this mbuf */ uint8_t? ? ? ? ? pad[M_HDR_PAD];/* word align? ? ? ? ? ? ? ? ? */ }

那么，這個(gè)結(jié)構(gòu)是如何使用的呢?

查看ASCONF處理的其余部分，它最終被添加到一個(gè)出站包隊(duì)列中，以確認(rèn)發(fā)送的包。

TAILQ_INSERT_TAIL(&stcb->asoc.asconf_ack_sent, ack, next);

這使得如果將釋放的m_buf結(jié)構(gòu)替換為帶有指向內(nèi)存連續(xù)指針的結(jié)構(gòu)（例如，CVE-2020-6514顯示的SctpTransport指針）的結(jié)構(gòu)，則該錯(cuò)誤很可能被用于顯示遠(yuǎn)程對(duì)等機(jī)的內(nèi)存。

?

我試圖通過(guò)發(fā)送與m_buf結(jié)構(gòu)大小相同的RTP包來(lái)實(shí)現(xiàn)這一點(diǎn)。有一個(gè)很好的訣竅可以讓大量特定大小的分配在WebRTC中無(wú)法釋放。視頻包在被組合成幀之前被存儲(chǔ)在一個(gè)列表中，因此，如果一個(gè)幀的末尾從未被發(fā)送，它們將被永久存儲(chǔ)，只要沒(méi)有達(dá)到最大數(shù)量的包。不幸的是，這導(dǎo)致了一個(gè)意想不到的問(wèn)題。WebRTC使用的OpenSSL碰巧有一些堆分配，其大小與m_buf結(jié)構(gòu)的大小相同，如果它們恰好被分配到釋放的m_buf結(jié)構(gòu)的位置，它們將被寫(xiě)入m_buf send進(jìn)程中，這出于某種原因?qū)?dǎo)致OpenSSL中的不可恢復(fù)狀態(tài)。應(yīng)用程序沒(méi)有崩潰，它只會(huì)陷入某種循環(huán)中，拒絕接受更多的連接。

所以我決定在usrsctp中分配內(nèi)存來(lái)代替m_buf結(jié)構(gòu)會(huì)更好。SCTP允許將包含任意數(shù)量的塊的數(shù)據(jù)包發(fā)送到主機(jī)，并且在大多數(shù)情況下，它們被當(dāng)作一個(gè)數(shù)據(jù)包序列來(lái)處理。更好的是，在當(dāng)前數(shù)據(jù)包中的所有塊都被處理之前，添加了釋放的m_buf結(jié)構(gòu)的出站數(shù)據(jù)包隊(duì)列不會(huì)發(fā)送任何數(shù)據(jù)包。這意味著應(yīng)該可以發(fā)送一個(gè)包，其中包含一個(gè)觸發(fā)該錯(cuò)誤的塊，然后發(fā)送一個(gè)塊，該塊將釋放的內(nèi)存設(shè)置為所需的值，然后將其發(fā)送回攻擊者。由于在釋放m_buf結(jié)構(gòu)和安全地重新分配內(nèi)存之間不需要發(fā)生網(wǎng)絡(luò)通信，因此避免了OpenSSL的問(wèn)題。

不幸的是，在usrsctp中對(duì)malloc的調(diào)用很少，其大小可以由傳入流量控制，并且沒(méi)有一個(gè)允許指定整個(gè)包內(nèi)容。我能找到的最好的方法是處理數(shù)據(jù)流重置塊。代碼如下，為清楚起見(jiàn)刪除了一些部分。

if (asoc->str_reset_seq_in == seq) { len = ntohs(req->ph.param_length); number_entries = ((len - sizeof(struct sctp_stream_reset_out_request)) / sizeof(uint16_t)); tsn = ntohl(req->send_reset_at_tsn); asoc->last_reset_action[1] = asoc->last_reset_action[0]; if (...) { ... } else if (SCTP_TSN_GE(asoc->cumulative_tsn, tsn)) { /* we can do it now */ ... } else { /* ?* we must queue it up and thus wait for the TSN's ?* to arrive that are at or before tsn ?*/ struct sctp_stream_reset_list *liste; int siz; siz = sizeof(struct sctp_stream_reset_list) + (number_entries * sizeof(uint16_t)); SCTP_MALLOC(liste, struct sctp_stream_reset_list *,? siz, SCTP_M_STRESET); if (liste == NULL) { /* gak out of memory */ asoc->last_reset_action[0] = SCTP_STREAM_RESET_RESULT_DENIED; sctp_add_stream_reset_result(chk, seq, asoc->last_reset_action[0]); return; } liste->seq = seq; liste->tsn = tsn; liste->number_entries = number_entries; memcpy(&liste->list_of_streams, req->list_of_streams, number_entries * sizeof(uint16_t)); TAILQ_INSERT_TAIL(&asoc->resetHead, liste, next_resp);

此代碼分配了liste結(jié)構(gòu)，該結(jié)構(gòu)可用于替換釋放的mbuf結(jié)構(gòu)。它有一個(gè)非常幸運(yùn)的功能，那就是與mbuf結(jié)構(gòu)的mh_next屬性對(duì)齊的next_resp屬性恰好是mbuf類(lèi)型。如果這是另一種類(lèi)型，則會(huì)導(dǎo)致問(wèn)題，因?yàn)閡srsctp在發(fā)送數(shù)據(jù)包之前會(huì)遍歷整個(gè)mbuf鏈。

?

一個(gè)不太幸運(yùn)的特性是，與mbuf結(jié)構(gòu)的mh_data屬性一致的屬性恰好是當(dāng)前重置序列號(hào)和傳輸序列號(hào)（TSN）。在這種方法中，兩者都要經(jīng)過(guò)多次檢查。重置序列號(hào)需要完全等于初始化連接時(shí)設(shè)置的序列號(hào)（在INIT或COOKIE_ECHO塊中），還需要等于SctpTransport指針的低位四個(gè)字節(jié)。可以通過(guò)發(fā)送COOKIE_ECHO塊來(lái)通過(guò)此檢查，該塊在觸發(fā)錯(cuò)誤之前將重置序列號(hào)設(shè)置為所需的值。

更具挑戰(zhàn)性的是在TSN上執(zhí)行的檢查。它與累積TSN進(jìn)行比較，后者最初被設(shè)置為與重置序列號(hào)相同的值。實(shí)際執(zhí)行的比較是一個(gè)“序列號(hào)大于”，它確定一個(gè)值是在另一個(gè)值之前還是在后面，假設(shè)序列號(hào)在所有位都被設(shè)置時(shí)滾動(dòng)到零。例如，如果當(dāng)前序列號(hào)為0xFFFFFFFF，則值2將通過(guò)“序列號(hào)大于”檢查，但值0xFFFFFFFE和0x80000001將失敗。從傳入數(shù)據(jù)包中讀出的TSN必須是SctpTransport指針的前四個(gè)字節(jié)，而累積的TSN必須是該指針的后四個(gè)字節(jié)，因?yàn)樗c重置序列號(hào)的值相同。所以這實(shí)際上是指針的兩半部分之間的比較。TSN是一個(gè)很小的數(shù)字，小于0x80，因?yàn)樗侵羔樀捻敳?#xff0c;所以每當(dāng)指針的第31位未設(shè)置時(shí)，此比較將大致返回true，并在設(shè)置指針時(shí)大致返回所需的false結(jié)果。

指針的第31位是由ASLR隨機(jī)確定的，以及SctpTransport實(shí)例在堆上分配的位置，這意味著它被設(shè)置為大約50%的時(shí)間。通常情況下，我可以接受50%有效的漏洞攻擊，因?yàn)檫@意味著它很可能只需嘗試幾次就可以成功，但在這種情況下，這不是真的，因?yàn)樗谕粋€(gè)ASLR布局上會(huì)有一次又一次失敗的傾向。ASLR布局是在Android設(shè)備啟動(dòng)時(shí)確定的，并且在重新啟動(dòng)之前不會(huì)再次更改。所以我需要一種方法在重置序列號(hào)被設(shè)置之后改變累積的TSN。

?

事實(shí)證明，使用FWD_TSN塊類(lèi)型是可行的，該類(lèi)型允許一個(gè)對(duì)等方請(qǐng)求另一個(gè)對(duì)等方將其累積的TSN最多向前移動(dòng)4096字節(jié)。通過(guò)重復(fù)發(fā)送此塊類(lèi)型，可以將累積的TSN向前移動(dòng)足夠多的位，以使第31位翻轉(zhuǎn)。這需要相當(dāng)多的數(shù)據(jù)塊，但是將這些數(shù)據(jù)塊組合成更少的數(shù)據(jù)包并盡可能快地發(fā)送出去，它可以在幾秒鐘內(nèi)翻轉(zhuǎn)過(guò)來(lái)。

總而言之，這個(gè)bug可以用來(lái)讓目標(biāo)設(shè)備發(fā)回SctpTransport實(shí)例的內(nèi)存，該實(shí)例包含指向類(lèi)的vtable的指針，最后給出WebRTC庫(kù)的位置并破壞ASLR。

仔細(xì)想想，我不認(rèn)為WebRTC庫(kù)是我的漏洞利用的最佳庫(kù)，因?yàn)閃ebRTC集成器將它靜態(tài)地與其他庫(kù)鏈接起來(lái)并使用各種工具鏈?zhǔn)呛苷５摹８菀字纋ibc的位置，libc來(lái)自Android系統(tǒng)，變化較小。所以我添加了這個(gè)bug的第二個(gè)用法，從全局偏移表讀取malloc的位置，這是從已經(jīng)讀取的SctpTransport vtable的固定偏移量。這允許計(jì)算libc的位置。

?

Moving the InstructionPointer (Again)

在使用WebRTC開(kāi)發(fā)Android Messenger：第1部分中，我弄清楚了如何使用RTP內(nèi)存損壞錯(cuò)誤來(lái)移動(dòng)指令指針，但是在提交CVE-2020-6514之后，Jann Horn建議也可以使用該bug來(lái)移動(dòng)指令指針。當(dāng)WebRTC使用SctpTransport指針作為地址時(shí)，它不僅使用它來(lái)標(biāo)識(shí)連接，而且實(shí)際上也使用它將指針強(qiáng)制轉(zhuǎn)換為SctpTransport類(lèi)，并在發(fā)送從usrsctp接收的出站數(shù)據(jù)包時(shí)對(duì)其進(jìn)行虛擬調(diào)用。

?

同時(shí)，usrsctp通常根據(jù)數(shù)據(jù)包中的標(biāo)識(shí)符確定出站數(shù)據(jù)包的地址，但是唯獨(dú)在一種情況下，它需要從數(shù)據(jù)包本身提取地址：在處理COOKIE_ECHO塊時(shí)。通常，不可能將不可信的指針?lè)旁谶@種塊類(lèi)型中，因?yàn)橥ǔ?huì)從傳入的數(shù)據(jù)包中回顯它們，并且需要對(duì)其進(jìn)行簽名。但是，Jann注意到簽名密鑰的隨機(jī)數(shù)生成非常弱。初始化usrsctp時(shí)，將調(diào)用以下代碼。

?

srandom(getpid());?

然后通過(guò)調(diào)用rand為隨機(jī)數(shù)生成器提供種子。

啟動(dòng)SCTP連接時(shí)發(fā)送的INIT塊包含用于身份驗(yàn)證的隨機(jī)生成的密鑰，該密鑰由用于密鑰的同一隨機(jī)數(shù)生成器生成。我編寫(xiě)了一個(gè)腳本，根據(jù)這個(gè)密鑰確定遠(yuǎn)程PID的值，方法是對(duì)0到70000之間的每個(gè)數(shù)字調(diào)用srand，并查看哪個(gè)會(huì)導(dǎo)致隨機(jī)數(shù)生成器生成相同的身份驗(yàn)證密鑰。然后就可以推斷出密鑰的值。

?

現(xiàn)在，此密鑰允許攻擊設(shè)備發(fā)送包含任何內(nèi)容的COOKIE_ECHO塊，包括將地址更改為自定義指針。這允許移動(dòng)指令指針，因?yàn)橄乱淮伟l(fā)送出站數(shù)據(jù)包時(shí)，將對(duì)提供的任何地址進(jìn)行虛擬調(diào)用，當(dāng)對(duì)等方用COOKIE_ACK響應(yīng)時(shí)，將立即進(jìn)行虛擬調(diào)用。在上面的部分中，我還討論了如何使用COOKIE_ECHO包來(lái)更改重置序列號(hào)，同時(shí)還討論了如何實(shí)際發(fā)送它們。它是用同樣的方法。

我現(xiàn)在有兩種可能的方法來(lái)設(shè)置利用漏洞的指令指針。我選擇繼續(xù)使用這個(gè)，因?yàn)樗褂胾srsctp，這也是打破ASLR所必需的，而RTP-one使用了一個(gè)不同的特性。我覺(jué)得減少需要啟用的特性的數(shù)量可以增加它所使用的應(yīng)用程序的數(shù)量，因?yàn)橛袝r(shí)應(yīng)用程序會(huì)禁用特定的WebRTC功能。

?

Putting it All Together

具有利用漏洞所需的所有必要功能后，我需要將它們?nèi)空显谝黄稹Ｎ业囊话悴呗允窃谝阎恢玫亩焉蟿?chuàng)建一個(gè)假對(duì)象，然后對(duì)該對(duì)象進(jìn)行虛擬調(diào)用。假對(duì)象將在同一個(gè)緩沖區(qū)中有一個(gè)假vtable，它將指向system，后者將運(yùn)行shell命令。

缺少的一環(huán)是如何在已知位置填充堆內(nèi)存。一種可能是使用RTP來(lái)分配與SctpTransport對(duì)象大小相同的內(nèi)存，希望它在對(duì)象后面的地址或可預(yù)測(cè)的位置分配。我試過(guò)這個(gè)方法，大概50%的時(shí)間都有效，但考慮到我有辦法讀懂記憶，我想我可以做得更好。

我注意到SctpTransport類(lèi)包含一個(gè)CopyOnWriteBuffer對(duì)象，名為partial_incoming_message_，它有時(shí)用于存儲(chǔ)傳入的SCTP數(shù)據(jù)。如果rtcp支持不完整的數(shù)據(jù)包，那么這些數(shù)據(jù)包將通過(guò)不完整的scp。這些存儲(chǔ)在部分“傳入”消息對(duì)象中，直到接收到數(shù)據(jù)包的其余部分。所以我想如果我通過(guò)SCTP把假對(duì)象的數(shù)據(jù)發(fā)送到目標(biāo)設(shè)備，它最終會(huì)填充這個(gè)緩沖區(qū)，我可以讀取地址。（請(qǐng)注意，這實(shí)際上需要兩次讀取，因?yàn)樵贑opyOnWriteBuffer對(duì)象與其支持?jǐn)?shù)據(jù)之間存在兩級(jí)間接尋址。）

我試過(guò)了，效果很好，但還有另一個(gè)問(wèn)題。為了用一個(gè)假vtable創(chuàng)建一個(gè)假對(duì)象，這個(gè)假對(duì)象需要引用它自己，但是這個(gè)方法只允許我知道內(nèi)存被寫(xiě)入后的位置，并且不能更改。我仔細(xì)看了一下這個(gè)功能是如何工作的。設(shè)置緩沖區(qū)的代碼如下。

transport->partial_incoming_message_.AppendData( ??????????reinterpret_cast<uint8_t*>(data), length); ??????????... if (!(flags & MSG_EOR) && (transport->partial_incoming_message_.size() < kSctpSendBufferSize)) { ????????return 1; ??????} ... transport->invoker_.AsyncInvoke<void>( RTC_FROM_HERE, transport->network_thread_, rtc::Bind(&SctpTransport::OnInboundPacketFromSctpToTransport, transport, transport->partial_incoming_message_, params, flags)); transport->partial_incoming_message_.Clear();

這里發(fā)生的情況是，傳入的數(shù)據(jù)總是立即附加到partial_incoming_message_緩沖區(qū)中，然后，如果它是不完整的片段，則函數(shù)將返回。否則，它將使線(xiàn)程排隊(duì)以處理數(shù)據(jù)，然后清除緩沖區(qū)。

考慮到可能尚未完成的排隊(duì)線(xiàn)程仍然需要數(shù)據(jù)，我開(kāi)始懷疑清除的工作原理。事實(shí)證明，CopyOnWriteBuffer類(lèi)會(huì)保留對(duì)數(shù)據(jù)的引用，并且僅在剩余零個(gè)引用的情況下才將其刪除。否則，它將減少引用計(jì)數(shù)并為緩沖區(qū)分配當(dāng)前大小的新數(shù)據(jù)。這意味著可以在寫(xiě)入數(shù)據(jù)之前讀取_incoming_message_緩沖區(qū)的位置，因?yàn)樗鼘?shí)際上是在清除期間分配的。只要由AppendData寫(xiě)入的數(shù)據(jù)更短或與已清除的最大大小相同，該內(nèi)存就不會(huì)被重新分配。

這允許我在一個(gè)已知的位置創(chuàng)建一個(gè)堆緩沖區(qū)并填充它。最后一步是找出要填充的內(nèi)容。我首先用序列號(hào)填充它，然后使用它崩潰的地址來(lái)計(jì)算要更改的內(nèi)存。在使用crash locations創(chuàng)建假vtable之后，我最終在一個(gè)到X8的分支上發(fā)生了崩潰，唯一的另一個(gè)可控寄存器是X21。X0當(dāng)然被設(shè)置為假vtable的位置，因?yàn)檫@次崩潰是由于一個(gè)虛擬調(diào)用造成的，X1和X23也是如此。

?

令人驚訝的是，libc有一個(gè)完美的工具來(lái)應(yīng)對(duì)這種情況。

?

do_nftw(char const*,int (*) …) + 0x138 LDR ? ? ? ? ? ? X0, [X23,#0x30] LDR ? ? ? ? ? ? X1, [X23,#0x70] BLR ? ? ? ? ? ? X21

將X23中加載的值設(shè)置為system，并將一個(gè)字符串參數(shù)復(fù)制到偽虛函數(shù)表的偏移0x30處，從而導(dǎo)致系統(tǒng)被該參數(shù)調(diào)用!

?

?為了快速概述，以下是利用該漏洞所需的步驟，依次為：

?

1. 根據(jù)INIT塊中的密鑰確定PID，然后確定秘密密鑰

2. 從SctpTransport對(duì)象讀取vtable

3. 從全局偏移量表中讀取malloc的位置

4. 用所需大小的數(shù)據(jù)填充partial_incoming_message_緩沖區(qū)

5. 清除了partial_incoming_message_緩沖區(qū)，因此分配了新緩沖區(qū)

6. 從SctpTransport對(duì)象讀取partial_incoming_message_緩沖區(qū)的地址

7. 從緩沖區(qū)結(jié)構(gòu)中讀取partial_incoming_message_后備緩沖區(qū)的地址

8. 基于malloc的位置，partial_incoming_message_緩沖區(qū)填充有漏洞利用數(shù)據(jù)

9. 觸發(fā)該漏洞，先虛擬調(diào)用小工具，然后再調(diào)用系統(tǒng)

?

現(xiàn)在我發(fā)現(xiàn)了一個(gè)漏洞，它在WebRTC的Android應(yīng)用程序示例中起作用。

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點(diǎn)擊【閱讀原文】了解更多詳細(xì)信息

總結(jié)

以上是生活随笔為你收集整理的使用WebRTC开发Android Messenger：第2部分的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。