蘋(píng)果手機(jī)軟件FaceTime的一項(xiàng)重大漏洞被曝光

曾幾何時(shí)，人們對(duì)于蘋(píng)果產(chǎn)品的信任程度就好像他們經(jīng)常使用的冰箱、空調(diào)、洗衣機(jī)一樣，但隨著“蘋(píng)果絕對(duì)安全”謠言的破滅，更多安全人員開(kāi)始投身到蘋(píng)果產(chǎn)品的漏洞挖掘研究之中。

今年年初，蘋(píng)果手機(jī)軟件FaceTime的一項(xiàng)重大漏洞被曝光，更是讓人們深知世上并無(wú)絕對(duì)的安全可言。

據(jù)The Verge報(bào)道，該漏洞可以讓用戶(hù)通過(guò) FaceTime 群聊功能（Group FaceTime）打電話(huà)給任何人，在對(duì)方接受或拒絕來(lái)電之前，就能聽(tīng)到他們手機(jī)里的聲音，該漏洞的曝光把蘋(píng)果推上了輿論的風(fēng)口浪尖。

那么，這樣的漏洞是如何被發(fā)現(xiàn)的呢？除了上述漏洞之外，F(xiàn)aceTime是否還存在著其他安全風(fēng)險(xiǎn)呢？

在此次ISC上，盤(pán)古團(tuán)隊(duì)聯(lián)合創(chuàng)始人王鐵磊、盤(pán)古實(shí)驗(yàn)室研究員黃濤就“蘋(píng)果FaceTime零接觸遠(yuǎn)程漏洞首次被還原”這一議題詳細(xì)解密了FaceTime的逆向全程并分享了幾個(gè)典型的漏洞案例。

內(nèi)繁外簡(jiǎn)的FaceTime

然而，對(duì)FaceTime進(jìn)行過(guò)逆向漏洞挖掘研究的黃濤卻深知它的“內(nèi)在”遠(yuǎn)沒(méi)有我們看到的這么簡(jiǎn)單，其內(nèi)部結(jié)構(gòu)甚至可以使用“錯(cuò)綜復(fù)雜”來(lái)形容。

通過(guò)逆向分析黃濤發(fā)現(xiàn)，F(xiàn)aceTime UI界面其實(shí)分成了通訊框和視頻區(qū)兩個(gè)部分?？此坪?jiǎn)單的UI區(qū)域?qū)崉t是由多個(gè)進(jìn)程在合作完成整個(gè)UI的運(yùn)作，它們分別是callservicesd、avconferenced（macOS）和mediaserverd（iOS）三個(gè)部分組成。

其中，callservicesd進(jìn)程主要負(fù)責(zé)渲染通訊框部分，以及撥打或者掛電話(huà)的功能。callservicesd進(jìn)程主要管理了三個(gè)功能——第一個(gè)是FaceTime接聽(tīng)、撥打的音視頻狀態(tài)；第二個(gè)是反饋、響應(yīng)一些FaceTime產(chǎn)生的UI上的數(shù)據(jù)；其次會(huì)為avconferenced（macOS）和mediaserverd（iOS）兩個(gè)進(jìn)程去提供信息傳遞的橋梁。

avconferenced和mediaserverd主要負(fù)責(zé)右邊的視頻區(qū)，它們負(fù)責(zé)處理通訊時(shí)的圖像內(nèi)容，其主要的功能就是將自身的音視頻發(fā)給遠(yuǎn)端或者處理遠(yuǎn)端傳遞過(guò)來(lái)的音視頻信息。

現(xiàn)在試想，當(dāng)一個(gè)用戶(hù)撥打FaceTime請(qǐng)求的時(shí)候，首先會(huì)點(diǎn)擊左邊的通訊框內(nèi)容選擇通話(huà)對(duì)象，這時(shí)UI會(huì)發(fā)送UINotification-Call通信，以此告知系統(tǒng)“我要打一個(gè)電話(huà)出去”。

這個(gè)時(shí)候callservicesd就會(huì)接受到系統(tǒng)發(fā)出的UINotification，它會(huì)通過(guò)一個(gè)函數(shù)開(kāi)啟通話(huà)模式的請(qǐng)求。然后，callservicesd就會(huì)調(diào)用【CSDFaceTimeProviderDelegateprovider：performStartCallAction】函數(shù)與avconferenced做交互，獲取到lnviteData請(qǐng)求并以此建立通話(huà)渠道。

在通話(huà)渠道創(chuàng)建之后，其通訊數(shù)據(jù)會(huì)被返回給callservicesd。這時(shí)callservicesd會(huì)將其內(nèi)部的通訊數(shù)據(jù)封裝起來(lái)并傳送給identityservicesd，這就是callservicesd的第三個(gè)動(dòng)作，也是和avconferenced（macOS）以及mediaserverd（iOS）建立通信橋梁的過(guò)程（identityservicesd是一個(gè)系統(tǒng)進(jìn)程，主要用來(lái)管理用戶(hù)和iCould和MAC的連接）。

隨后，identityservicesd會(huì)將通訊信息機(jī)型封裝，并且同時(shí)把它傳輸給一個(gè)叫apsd（用于和蘋(píng)果發(fā)射推送數(shù)據(jù)）的進(jìn)程，后者和蘋(píng)果保持了可行的安全連接，它們?cè)诔钟薪换プC書(shū)的情況下運(yùn)作以確保進(jìn)程的安全性。

在apsd收到來(lái)自identityservicesd的封裝信息之后，前者會(huì)再度將一層一層的數(shù)據(jù)打包成一個(gè)對(duì)象，同時(shí)將其推送給AppleServer。當(dāng)然，蘋(píng)果服務(wù)器不會(huì)簡(jiǎn)單地把消息推送過(guò)去，而是會(huì)對(duì)消息做一個(gè)簡(jiǎn)單的過(guò)濾。

“老實(shí)說(shuō)，我們發(fā)現(xiàn)這種過(guò)濾機(jī)制并非真的能確保FaceTime整個(gè)運(yùn)作進(jìn)程的安全可靠，在尚未被過(guò)濾的信息中，我們?nèi)钥烧业娇赡鼙还粽哌h(yuǎn)端控制的數(shù)據(jù)?！?/p>

原來(lái)，研究人員會(huì)人為發(fā)送一組數(shù)據(jù)進(jìn)入到上述的進(jìn)程流程當(dāng)中，在經(jīng)過(guò)蘋(píng)果服務(wù)器過(guò)濾后，再通過(guò)對(duì)比這些數(shù)據(jù)和遠(yuǎn)端發(fā)送的數(shù)據(jù)，以此得知哪些數(shù)據(jù)是可控的。在這個(gè)流程完成后，蘋(píng)果服務(wù)器就會(huì)把a(bǔ)psiMessage傳遞給遠(yuǎn)端的apsd，也就是被呼叫那個(gè)用戶(hù)的設(shè)備上了。

在接聽(tīng)方設(shè)備收到數(shù)據(jù)后，便能夠看到來(lái)自撥打方的音視頻信息，為了實(shí)現(xiàn)雙向交流，與此同時(shí)apsd收到的數(shù)據(jù)會(huì)采用與上述完全一致的封裝結(jié)構(gòu)來(lái)反序列化apsiMessage。為了方便觀察apsiMessage中具體包含了哪些數(shù)據(jù)信息，通常會(huì)在其反序列的函數(shù)里面設(shè)置一個(gè)斷點(diǎn)。

通過(guò)設(shè)置斷點(diǎn)，可以看到其中幾個(gè)比較重要的參數(shù)，它們標(biāo)示了apsd數(shù)據(jù)包究竟會(huì)被傳輸?shù)侥抢镞M(jìn)行處理。apsd會(huì)通過(guò)兩個(gè)參數(shù)把消息傳遞給mediaserverd，之后進(jìn)一步進(jìn)行反序列化。

“最終，我們?cè)趍ediaserverd函數(shù)里面看到數(shù)據(jù)變了，其中有一個(gè)字段叫做C的值是232，其代表遠(yuǎn)端發(fā)來(lái)的是一個(gè)Notification。通過(guò)不同的C值，比如說(shuō)232、233、234、235來(lái)調(diào)用不同的函數(shù)去處理Notification，所以即便不改變漏洞內(nèi)容，只改變與之對(duì)應(yīng)的處理函數(shù)會(huì)不一樣?！?/p>

緊接著，mediaserverd會(huì)繼續(xù)把數(shù)據(jù)解開(kāi)然后發(fā)給callservicesd，其同樣也會(huì)把數(shù)據(jù)進(jìn)行反序列化，將其推送給遠(yuǎn)端的mediaserverd。如此以來(lái)，遠(yuǎn)程呼叫端的設(shè)備就獲取到了呼叫端的媒體配置信息和加密信息。在這些數(shù)據(jù)處理完之后，呼叫端遠(yuǎn)端就會(huì)跳出一個(gè)UI上面顯示——有一個(gè)人正在通過(guò)Facetime與你通話(huà)的音視頻信息。

這樣一來(lái)，一次FaceTime的通話(huà)連接便被建立起來(lái)了。

為了實(shí)現(xiàn)實(shí)時(shí)的通話(huà)需求，遠(yuǎn)端用戶(hù)接通的時(shí)候同樣會(huì)產(chǎn)生一個(gè)與上述FaceTime UI數(shù)據(jù)傳遞路徑完全一致的反交換過(guò)程，這一過(guò)程同樣會(huì)被遠(yuǎn)端的callservicesd去處理，接下來(lái)流程和之前幾乎是一樣。

“值得注意的是，在反向通訊的過(guò)程中之前的C值不是232而是233了，這時(shí)遠(yuǎn)端已經(jīng)接受了對(duì)方設(shè)備視頻的請(qǐng)求，這時(shí)會(huì)調(diào)用相應(yīng)函數(shù)值來(lái)處理返回過(guò)來(lái)的數(shù)據(jù)。這種情況下，兩端都會(huì)打開(kāi)各自的avconferenced（macOS）和mediaserverd（iOS）端口，并且在穿墻協(xié)議的幫助下實(shí)現(xiàn)雙方找到IP建立端對(duì)端鏈接?！?/p>

通過(guò)端對(duì)端的鏈接，identityservicesd負(fù)責(zé)處理和接收網(wǎng)絡(luò)包，另一個(gè)函數(shù)會(huì)調(diào)用apsiMessage從udp端口拿到網(wǎng)絡(luò)包傳遞給IDSGlobaLink，后者會(huì)判斷該網(wǎng)絡(luò)報(bào)是否符合seiten協(xié)議，如果是就會(huì)將其傳送給對(duì)應(yīng)的執(zhí)行函數(shù)，進(jìn)一步解析網(wǎng)絡(luò)包，再次將其發(fā)送給更細(xì)分的執(zhí)行函數(shù)。與此同時(shí)，identityservicesd還會(huì)響應(yīng)一些其他的協(xié)議。

這張圖是真正的在建立FaceTime之后其數(shù)據(jù)的音視頻究竟是怎樣的，到這里逆向的分析也就告一段落了。

可見(jiàn)，看似簡(jiǎn)潔的FaceTime其進(jìn)行數(shù)據(jù)處理、執(zhí)行及反饋的渠道多到令人咋舌的地步，這也注定FaceTime更容易存在攻擊面。而對(duì)于如此龐雜的數(shù)據(jù)流通線(xiàn)路，其中需要用戶(hù)進(jìn)行操控的地方少之又少，這就意味著一旦攻擊開(kāi)始，其整個(gè)過(guò)程具有極強(qiáng)隱蔽性。

FaceTime的4個(gè)漏洞案例分享

從上面FaceTime逆向的過(guò)程可以看出，實(shí)際上從呼出到最終的雙方看到音視頻信息是一個(gè)非常長(zhǎng)的處理流程。也就是說(shuō)，一旦逆向分析有所疏漏，漏洞挖掘的過(guò)程只是在某一層進(jìn)行，這就難免會(huì)使得研究數(shù)據(jù)完整性欠缺，甚至?xí)p壞其格式。

那么，在搞清楚FaceTime的工作原理之后，關(guān)于其漏洞挖掘的過(guò)程才算真正開(kāi)始。在這里，王鐵磊分享了4個(gè)FaceTime的漏洞分析案例。

案例1

第一個(gè)案例介紹的是一個(gè)疑似的信息泄露，這個(gè)漏洞發(fā)生在從apsd到avconferenced之間，也就是在最初的信息數(shù)據(jù)包處理上。

通過(guò)查看數(shù)據(jù)流，發(fā)現(xiàn)攻擊者的數(shù)據(jù)包中包含了一些U字段的報(bào)文數(shù)據(jù)。這個(gè)U字段數(shù)據(jù)實(shí)際上是一個(gè)UUID，其本身只是一些嵌入符號(hào)，并沒(méi)有什么特別的含義。

“但是，我們發(fā)現(xiàn)通過(guò)在其前后插入額外的字段，可以讓這些原本毫無(wú)意義的字段來(lái)強(qiáng)制執(zhí)行一些命令?！?/p>

首先在Notification插入一些額外的字段，當(dāng)遠(yuǎn)端收到之后U字段和人工植入的數(shù)據(jù)都在其中，于是強(qiáng)制返回包中會(huì)包含UUID——到目前為止整個(gè)流程上還沒(méi)有什么問(wèn)題，只是一方面是數(shù)據(jù)的發(fā)送另一方面是信息的返回。但是，因?yàn)檫@里有同樣的字段，這也正是漏洞的所在。

首先，來(lái)看看這段代碼的具體意思——收到一個(gè)Notification以后，遠(yuǎn)端會(huì)把整個(gè)字典數(shù)據(jù)做一個(gè)分析，它先試圖去看有沒(méi)有所謂的U字段，有的話(huà)就把U字段所對(duì)應(yīng)的數(shù)據(jù)包給取出來(lái)，并假定其是一個(gè)AI Sdatae，然后將其作為參數(shù)傳入一個(gè)以GWUUID開(kāi)頭的函數(shù)中，其本意是為了把AI Sdatae轉(zhuǎn)換成一個(gè)CFStun，但是這個(gè)假定數(shù)據(jù)的長(zhǎng)度是16字節(jié)，而因?yàn)槠湔{(diào)用的一個(gè)函數(shù)的LOKCBfer是沒(méi)有初始化的，這就意味這如果發(fā)出去的UUID的長(zhǎng)度不到16字節(jié)，那么就有可能得到一個(gè)未初始化的棧溢出數(shù)據(jù)。

為了證明上述猜測(cè)，研究人員首先發(fā)送了一個(gè)遠(yuǎn)端的UUID。研究人員的最初想法，是想看到的輸出一些值得關(guān)注的地址，但卻發(fā)現(xiàn)改造后的Notification發(fā)過(guò)去后在遠(yuǎn)端收到的UUID不見(jiàn)了，這就意味著蘋(píng)果服務(wù)器那端把短的UUID剝離掉了，從代碼角度來(lái)看這是一個(gè)100%未初始化內(nèi)存泄露的問(wèn)題，但是真實(shí)POC構(gòu)造過(guò)程中蘋(píng)果服務(wù)器扮演了一個(gè)未知的角色，因此不確定是何時(shí)開(kāi)始過(guò)濾的。

案例2

當(dāng)FaceTime的連接建立之后，一個(gè)非常重要的一個(gè)角色就是mediaserverd，因?yàn)閙ediaserverd進(jìn)程負(fù)責(zé)第一層網(wǎng)絡(luò)報(bào)文的處理，F(xiàn)aceTime的所有數(shù)據(jù)或者其它控制的發(fā)送，這些報(bào)文在最初的未處理狀態(tài)都被mediaserverd服務(wù)運(yùn)行。

mediaserverd會(huì)根據(jù)包的內(nèi)容來(lái)去選擇是哪些其它的進(jìn)程或者是其它的函數(shù)來(lái)處理，其中typeMessage攻擊者就可以通過(guò)udp把攻擊文件發(fā)送到遠(yuǎn)端的mediaserverd，遠(yuǎn)端的mediaserverd會(huì)識(shí)別typeMessage。

根據(jù)它的協(xié)議，typeMessage在偏移為“4”的地方會(huì)有執(zhí)行。因此，從代碼執(zhí)行上可以看到mediaserverd就是做了一個(gè)比較，如果包里存在為“4”的值那就是typeMessage，然后將其一個(gè)函數(shù)除去，之后發(fā)送的報(bào)文會(huì)被反序列化成為一個(gè)叫IDSStunMessage的對(duì)象，而IDSStunMessage在這個(gè)反序列化構(gòu)成中沒(méi)有發(fā)現(xiàn)什么特別的漏洞，然后當(dāng)typeMessage被反序列化成這個(gè)對(duì)象以后，會(huì)進(jìn)一步處理函數(shù)。

實(shí)際上，期間過(guò)程中一共包含了20個(gè)屬性，他們?nèi)渴菑膗dp報(bào)文中拷貝過(guò)去的，也就是說(shuō)它們?cè)诂F(xiàn)在這一階段是完全可以被攻擊者控制的。如果typeMessage中的type數(shù)值為“0x17”，這時(shí)會(huì)阻斷一個(gè)特殊函數(shù)，其功能是將類(lèi)型為19的屬性取出來(lái)，這一過(guò)程都屬于安全流程，但是在隨后的反序列化過(guò)程中就會(huì)暴露出很多問(wèn)題。

反序列化的時(shí)候數(shù)據(jù)格式非常簡(jiǎn)單，它就是兩字節(jié)的type兩字節(jié)的長(zhǎng)度。但實(shí)際上，這里面如果看到一個(gè)屬性的type是0xF或者很多種類(lèi)型的屬性都會(huì)得到一個(gè)叫readIDSGLAttrBinaryData的函數(shù)，其過(guò)程會(huì)調(diào)用到memcpy。而這個(gè)memcpy的case參數(shù)完全可控，其執(zhí)行難度不大，稍加長(zhǎng)度布局的改動(dòng)即可讓其顯示141414.。。的錯(cuò)誤顯示，這是一個(gè)典型的堆出漏洞。

案例3

callservicesd會(huì)把數(shù)據(jù)再轉(zhuǎn)給avconferenced（macOS）或者mediaserverd（iOS），這其實(shí)進(jìn)入到了音視頻流的處理流程，而這里的這個(gè)漏洞是一個(gè)棧溢出。

該漏洞的原理是——當(dāng)去做視頻剪輯的時(shí)候，一幀數(shù)據(jù)可能會(huì)很大，這個(gè)時(shí)候一個(gè)處理單元就可能被分割成多個(gè)RTP包被進(jìn)行傳送，然后接受方接收了這些包之后再重組成完整數(shù)據(jù)包做處理。由于RTP包是通過(guò)UDP包來(lái)的，所以有前有后，為了維持如此布局就要將這些RTP都進(jìn)行串聯(lián)，在傳送到之后才重組起來(lái)。

在每收到一個(gè)RTP包的時(shí)候會(huì)嚴(yán)格檢查包的格式，但是有時(shí)候會(huì)出現(xiàn)丟包的情況，在蘋(píng)果的處理方案中，其引入了一種容錯(cuò)機(jī)制——它可以通過(guò)已經(jīng)收到的包去重構(gòu)出一些已丟包的基本信息，這就是為什么在發(fā)生網(wǎng)絡(luò)抖動(dòng)的時(shí)候，F(xiàn)aceTime聊天的畫(huà)面會(huì)糊一點(diǎn)，但還是能夠保持能看到基本的內(nèi)容的原因。

但是問(wèn)題在于，在做包修復(fù)的時(shí)候，RTP里面會(huì)含一個(gè)叫做FEC的東西會(huì)重構(gòu)出RTP包，重構(gòu)出來(lái)的長(zhǎng)度則是在FEC Header里面制定的。但是FEC Header是沒(méi)有經(jīng)過(guò)任何檢查的，所以最后導(dǎo)致的后果就是容錯(cuò)機(jī)制被調(diào)度起來(lái)的時(shí)候，執(zhí)行函數(shù)中的size是完全可控的，這是最經(jīng)典的棧溢出。

那么，在2019年iOS上面，棧溢出還能不能利用？

實(shí)際上，像這種傳統(tǒng)的經(jīng)典棧溢出的最有效防范就是啟用cookie。它的基本原理就是當(dāng)函數(shù)值被調(diào)用的時(shí)候，在返回地址和局部變量之間插入一個(gè)cookie，在函數(shù)返回的時(shí)候從棧上把剛才的cookie拿出來(lái)作比較，如果二者不一致的話(huà)那么意味著整個(gè)cookie都被破壞掉了，很可能返回地址也已經(jīng)被破壞掉了，所以這時(shí)該程序就可以主動(dòng)地退出，避免整個(gè)返回地址被控制住。

這種連續(xù)溢出會(huì)破壞stack_cookie，這些指令在函數(shù)執(zhí)行進(jìn)來(lái)的時(shí)候，函數(shù)參數(shù)（地址）已經(jīng)在棧上了，有些指令可以把一些寄存器暫時(shí)壓在棧上，這幾條指令在分配局部變量，其實(shí)也是在放置棧的cookie。

其中的問(wèn)題是，棧cookie被放在了局部變量后面，這就意味著當(dāng)局部變量發(fā)生棧溢出的時(shí)候它會(huì)直接覆蓋到crashed而無(wú)需破壞stack_cookie。這個(gè)問(wèn)題十分嚴(yán)重，stack_cookie根本沒(méi)有放在一個(gè)合適的位置，自然也起不了正常的作用。

通過(guò)crash log的截圖可以看出，在iOS上可以看到serverd34號(hào)線(xiàn)程已經(jīng)發(fā)生了崩潰，整個(gè)PC已經(jīng)完全被控制，變成了808080，與此同時(shí)其他的寄存器也都被控制了。在將該漏洞報(bào)告蘋(píng)果后，后者在12.4版本中做了修復(fù)，但事情并沒(méi)有就此告一段落：

在意識(shí)到stack_cookie出問(wèn)題的時(shí)候，研究人員又去檢查了其他的模塊及函數(shù)，他們發(fā)現(xiàn)很多函數(shù)都有這個(gè)問(wèn)題，因此他們意識(shí)到這里還有一個(gè)編譯器的漏洞。因此，結(jié)論是這是一個(gè)在FaceTime棧溢出背后還有一個(gè)編譯器漏洞問(wèn)題。

實(shí)際上，蘋(píng)果是LLVM編譯器的一個(gè)最大推手，如果蘋(píng)果編譯器有問(wèn)題那么多半意味著LLVM編譯器有問(wèn)題，最終這個(gè)問(wèn)題蘋(píng)果的安全團(tuán)隊(duì)在進(jìn)行更詳細(xì)的分析后發(fā)現(xiàn)確實(shí)如此，其影響的是整個(gè)品牌的編譯器產(chǎn)品，這也是為什么之后該廠(chǎng)商為這樣一個(gè)威脅程度為0的漏洞發(fā)布了公開(kāi)聲明的原因。

案例4

identityservicesd會(huì)根據(jù)收到的Notification里的一個(gè)函數(shù)決定是將消息發(fā)給callservicesd還是其它的服務(wù)。這是一個(gè)叫做Phone countinuity的漏洞，它原本是可以實(shí)現(xiàn)在MAC筆記本和iPhone在登陸統(tǒng)一Apple ID的情況啟用通話(huà)功能的一項(xiàng)附加功能。雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)

實(shí)際上，這就意味著手機(jī)和電腦之間存在著一個(gè)數(shù)據(jù)通道。他們也做了一些逆向分析，最終發(fā)現(xiàn)這個(gè)還是在identityservicesd做的處理。

其實(shí)會(huì)存在這樣的執(zhí)行路徑，IDSLinkManager最后會(huì)走到一個(gè)叫做IDSSockAddrWrapper initWithSockAddr：的函數(shù)。這個(gè)函數(shù)實(shí)際是根據(jù)UTP包中的內(nèi)容去反序列化一些地址，這里也是最終出問(wèn)題的地方。如果大家對(duì)去年的imptcp模塊安全漏洞熟悉的話(huà)，iOS內(nèi)核嘗試著去把一個(gè)用戶(hù)的數(shù)據(jù)反序列化成一個(gè)soft地址，問(wèn)題是對(duì)于一個(gè)有效地址其長(zhǎng)度是0X80，但一個(gè)soft結(jié)構(gòu)體它的長(zhǎng)度域可表達(dá)的范圍是0XFF，這就與意味著當(dāng)把一個(gè)地址進(jìn)行拷貝時(shí)，要根據(jù)其第一字節(jié)的長(zhǎng)度來(lái)進(jìn)行調(diào)節(jié)，因此一定要做嚴(yán)格的長(zhǎng)度檢查。但是，這個(gè)函數(shù)里只對(duì)地址域進(jìn)行了檢查，沒(méi)有檢查長(zhǎng)度，這意味著可以把第一個(gè)字節(jié)填稱(chēng)0XFF最多可以溢出0XFF-［字節(jié)長(zhǎng)度］這么長(zhǎng)，那這個(gè)函數(shù)和前面說(shuō)到了漏洞利用十分接近。

總結(jié)

在整個(gè)分析中，F(xiàn)aceTime的大量攻擊漏洞被逐一挖掘出來(lái)。

在對(duì)FaceTime進(jìn)行分析時(shí)王鐵磊稱(chēng)，首先，F(xiàn)aceTime的代碼質(zhì)量非常差，這個(gè)出乎他們的預(yù)期，整個(gè)FaceTime需要一個(gè)極大的提高，否則隨著安全研究人員的不斷挖掘會(huì)有更多漏洞被曝出來(lái)；其次，整個(gè)Message的接口有非常大的畸變，其本質(zhì)都是通過(guò)identityservicesd做的一個(gè)轉(zhuǎn)化，這么多功能糅雜在一起也就意味這復(fù)雜性很高，那么攻擊面是非常大的；最后對(duì)于進(jìn)行安全研究的人員來(lái)說(shuō)，很多老的漏洞并沒(méi)有過(guò)時(shí)，比如上面講的棧溢出就是十分經(jīng)典的例子。