新款iPhone SE開售前夕，iOS被曝存在八年的0day漏洞 |
| 來源：聚銘網(wǎng)絡(luò) 發(fā)布時間：2020-04-24 瀏覽次數(shù)： |
信息來源：Freebuf
近日，安全研究人員發(fā)現(xiàn)iPhone和iPad自帶的默認(rèn)郵件應(yīng)用程序MobileMail 和Maild存在兩個正在被在野利用的嚴(yán)重漏洞，而且至少在兩年前就已經(jīng)開始監(jiān)視用戶了。 這兩個漏洞允許遠(yuǎn)程攻擊者秘密獲取蘋果設(shè)備的控制權(quán)，只要向已經(jīng)登錄郵件賬號的用戶設(shè)備發(fā)送電子郵件即可。這可能會使超過5億部iPhone容易受到黑客的攻擊。同時，iPad也存在這一問題。
舊金山的一家手機(jī)安全取證公司ZecOps在周三發(fā)布的一份報告中表示，在2019年末調(diào)查一起客戶網(wǎng)絡(luò)攻擊事件時，發(fā)現(xiàn)了該問題。ZecOps創(chuàng)始人Zuk Avraham表示，他發(fā)現(xiàn)證據(jù)顯示，這一漏洞至少在六起網(wǎng)絡(luò)入侵事件中被利用。
Zuk推特聲明 該漏洞是存在于蘋果自帶郵件應(yīng)用程序中的MIME庫中的遠(yuǎn)程代碼執(zhí)行漏洞，首先是因?yàn)樵浇鐚懭脲e誤，其次是堆溢出問題。 盡管兩個電子郵件都是在處理郵件時觸發(fā)的，但是第二個漏洞更為嚴(yán)重一些，因?yàn)槠淇梢詫?shí)現(xiàn)“零點(diǎn)擊”利用，無需任何用戶交互。
報告中還提及疑似遭受攻擊的目標(biāo)：
八年零日漏洞在野利用據(jù)研究員表明，兩個漏洞存在iPhone 和iPad多個版本中長達(dá)8年，可以追溯到iOS6，甚至影響了當(dāng)前的iOS 13.4.1，常規(guī)版本尚且沒有補(bǔ)丁更新。 更讓人擔(dān)憂的是，多個攻擊者組織長期利用這些漏洞（至少在野零日攻擊中利用了2年最早可追溯到2018年1月）。 研究人員說：“目前公布的攻擊數(shù)據(jù)有限，但是至少有6個組織或者個體遭受攻擊，影響力還是很大的。盡管ZecOps沒有發(fā)現(xiàn)攻擊的幕后黑手，但是我們了解到至少有一個“雇傭組織”在銷售該漏洞利用，并將電子郵件地址作為唯一標(biāo)識符。 此外，對于蘋果用戶本身來說是很難意識到黑客的入侵的，因?yàn)樗麄冊讷@取用戶遠(yuǎn)程操控之后，可以立即刪除惡意電子郵件。
除了郵件使用速度的短暫下降以外，用戶沒法發(fā)現(xiàn)任何的異常行為。成功的漏洞利用是讓黑客在MobileMail 或者M(jìn)aild 應(yīng)用程序中執(zhí)行惡意代碼，并竊取、修改或者刪除郵件。
然而，想要完全操控設(shè)備，黑客還需要一個助手，即單獨(dú)的內(nèi)核漏洞（比如無法修補(bǔ)的Checkm8漏洞）。盡管目前研究人員還沒有發(fā)現(xiàn)黑客使用的惡意軟件細(xì)節(jié)，但是郵件的漏洞和內(nèi)核漏洞結(jié)合使用來監(jiān)控他們的目標(biāo)用戶也不是沒有可能。 當(dāng)心！目前尚無可用補(bǔ)丁研究人員在兩個月前發(fā)現(xiàn)這次的在野利用攻擊，并將其報告給蘋果安全團(tuán)隊(duì)。 截至發(fā)文，只有iOS13.4.5 beta版本在上周發(fā)布，包含了這兩個漏洞的安全補(bǔ)丁。
而數(shù)百外的iPhone 和iPad用戶還需等待下一次的軟件安全補(bǔ)丁更新。與此同時，強(qiáng)烈建議蘋果用戶不要使用設(shè)備內(nèi)置的郵件應(yīng)用程序。 漏洞詳情ZecOps發(fā)現(xiàn)，在MIME庫中的執(zhí)行MFMutableData，沒有對系統(tǒng)調(diào)用ftruncate()進(jìn)行錯誤檢查，這會導(dǎo)致越界寫入。研究人員找到了一種無需等待系統(tǒng)調(diào)用ftruncate失敗即可觸發(fā)OOB-Write的方法。此外，他們還發(fā)現(xiàn)可以遠(yuǎn)程觸發(fā)的堆溢出。 事實(shí)上，這兩種漏洞都是遠(yuǎn)程觸發(fā)的。 OOB寫入錯誤和堆溢出錯誤都是由于相同的問題而發(fā)生的：未正確處理系統(tǒng)調(diào)用的返回值。 遠(yuǎn)程錯誤可以在處理下載電子郵件時觸發(fā)，在這種情況下，電子郵件將無法完全下載到設(shè)備上。
事故取證分析用戶經(jīng)歷的部分崩潰（多次崩潰中的一部分）如下。 崩潰指令是stnp x8, x9, [x3]，這意味著價值x8，并x9已寫入x3并墜毀由于訪問無效的地址0x000000013aa1c000，其存儲在x3。 Thread3Crashed: 0 libsystem_platform.dylib 0x000000019e671d88_platform_memmove+88 0x19e671d84 b.ls0x00008da8 0x19e671d88 stnpx8,x9,[x3] 0x19e671d8c stnpx10,x11,[x3, #16] 0x19e671d90 addx3,x3, 0x20 0x19e671d94 ldnpx8,x9,[x1] 1 MIME 0x00000001b034c4d8-[MFMutableData appendBytes:length:]+ 356 2 Message 0x00000001b0b379c8-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]+ 808
為了找出導(dǎo)致流程崩潰的原因，來看一下MFMutableData的實(shí)現(xiàn)。 下面的調(diào)用樹取自部分崩潰日志。 -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- memmove() 通過分析MIME庫， -[MFMutableData appendBytes:length:] 偽代碼如下：
崩潰發(fā)生之前，已執(zhí)行以下調(diào)用堆棧： -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:]| +-- -[MFMutableData appendBytes:length:]| +-- -[MFMutableData setLength:]| +-- -[MFMutableData _flushToDisk:capacity:]| +-- ftruncate() 如果數(shù)據(jù)大小達(dá)到閾值，則使用文件來存儲實(shí)際數(shù)據(jù)，當(dāng)數(shù)據(jù)更改時，應(yīng)相應(yīng)更改映射文件的內(nèi)容和大小。-[MFMutableData _flushToDisk:capacity:]在內(nèi)部調(diào)用系統(tǒng)調(diào)用ftruncate()來調(diào)整映射文件的大小。 以下是-[MFMutableData _flushToDisk:capacity:] 的偽代碼：
ftruncate詳情主頁： ftruncate() andtruncate() cause thefilenamedbypath,orreferencedbyfildes,tobe truncated (orextended)tolengthbytesinsize.Ifthefilesizeexceedslength,anyextradataisdiscarded.Ifthefilesizeissmallerthanlength, thefileisextendedandfilledwithzerostothe indicatedlength. The ftruncate()formrequires thefiletobeopenforwriting.RETURNVALUESAvalueof0isreturnedifthecallsucceeds.Ifthecallfails a-1isreturned,andtheglobalvariableerrno specifies theerror. 主頁顯示：“If the call fails a -1 is returned, and the global variable errno specifies the error.”這意味著在某些情況下，此系統(tǒng)調(diào)用將無法截斷文件并返回錯誤代碼。 然而，一旦系統(tǒng)調(diào)用ftruncate失敗，無論如何_flushToDisk會繼續(xù)進(jìn)行，這意味著在appendBytes()函數(shù)中映射文件大小沒有延伸并無法執(zhí)行達(dá)到memmove()，這導(dǎo)致MMAP文件的OOB寫入。 尋找另一個觸發(fā)因素崩潰是由于系統(tǒng)調(diào)用ftruncate()失敗引起的，是否意味著除了等待系統(tǒng)調(diào)用失敗之外什么也不能做？ 再來看一下-[MFMutableData _flushToDisk:capacity:]函數(shù)。
在[b]行中所見，檢查flush在調(diào)用ftruncate()之前標(biāo)志是否為true。這意味著，如果可以將flush在第[a]行將標(biāo)志設(shè)置為false ，則ftruncate()根本不會執(zhí)行。 如果有人在調(diào)用-[MFMutableData appendData:]之前調(diào)用-[MFMutableData setLength:](set flush to 0), ftruncate() won’t be executed due to flush==0)，將會得到類似的結(jié)果。 將此OOB Write與其他漏洞或控制內(nèi)存布局的方法結(jié)合使用，可以遠(yuǎn)程觸發(fā)此漏洞，例如，通過控制選擇器。
盡管這確實(shí)是一個應(yīng)修補(bǔ)的漏洞，但我們懷疑它是由攻擊者試圖利用以下漏洞而觸發(fā)的。 第二個漏洞：MFMutable中的遠(yuǎn)程堆溢出研究人員繼續(xù)調(diào)查可疑的遠(yuǎn)程事件，并確定同一區(qū)域存在另一個漏洞。 回溯可以如下所示： -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- -[MFMutableData _mapMutableData] 在分析代碼流時，研究人員確定了以下內(nèi)容：
易受攻擊的函數(shù)的偽代碼如下： 系統(tǒng)調(diào)用mmap失敗時，- [MFMutableData_mapMutableData:]調(diào)用函數(shù)MFMutableData__mapMutableData___block_invoke
偽代碼MFMutableData__mapMutableData___block_invoke如下，它分配了一個大小為8的堆內(nèi)存，然后用分配內(nèi)存替換data->bytes指針。
執(zhí)行-[MFMutableData _mapMutableData:]完之后，進(jìn)程繼續(xù)執(zhí)行-[MFMutableData appendBytes:length:]，將數(shù)據(jù)復(fù)制到分配內(nèi)存時導(dǎo)致堆溢出。 -[MFMutableDataappendBytes:length:] { int length = [selflength]; //... bytes =self->bytes; if(!bytes){ bytes = [self_mapMutableData];//Might be a data pointer of a size8heap } copy_dst = bytes + length; //... platform_memmove(copy_dst, append_bytes, append_length);//It used append_length to copy the memory, causing an OOB writingina small heap } append_length是來自流式傳輸?shù)臄?shù)據(jù)塊的長度。由于這MALLOC_NANO是一個可預(yù)測的內(nèi)存區(qū)域，因此可以利用此漏洞。 攻擊者無需耗盡內(nèi)存的每一個最后一位就可以使mmap失敗，因?yàn)閙map需要一個連續(xù)的內(nèi)存區(qū)域。 復(fù)現(xiàn)根據(jù)mmap操作說明，在MAP_ANON was specified and insufficient memory was available時mmap會失敗。 mmap失敗是正常情況，理想情況下，電子郵件夠大就不可避免地會發(fā)生。但是，可以使用其他可耗盡資源的技巧來觸發(fā)漏洞。這些技巧可以通過多方面，比如RTF和其他格式來實(shí)現(xiàn)。 可能影響可利用性的另一個重要因素是硬件規(guī)格：
較舊的設(shè)備具有較小的物理RAM和較小的虛擬內(nèi)存空間，因此不必耗盡RAM的每一位來觸發(fā)此錯誤，當(dāng)無法在可用虛擬內(nèi)存中找到給定大小的連續(xù)內(nèi)存空間時，mmap將失敗。 目前已經(jīng)確定MacOS不會同時受到這兩個漏洞的攻擊。 在iOS 12中，觸發(fā)漏洞更容易，數(shù)據(jù)流傳輸是在同一過程中完成的，因?yàn)槟J(rèn)郵件應(yīng)用程序（MobileMail）會處理更多的資源，從而耗盡了虛擬內(nèi)存空間（尤其是UI）的分配渲染，而在iOS 13中，MobileMail將數(shù)據(jù)流傳遞到后臺進(jìn)程maild。它把資源集中在解析電子郵件上，從而降低了虛擬內(nèi)存空間意外用完的風(fēng)險。 遠(yuǎn)程復(fù)現(xiàn)由于MobileMail / maild并未明確設(shè)置電子郵件大小的最大限制，因此可以設(shè)置自定義電子郵件服務(wù)器并發(fā)送具有幾GB純文本的電子郵件。iOS MIME /消息庫在流傳輸數(shù)據(jù)時將數(shù)據(jù)平均分成大約0×100000字節(jié)，因此完全可以不下載整個電子郵件。 請注意，這只是如何觸發(fā)此漏洞的一個示例。攻擊者無需為了觸發(fā)此漏洞而發(fā)送此類電子郵件，使用多種方式，比如RTF或其他格式等技巧，可以使用標(biāo)準(zhǔn)大小的電子郵件實(shí)現(xiàn)相同的目標(biāo)。 披露時間表
|
