新款iPhone SE開售前夕，iOS被曝存在八年的0day漏洞 |
| 來源：聚銘網絡 發(fā)布時間：2020-04-24 瀏覽次數(shù)： |
信息來源：Freebuf
近日，安全研究人員發(fā)現(xiàn)iPhone和iPad自帶的默認郵件應用程序MobileMail 和Maild存在兩個正在被在野利用的嚴重漏洞，而且至少在兩年前就已經開始監(jiān)視用戶了。 這兩個漏洞允許遠程攻擊者秘密獲取蘋果設備的控制權，只要向已經登錄郵件賬號的用戶設備發(fā)送電子郵件即可。這可能會使超過5億部iPhone容易受到黑客的攻擊。同時，iPad也存在這一問題。
舊金山的一家手機安全取證公司ZecOps在周三發(fā)布的一份報告中表示，在2019年末調查一起客戶網絡攻擊事件時，發(fā)現(xiàn)了該問題。ZecOps創(chuàng)始人Zuk Avraham表示，他發(fā)現(xiàn)證據(jù)顯示，這一漏洞至少在六起網絡入侵事件中被利用。
Zuk推特聲明 該漏洞是存在于蘋果自帶郵件應用程序中的MIME庫中的遠程代碼執(zhí)行漏洞，首先是因為越界寫入錯誤，其次是堆溢出問題。 盡管兩個電子郵件都是在處理郵件時觸發(fā)的，但是第二個漏洞更為嚴重一些，因為其可以實現(xiàn)“零點擊”利用，無需任何用戶交互。
報告中還提及疑似遭受攻擊的目標：
八年零日漏洞在野利用據(jù)研究員表明，兩個漏洞存在iPhone 和iPad多個版本中長達8年，可以追溯到iOS6，甚至影響了當前的iOS 13.4.1，常規(guī)版本尚且沒有補丁更新。 更讓人擔憂的是，多個攻擊者組織長期利用這些漏洞（至少在野零日攻擊中利用了2年最早可追溯到2018年1月）。 研究人員說：“目前公布的攻擊數(shù)據(jù)有限，但是至少有6個組織或者個體遭受攻擊，影響力還是很大的。盡管ZecOps沒有發(fā)現(xiàn)攻擊的幕后黑手，但是我們了解到至少有一個“雇傭組織”在銷售該漏洞利用，并將電子郵件地址作為唯一標識符。 此外，對于蘋果用戶本身來說是很難意識到黑客的入侵的，因為他們在獲取用戶遠程操控之后，可以立即刪除惡意電子郵件。
除了郵件使用速度的短暫下降以外，用戶沒法發(fā)現(xiàn)任何的異常行為。成功的漏洞利用是讓黑客在MobileMail 或者Maild 應用程序中執(zhí)行惡意代碼，并竊取、修改或者刪除郵件。
然而，想要完全操控設備，黑客還需要一個助手，即單獨的內核漏洞（比如無法修補的Checkm8漏洞）。盡管目前研究人員還沒有發(fā)現(xiàn)黑客使用的惡意軟件細節(jié)，但是郵件的漏洞和內核漏洞結合使用來監(jiān)控他們的目標用戶也不是沒有可能。 當心！目前尚無可用補丁研究人員在兩個月前發(fā)現(xiàn)這次的在野利用攻擊，并將其報告給蘋果安全團隊。 截至發(fā)文，只有iOS13.4.5 beta版本在上周發(fā)布，包含了這兩個漏洞的安全補丁。
而數(shù)百外的iPhone 和iPad用戶還需等待下一次的軟件安全補丁更新。與此同時，強烈建議蘋果用戶不要使用設備內置的郵件應用程序。 漏洞詳情ZecOps發(fā)現(xiàn)，在MIME庫中的執(zhí)行MFMutableData，沒有對系統(tǒng)調用ftruncate()進行錯誤檢查，這會導致越界寫入。研究人員找到了一種無需等待系統(tǒng)調用ftruncate失敗即可觸發(fā)OOB-Write的方法。此外，他們還發(fā)現(xiàn)可以遠程觸發(fā)的堆溢出。 事實上，這兩種漏洞都是遠程觸發(fā)的。 OOB寫入錯誤和堆溢出錯誤都是由于相同的問題而發(fā)生的：未正確處理系統(tǒng)調用的返回值。 遠程錯誤可以在處理下載電子郵件時觸發(fā)，在這種情況下，電子郵件將無法完全下載到設備上。
事故取證分析用戶經歷的部分崩潰（多次崩潰中的一部分）如下。 崩潰指令是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
為了找出導致流程崩潰的原因，來看一下MFMutableData的實現(xiàn)。 下面的調用樹取自部分崩潰日志。 -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- memmove() 通過分析MIME庫， -[MFMutableData appendBytes:length:] 偽代碼如下：
崩潰發(fā)生之前，已執(zhí)行以下調用堆棧： -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:]| +-- -[MFMutableData appendBytes:length:]| +-- -[MFMutableData setLength:]| +-- -[MFMutableData _flushToDisk:capacity:]| +-- ftruncate() 如果數(shù)據(jù)大小達到閾值，則使用文件來存儲實際數(shù)據(jù)，當數(shù)據(jù)更改時，應相應更改映射文件的內容和大小。-[MFMutableData _flushToDisk:capacity:]在內部調用系統(tǒng)調用ftruncate()來調整映射文件的大小。 以下是-[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)調用將無法截斷文件并返回錯誤代碼。 然而，一旦系統(tǒng)調用ftruncate失敗，無論如何_flushToDisk會繼續(xù)進行，這意味著在appendBytes()函數(shù)中映射文件大小沒有延伸并無法執(zhí)行達到memmove()，這導致MMAP文件的OOB寫入。 尋找另一個觸發(fā)因素崩潰是由于系統(tǒng)調用ftruncate()失敗引起的，是否意味著除了等待系統(tǒng)調用失敗之外什么也不能做？ 再來看一下-[MFMutableData _flushToDisk:capacity:]函數(shù)。
在[b]行中所見，檢查flush在調用ftruncate()之前標志是否為true。這意味著，如果可以將flush在第[a]行將標志設置為false ，則ftruncate()根本不會執(zhí)行。 如果有人在調用-[MFMutableData appendData:]之前調用-[MFMutableData setLength:](set flush to 0), ftruncate() won’t be executed due to flush==0)，將會得到類似的結果。 將此OOB Write與其他漏洞或控制內存布局的方法結合使用，可以遠程觸發(fā)此漏洞，例如，通過控制選擇器。
盡管這確實是一個應修補的漏洞，但我們懷疑它是由攻擊者試圖利用以下漏洞而觸發(fā)的。 第二個漏洞：MFMutable中的遠程堆溢出研究人員繼續(xù)調查可疑的遠程事件，并確定同一區(qū)域存在另一個漏洞。 回溯可以如下所示： -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- -[MFMutableData _mapMutableData] 在分析代碼流時，研究人員確定了以下內容：
易受攻擊的函數(shù)的偽代碼如下： 系統(tǒng)調用mmap失敗時，- [MFMutableData_mapMutableData:]調用函數(shù)MFMutableData__mapMutableData___block_invoke
偽代碼MFMutableData__mapMutableData___block_invoke如下，它分配了一個大小為8的堆內存，然后用分配內存替換data->bytes指針。
執(zhí)行-[MFMutableData _mapMutableData:]完之后，進程繼續(xù)執(zhí)行-[MFMutableData appendBytes:length:]，將數(shù)據(jù)復制到分配內存時導致堆溢出。 -[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是一個可預測的內存區(qū)域，因此可以利用此漏洞。 攻擊者無需耗盡內存的每一個最后一位就可以使mmap失敗，因為mmap需要一個連續(xù)的內存區(qū)域。 復現(xiàn)根據(jù)mmap操作說明，在MAP_ANON was specified and insufficient memory was available時mmap會失敗。 mmap失敗是正常情況，理想情況下，電子郵件夠大就不可避免地會發(fā)生。但是，可以使用其他可耗盡資源的技巧來觸發(fā)漏洞。這些技巧可以通過多方面，比如RTF和其他格式來實現(xiàn)。 可能影響可利用性的另一個重要因素是硬件規(guī)格：
較舊的設備具有較小的物理RAM和較小的虛擬內存空間，因此不必耗盡RAM的每一位來觸發(fā)此錯誤，當無法在可用虛擬內存中找到給定大小的連續(xù)內存空間時，mmap將失敗。 目前已經確定MacOS不會同時受到這兩個漏洞的攻擊。 在iOS 12中，觸發(fā)漏洞更容易，數(shù)據(jù)流傳輸是在同一過程中完成的，因為默認郵件應用程序（MobileMail）會處理更多的資源，從而耗盡了虛擬內存空間（尤其是UI）的分配渲染，而在iOS 13中，MobileMail將數(shù)據(jù)流傳遞到后臺進程maild。它把資源集中在解析電子郵件上，從而降低了虛擬內存空間意外用完的風險。 遠程復現(xiàn)由于MobileMail / maild并未明確設置電子郵件大小的最大限制，因此可以設置自定義電子郵件服務器并發(fā)送具有幾GB純文本的電子郵件。iOS MIME /消息庫在流傳輸數(shù)據(jù)時將數(shù)據(jù)平均分成大約0×100000字節(jié)，因此完全可以不下載整個電子郵件。 請注意，這只是如何觸發(fā)此漏洞的一個示例。攻擊者無需為了觸發(fā)此漏洞而發(fā)送此類電子郵件，使用多種方式，比如RTF或其他格式等技巧，可以使用標準大小的電子郵件實現(xiàn)相同的目標。 披露時間表
|
