'Safari與iMessage如何打破iPhone的安全“神話”'

▲圖片來源：BRITTANY HOSEA-SMALL/AFP/Getty Images

許多“果粉”對iPhone的忠實，都來自於對iOS優質體驗和安全性的信任。但，這個曾被公認為最安全的主流操作系統，在過去幾個月卻經歷了一波聲譽打擊：據黑客安全大會披露，攻擊者能夠在用戶沒有任何點擊操作的前提下完成六次足以劫持iPhone設備的無交互攻擊。此外，還有五種iOS漏洞利用鏈現身惡意網站，攻擊者已經藉此入侵了數十臺設備。零日漏洞經紀公司甚至抱怨稱，由於黑客大肆通過iOS攻擊攫取市場，他們手中的漏洞資源已經遭遇大幅貶值。

隨著iPhone 11的發佈，許多人又開始了新的擔憂：蘋果公司不能再單純地對已經曝光的個人安全漏洞加以修復，而應該真正自查iOS當中引發這些缺陷的更深層次問題。有長期關注iOS的安全研究人員稱，這意味著蘋果公司首先需要著眼於iPhone中的兩大內部要素：Safari與iMessage。

雖然兩個應用的漏洞只會為黑客提供指向iOS設備的初步立足點（攻擊者必須找到其它漏洞才能更深入地滲透至目標操作系統當中），但這些表面級別的漏洞仍在最近出現的一系列攻擊活動中發揮了重要作用。而蘋果公司，則拒絕對此發表任何評論。

獨立安全研究員Linus HenzeHenze在今年早些時候曾發佈過一項名為KeySteal的MacOS漏洞。他表示，“如果大家想要入侵iPhone，Safari與iMessage就是最好的入口。”他還在與其他iOS研究人員的討論中指出，iMessage以及WebKit（這款瀏覽器引擎不僅是Safari的基礎，同時也是所有iOS瀏覽器的基礎），蘋果公司一直把對內部代碼的信任度放在高於其他公司代碼的位置上，而這也正是問題的真正根源。Henze解釋稱，“相較於其他人提供的代碼，蘋果公司更信任自己的代碼。他們明顯不願接受自己的代碼也有bug這一事實。”

>>> WebKit中的發現

舉例來說，蘋果公司要求所有iOS網絡瀏覽器——包括Chrome、Firefox、Brave以及其它各類方案——都必須與Safari一樣以WebKit引擎為基礎。Henze表示：“這基本上相當於只允許各廠商為Safari開發擁有不同界面的同內核版本。”在他看來，蘋果之所以要求各類瀏覽器盡皆使用WebKit，是因為為了縮短處理時長，運行網站中JavaScript代碼時往往涉及複雜的即時編譯技術（JIT）。雖然在iOS設備上運行的程序往往需要由蘋果或者經過批准的開發商進行加密簽名，但瀏覽器的JIT速度優化則不在受審範圍之內。

由此帶來的結果就是，蘋果堅持只允許利用WebKit引擎處理那些不具備簽名的代碼。“他們明顯更信任自己的代碼。如果他們給Chrome開了特殊通道，那就得為所有其他瀏覽器開設特殊通道。”Henze指出。

根據安全研究人員們的想法，強制使用WebKit之所以會帶來麻煩，是因為蘋果的這套瀏覽器引擎在某些方面的安全性上不及Chrome等其他瀏覽器。安全廠商Ret2公司創始人Amy Burnett一直負責Chrome與WebKit開發方面的培訓，她表示，目前雖然不清楚這兩種瀏覽器哪一種更易受到攻擊，但Chrome的bug修復速度往往更快——這主要是因為谷歌公司一直在努力主動尋找並消除代碼中的安全漏洞，而且廣泛採用模糊測試等自動化技術。

此外，谷歌公司還為Chrome漏洞設立了Bug賞金計劃，用以激勵正義黑客們發現問題並上報問題。而蘋果方面除了通過WebKit給iOS引入安全隱患之外，再沒有其它任何保障性作為。Burnett指出，“大家可能會在這兩種瀏覽器當中找到類似的bug，但問題在於誰能夠搶先一步解決問題。谷歌在這方面似乎表現得更好。”她還補充稱，Chrome利用沙箱技術將瀏覽器與操作系統其餘部分隔離開來的做法，也起到了良好的效果。如我們所知，這種沙箱隔離出了名的難以繞過——門檻遠高於WebKit——因此Chrome中存在的任何漏洞可能都不足以幫助攻擊者進一步入侵操作系統中的其它組件。

>>> 引用風險

獨立安全研究員Luca Todesco表示，WebKit瀏覽器架構當中的另一個特殊元素也有可能引發潛在攻擊，這就是文檔對象模型WebCore。WebKit瀏覽器會利用WebCore進行網站渲染，而WebCore要求瀏覽器開發商追蹤會引用其它對象的數據“對象”（可能是一串文本，也可能是數據數組）。這一過程被稱為“引用計數”，一旦發生錯誤，某項引用就有可能指向這個缺失的對象。而黑客當然能夠利用自己選定的對象填補這個空白，這相當於一個間諜在會議登記表上填寫他人姓名。

相比之下，Chrome自己的WebCore版本當中包含了一項被稱為“垃圾收集器”的安全措施，能夠消除指向缺失對象的指針。如此一來，WebCore就不會錯誤地為這些對象保留未分配狀態並被攻擊者所利用。當然，WebKit也使用了一套被稱為“智能指針”的自動引用計數系統，但Todesco認為這仍不足以徹底消除隱患。他表示，“在WebCore當中可能發生很多情況，瀏覽器開發商必須跟蹤所有可能性，而這本身就是一項不可能完成的任務。”

為了“挽救”蘋果在安全方面的信譽，蘋果在過去一年多當中已經為iOS實施了一項重要的緩解措施，也就是“isoheaps”，也稱為「隔離堆」。其作用是確保引用計數中的錯誤無法被利用。對此，iPhone XS、XS Max以及XR的硬件漏洞得到了一定緩解。然而，Todesco與Burnett都注意到，雖然「隔離堆」機制大大提高了WebCore的安全性，但卻仍未能徹底阻斷對WebCore的攻擊，因為許多黑客會轉而攻擊WebKit的其它組件。Todesco表示，自2018年推出「隔離堆」機制以來，已出現多次對引用計數錯誤的利用活動。Ret2公司的Burnett也贊同稱，“看起來問題還是沒有真正得到解決。”

雖然存在諸多問題，WebKit的缺陷也確實一次又一次成為iOS攻擊的切入點，但WebKit本身的安全性是否顯著弱於Chrome還是存在爭議。在Zerodium（一家銷售零日黑客技術的公司）公佈的產品價格表上，明確列出了直接指向Chrome與Safari的攻擊方法。而另一家零日漏洞經紀商Maor Shwartz則在採訪中明確表示，由於WebKit的安全性確實要差於Chrome，所以目前Android漏洞的最高價格已經反超iOS。Shwartz強調稱，“Chrome是目前最安全的瀏覽器，漏洞的市場價格已經體現了這一點。”

>>> iMessage的問題

iMessage中的可利用漏洞要遠比WebKit更少，但這些漏洞的嚴重程度卻更高，因為黑客完全可以將此作為初始跳板，並在沒有用戶交互的前提下接管目標手機。就在上個月，谷歌Zero項目團隊研究員Natalie Silvanovich就展示了一系列令人稀奇的iMessage零日漏洞。事實證明，這些漏洞確實能夠實現對目標iPhone的遠程零點擊接管。

比這些bug更令人不安的是，它們全都源自相同的安全問題——即iMessage會向攻擊者公開其“反序列化器”。該組件負責對通過iMessage發來的各類數據進行解包。專注關注蘋果產品的安全廠商Jamf公司安全研究員Patrick Wardle對這個漏洞做出了這樣的描述——這就像是盲目打開一個裝滿組件的盒子，卻在沒有進行任何檢查的情況下馬上著手組裝。Wardle表示，“我們可以把炸彈的組件放在盒子裡。由於蘋果允許我們對所有對象進行反序列化，這無疑會帶來巨大的攻擊面。”

更重要的是，iMessage在iOS當中擁有一系列其它消息應用所不具備的天然特權。比如，非蘋果應用必須運行在嚴格的沙箱環境當中，從而與操作系統的其它組件彼此隔離。這意味著，如果像WhatsApp這樣的第三方應用程序遭到入侵，攻擊者還需要採取新的方式進一步突破沙箱，才能獲得對目標設備的深層控制。然而，iMessage中的某些易受攻擊的組件與SpringBoard集成，而後者屬於管理設備主屏幕的iOS程序。該程序根本就沒有自己的沙箱環境。

Linux Henze在評論iMessage時也說道：“我個人無法理解他們為什麼不全面採用沙箱化機制。他們應該假設自己的代碼也會有bug，並確保與其他應用程序採取同樣的沙箱保護措施，例如WhatsApp、Signal以及任何其他應用程序。”

蘋果之所以能夠為iPhone建立起良好的安全聲譽，靠的就是對在App Store上線的一切應用程序進行全面審查和嚴格隔離。