作者：菜絲@螞蟻安全實驗室
公衆號：螞蟻安全實驗室
1.前 言
相信讀者對 XSS 早已不陌生。通常談論 XSS 的時候大多是針對 Web 安全領域的攻防和利用，而在客戶端中也可能出現對輸入處理不當而造成的 XSS。螞蟻安全光年實驗室近日在 BlackHat EU 2020 上發表的議題 Cross-Site Escape: Pwning macOS Safari Sandbox the Unusual Way 就展示了一種針對 Safari 瀏覽器沙箱的繞過思路，將 Web 安全老生常談的攻擊方式移植到一個看上去毫不相干的領域，將進程間通信（IPC）的安全問題轉化成跨組件的 js 腳本注入，最後完全繞過瀏覽器沙箱獲得完整的代碼執行權限。
由於瀏覽器功能複雜、迭代迅速，很容易出現內存安全相關的漏洞，因此沙箱（sandbox）成爲了現代瀏覽器的標準配置。簡單來說就是把渲染引擎等邏輯裝進一個被“籠子”關起來的進程，即使攻擊者利用漏洞獲得了任意代碼執行，接下來仍然要做額外的工作從沙箱裏逃逸出來，才能真正訪問到有價值的信息。常規的沙箱逃逸多是利用進程間通信機制，或可訪問到的內核、驅動等組件，在權限更高的進程或者直接內核當中觸發其他內存安全問題，從而關閉沙箱或者啓動一個不受限制的進程，形成完整的攻擊鏈條（fullchain exploit）。
而我們的議題富有創意地在 XSS 的老樹上開出了新花，嫁接到沙箱逃逸的場景中實現了穩定的利用，而且完全避開當下系統針對內存安全漏洞所引入的各種緩解措施（mitigation）。因爲這些緩解措施並不是針對此類問題而設計的，兩者不在同一個戰場上。
2.跨進程 XSS？
通常 XSS 指的是通過 HTTP 協議等輸入向量，將惡意代碼（如 Javascript 或者 HTML 片段）注入到本不應該受攻擊者控制的站點內容當中，從而繞過同源策略（Same-Origin Policy）竊取用戶憑據的攻擊手法。這種攻擊可以追溯到二十世紀九十年代，常年雄踞 OWASP 的十大 Web 安全威脅榜單。
結合瀏覽器漏洞的場景，又有 UXSS（Universal XSS）的攻擊方式。XSS 通常出現在服務器後端或者網頁前端腳本，而 UXSS 主要基於客戶端瀏覽器（或擴展）的漏洞，從而篡改瀏覽器預定的行爲和繞過安全限制。通常在沒有啓用站點隔離（Site-Isolation，Chrome 的安全特性）的瀏覽器中，同一個渲染器進程可以同時處理多個域名，因此同源策略是在進程內通過特定的訪問控制策略保證的。
有時瀏覽器在處理特定的 DOM 或者網絡接口存在邏輯缺陷，可能導致不同站點的數據可以相互訪問，或注入腳本到不同的域名上下文中；有時特定的瀏覽器上下文配置會默認允許關閉同源策略檢測，例如 Android系統WebView可以使用 setAllowUniversalAccessFromFileURLs 等配置對 file 域開啓同源策略例外，對應的 iOS 下 UIWebView 則直接默認啓用了類似的策略，只要是 file:// 域下的頁面，一律不限制同源策略；而在出現了內存破壞漏洞，導致惡意網頁具有內存讀寫權限的前提下，攻擊者的腳本可以修改進程內的特定標誌位實現 UXSS。
在這篇議題當中借鑑了 XSS 注入 javascript 的思路，但輸入向量不是 Web 協議，而是本地進程之間的跨進程通信（IPC）。例如反射型 XSS 通常會將惡意的腳本或者 HTML 直接附在 GET 請求的 query string 當中，讓腳本在目標站點域執行；而類似的，本文的一些案例通過 XPC（macOS 和 iOS 下的進程通信）接口，從瀏覽器的沙箱進程內發起調用，誘導其他高權限系統服務渲染攻擊 HTML，從而在沒有沙箱限制的 WebView 裏運行惡意腳本，最終獲得完整權限的本地代碼執行（即沙箱逃逸）。和 UXSS 相比，雖然都是本地的攻擊，但 UXSS 仍然在進程內，而本文的思路則實現了跨進程、跨安全邊界的代碼注入。
以下表格簡單比較了這種攻擊的特點：
| XSS | 跨進程 js 注入 | |
|---|---|---|
| 輸入向量 | HTTP 協議 | 跨進程通信 |
| 對象 | 其他域名 | 高權限本地進程 |
| 載荷 | 提取登錄憑據或直接發起請求僞造 | 在高權限 WebView 執行本地代碼 |
| 最終目的 | 繞過同源策略 | 瀏覽器渲染器沙箱逃逸 |
因此這種攻擊的思路大體如下：
1.擁有一個完整的 WebKit 遠程代碼執行漏洞，用以觸發後續逃逸操作。
2.找到瀏覽器沙箱可以交互的系統服務，使用系統服務當中的邏輯缺陷向其他本地進程注入 js 代碼。
3.被注入 js 的進程和存在邏輯缺陷的系統服務不一定是同一個。
4.在高權限進程當中通過再次利用 WebKit 漏洞，甚至進程自身的特殊功能，獲得無沙箱限制的命令執行。
3.WebView
既然要在不同上下文當中運行 js 腳本，就得在高權限進程當中找到可以渲染 HTML 和執行 js 的地方。
macOS 上支持 HTML 渲染的組件非常多。像 Finder、Spotlight、Dictionary、HelpViewer、iBooks 甚至 iMessage 當中都用到了 WebView 組件。WebView 分爲兩種，歷史遺留（legacy）的 WebView 和 macOS 10.10 後引入的 WKWebView。前者不支持進程隔離（沒有 sandbox），不支持 JIT（即時編譯），在 SDK 中標記爲已廢棄。而 WKWebView 是目前推薦的嵌入 Web 內容的方式。因爲使用了多進程，從攻擊角度來說和 Safari 完全一致。
兩種 WebView 都提供了一些機制來實現 Objective-C 和 javascript 互相調用，但實現上不同。WKWebView 因爲用了 IPC，就只支持異步的 messageHandler 委託；歷史遺留的 WebView 則提供更強大的接口，可以直接把 Objective-C 的對象、方法暴露給 js，也支持同步調用。其實 WKWebView 提供了一種叫做 InjectedBundle 的機制，可以在渲染器進程裏直接加載二進制插件，從而暴露更多的 JSContext 功能。但由於系統簽名機制，沙箱進程 WebContent 不允許載入第三方簽名的模塊，因此只有 Apple 自己用到了這項功能，也沒有在開發者文檔中提到。
這些不是 Safari，本身又用到了 HTML 渲染的進程，便是本議題的攻擊目標。一些 WebView 使用的老式的接口，沒有進程隔離。假設我們有一個非 JIT 的瀏覽器漏洞，直接通過客戶端 xss 在這些 WebView 裏運行利用，即可獲得沒有限制的任意代碼執行；更有甚者，一些 WebView 本身向 js 暴露了接口，使得我們不需要重複使用 WebKit 的漏洞，而是簡單調用便可以執行任意本地代碼。
如果上面的描述讓人昏昏欲睡，話不多說，我們直接來看漏洞案例。
cfprefsd TOCTOU 沙箱逃逸
這個問題沒有分配 CVE。筆者在 10.13 上發現，但在當時的 10.14 開發者測試版上已經被修復了。復現很簡單：
-
在 macOS <= 10.13.6 系統上。
-
關閉 SIP，以便可以調試系統自帶應用。
-
附加到任意一個 WebContent 進程，輸入 po (id)CFPreferencesCopyAppValue(@"CFBundleGetInfoString", @"/Applications/Calculator.app/Contents/Info")。
-
靈異事件發生了。按照沙箱規則，這個路徑本該無法讀取，卻成功地返回了內容。不僅可以讀，換成寫操作也沒有問題。
漏洞成因在於 CoreFoundation 當中的一段邏輯問題。Preferences 系列 API 用來持久化程序偏好信息，通過 plist 格式將 Objective C 當中的數據類型和鍵值對等信息保存到路徑。但實際上對路徑的讀寫操作不是在進程內完成的，而是通過一個 cfprefsd 進程作爲代理，將讀寫操作使用 XPC 傳遞。cfprefsd 服務本身對讀寫操作有權限檢查，但問題出在沙箱的狀態的判定上。一個進程在訪問過 Preferences 之後，如果進程沒有 sandbox，那麼 cfprefsd 會對其做一個標記。在此之後，所有的權限檢查都會優先判斷這個標記。
void __cdecl ___CFPrefsMessageSenderIsSandboxed_block_invoke(Block_layout_1D3750 *block, _CFPrefsClientContext *ctx)
{
if ( ctx->_sandboxed != NULL ) {
*(*(block->lvar1 + 8) + 24) = ctx->_sandboxed == kCFBooleanTrue;
} else {
*(*(block->lvar1 + 8) + 24) = sandbox_check(block->pid, 0, SANDBOX_CHECK_NO_REPORT) != 0;
ctx->_sandboxed = *(*(block->lvar1 + 8) + 24LL) ? &kCFBooleanTrue : &kCFBooleanFalse;
}
}這就造成了一個 Time-of-check-time-of-use（TOCTOU）的問題。
在 mac 系統下，一個進程可以動態地給自身加上沙箱鎖定狀態。這個 API 是單向的，即進入沙箱之後就無法解除這個狀態（除非有內核漏洞）。假設一個進程先訪問了 Preferences，然後進入沙箱，此時在 cfprefsd 服務的眼裏，進程仍然是之前緩存的那個“沒有沙箱”的狀態，從而暢通無阻。
而 WebKit 的渲染器進程不巧在默認情況下就滿足這個條件。
在初始化階段，WebKit 不會加載任何第三方的內容，因此這時候不需要沙箱也是合理的。WebKit 當中引用到了一個 AppKit 的庫，這個庫在進程初始化的時候會讀取一些 Preferences 信息，也就在 cfprefsd 留下了訪問記錄。接着 WebKit 調用 sandbox_init_with_paramaters 進入鎖定狀態並加載網頁。這時候攻擊者通過渲染引擎漏洞獲得了在 sandbox 內執行任意代碼的能力，訪問 Preferences API。cfprefsd 仍然認爲渲染器是一個正常進程，允許讀寫任意路徑的 plist 文件，除非對應路徑需要 root 權限。
到這一步其實已經可以通過修改 plist 在 sandbox 外觸發代碼執行了。macOS 在開機時會加載 ~/Library/LaunchAgents 當中的啓動項，使用這個漏洞添加啓動項便可同時實現逃逸沙箱和持久化。但是缺點顯而易見，就是需要一次註銷或者重啓。
藉助跨進程 XSS，我們找到了一種立即執行任意命令的方法。
macOS 曾經有一個叫 Dashboard 的功能，在一個獨立的桌面上運行一些 HTML 編寫的小組件（widget）。這個功能在 10.15 當中被刪除，由桌面右側的“今天”視圖（Today Widgets）替代。
回到當時的系統中。
Dashboard Widgets 保存在如下路徑：
· /Library/Widgets 系統預裝
· ~/Library/Widgets 用戶下載安裝
一個 widget 是一個包（bundle），也就是帶有特定結構的目錄，目錄的擴展名爲 .wdgt。它由元數據 Info.plist、圖標和至少一個 HTML 文件作爲主體。WebContent 進程沙箱提供了一個可以寫入文件的臨時目錄，可以釋放一個完整的 wdgt 包。再通過前面提到的cfprefsd 漏洞篡改 com.apple.dashboard 域下的設置，從而讓 Dashboard 加載來自臨時路徑的惡意 widget，實現從 WebKit 沙箱到 Dashboard 的跨進程 xss。
Dashboard 的 WebView 是一個典型的遺留組件，沒有沙箱隔離，因此任何一個非 JIT 的漏洞都可以直接利用後拿到 shell。但當我們可以注入任意小插件的時候，事情變得更簡單了。在 .wdgt 的 Info.plist 當中有一個 AllowSystem 屬性，一旦設置爲 true，js 的上下文中便會提供一個 window.widget.system 的函數。顧名思義，就是執行任意系統命令：
window.onload = function () {
widget.onshow = function () {
widget.system('/usr/bin/open -a Calculator');
}
}接下來還有一些問題亟待解決。假如系統把 Dashboard 關閉了怎麼辦？還有在通過漏洞安裝了任意 widget 之後，如何才能激活代碼執行的事件？
通過分析 WebContent 沙箱，我們發現這樣一個系統服務允許訪問：
(global-name "com.apple.dock.server")這個 Dock 服務正好通過 MIG 提供了啓用 Dashboard 和切換桌面的功能。更方便的是，在 HIServices.framework 當中提供了一些私有函數，可以幫助構造併發送具體的 Mach Message。
使用如下兩行代碼便可以強制開啓 Dashboard（即使之前被系統設置禁用），然後模擬用戶手勢滑動到 Dashboard 的桌面：
CoreDockSetPreferences((__bridge CFDictionaryRef) @{@"enabledState" : @2});
CoreDockSendNotification(CFSTR("com.apple.dashboard.awake"));4.HelpViewer 的又一次陷落
這個案例的發現頗有一些喜劇色彩。
在距離 2019 年的天府杯還有一個多月，筆者突然發現 mac 10.15 開發者測試版中將準備好的沙箱逃逸漏洞的其中一環修補掉了（這個利用鏈條將在稍後分析），只能在極短時間內再爭取一個新的方案。
這時筆者盯上了 Project Zero 之前的一個經典案例 CVE-2017-2361。在 issue 1040 中，lokihardt 通過特殊的 URL scheme 打開本地預裝應用 HelpViewer，觸發一個反射型 xss，從而得到特權上下文中執行 Apple Script 的能力，只用一個 xss 實現了完整的遠程代碼執行。這個漏洞當時也由 redrain 獨立發現，被撞掉了。
既然時間所剩無幾，不如看看有沒有找到變種的機會。
Safari 在跳轉本地應用的時候需要彈窗確認。但通過逆向發現，瀏覽器內部維護了一個信任名單列表：
@"itms-books",@"itms-bookss", @"ibooks", @"macappstore", @"macappstores",
@"radr", @"radar", @"udoc", @"ts", @"st", @"x-radar", @"icloud-sharing",
@"help", @"x-apple-helpbasic" count:19];只要目標 URL 的 scheme 在其中，而且數字簽名來自 Apple，就不會詢問用戶而直接跳轉過去。其中的 x-apple-helpbasic 引起了筆者的注意。這個 URL 仍然鏈接到 HelpViewer，由函數 -[HVBasicURLHandler process:] 處理。
if ([url.scheme isEqualToString:@"x-apple-helpbasic"] &&
[url.host hasSuffix:@".apple.com"] &&
[HelpApplication
sharedApplication].isOnline)只要 URL 的域名滿足 *.apple.com，就會打開對應的 https 頁面。例如x-apple-helpbasic://www.apple.com/aaa，將訪問 https://www.apple.com/aaa
由於用到了加密，我們無法通過 Wi-Fi 劫持的方式篡改返回的內容，從而寄希望於真正意義上的 xss 或者 open redirection 問題。在找到這段代碼的時候距離比賽僅有不到一星期，憑着碰運氣的心態開始手工挖掘 Web 漏洞。
蘋果官網有一個叫 Apple web server notifications 的頁面，羅列了服務端相關的修復公告和致謝，包括具體的域名。這其實給前期的信息收集帶來了很大方便。運氣爆棚的是，筆者僅靠 Google Dork 和 F12 的原始辦法，不到一天時間便找到了一個符合要求的 DOM xss。
通過這個客戶端和服務端結合的問題，我們從瀏覽器直接跳轉到了 HelpViewer 應用當中。很可惜，正如這個 URL 名字所暗示的那樣，這是一個僅具備基本功能的界面，此前的 Apple Script 功能並不能使用。其實到這一步已經結束了，沙箱確實沒了。只要再來一個 DOM 瀏覽器漏洞，即可實現 fullchain exploit。
那麼邏輯的方式還有沒有做其他事的可能？
在 -[HVBasicWindowController webView:decidePolicyForNewWindowAction:request:newFrameName:decisionListener:] 裏，遇到無法處理的 URL，就會調用 -[NSWorkspace openURL:] 打開文件，也就相當於運行本地程序。很可惜一開始注入 xss 的頁面是 https:// 協議，按照 WebKit 的同源策略限制，是不允許直接跳轉到 file:/// 域下的，否則我們就可以直接將 location 指向 Calculator.app 直接運行計算器了。不過彈其他的 URL 沒有限制，例如 ssh:/// 可以打開一個終端應用嘗試連接遠程服務器。
另外在 HelpViewer 當中實現了數個 NSURLProtocol 的子類：
· HVHelpTopicsURLProtocol (x-help-topics:)
· HVHelpContentURLProtocol (apple-help-content:)
· HVHelpURLProtocol (help:)
請不要和之前提到的應用跳轉 URL 混淆。雖然都是 help: 開頭，但這裏的 URL 是用來處理資源加載，調用對應的 URLProtocol 類當中的方法，將 HTTP 響應內容替換成自定義的返回值。在方法 -[HVHelpURLProtocol startLoading] 當中，會將 URL 的 pathname 轉換成本地的路徑，直接讀取文件進行返回。例如 help://anything/etc/passwd 會替換成對 /etc/passwd 的訪問。
之前提到我們不能跳轉到 file:/// 域下，而 help:// 就沒有這個限制。可以結合其他條件，讓 macOS 將遠程文件掛在到一個本地可預測的路徑，通過訪問這個 help://anything/some/path.html，即可獲得全盤文件讀取的能力。在 macOS <= 10.14 的系統上可以用 /net/hostname/pathname 這樣的路徑自動掛載遠程服務器上的 NFS，完成利用。正是因爲這個特性的安全風險，mac 在 10.15 之後默認註釋掉了 /etc/auto_master 當中掛載 NFS 的能力。
筆者做了另一種嘗試。之前提到這個 WebView 可以不受限制地打開除 file:/// 之外的本地 URL scheme，可以使用 smb://user:passwd@host/path 讓 Finder 加載一個遠程 samba 資源。假設成功後，會使用 /Volumes/path 作爲掛載點，也就完成了從 https:// 到 help:// 域的轉換，從而讀取全盤本地文件。不過實際操作過程中 Finder 會彈出一個確認框詢問是否打開 samba 路徑，需要一次額外的用戶確認。
還是直接 DOM RCE 好使……
5.Dictionary XSS 到命令執行
mac 系統有一個自帶的詞典應用，詞條的界面實際上是基於 WebView 渲染的 HTML。通常情況下 Dictionary 不會隨意加載第三方網頁，除了這一次。這一串漏洞利用便是前文提到的，在天府杯前兩個月被修補掉的問題。
在 Safari 的沙箱配置文件中有這樣一個服務：
(global-name "com.apple.mobileassetd")服務訪問的對象是 mobileassetd 進程。其實除了系統軟件版本更新之外，一些資源文件（assets）會定期從 apple 官方網站通過 OTA 的方式更新。這些文件存在 /System/Library/Assets(V2?) 目錄下，通常受到 SIP 保護，即使有 root 權限也無法修改，只有 mobileassetd 等特殊權限的進程纔可以更新。這類資源包括詞典、字體等不可執行的文件，訪問它們要用到私有 API 框架 MobileAsset 當中的 ASAssetQuery 和 ASAsset 類。
首先我們創造一個查詢實例，獲得其 results 數組，當中便是所有的 ASAsset 對象：
const static NSString *kVictim = @"com.apple.dictionary.AppleDictionary";
[[ASAssetQuery alloc] initWithAssetType:kType];
[query runQueryAndReturnError:&err];
NSArray *results = [query results];通過修改 ASAsset 對象的如下屬性，並執行其 beginDownloadWithOptions: 方法，可以誘導 mobileassetd 從任意網址下載資源並替換本地的文件：
· __BaseURL
· __RelativePath
· __RemoteURL
· _DownloadSize（壓縮包的大小）
· _UnarchivedSize（解壓後的大小）
· _Measurement（校驗值）
到這一步我們正好可以在 Safari 的沙箱內通過強制 OTA 的方式，讓系統下載任意的詞典資源，我們便有機會向 Dictionary.app 當中注入任意 js 代碼了。
來看看 Dictionary 裏可以幹什麼。
a = document.createElement('a');
a.href = 'file:///Applications/Calculator.app';
a.click()
這一段代碼匪夷所思地可以從 Dictionary 的 WebView 裏直接運行計算器。而 location 賦值跳轉的方式並不起作用，爲什麼？
讓我們來到這個函數 -[DictionaryController webView:decidePolicyForNavigationAction:request:frame:decisionListener:]:
element = action[WebActionElementKey];
url = element[WebElementLinkURLKey];
if (!url)
url = action[WebActionOriginalURLKey];
...
[[NSWorkspace sharedWorkspace] openURL:url];這個方法處理 WebView 的跳轉事件，真對 WebActionElementKey 的情況來取出 URL，最後用 -[NSWorkspace openURL:] 方法執行本地應用，也就是隻處理了表單提交、鏈接點擊等事件，而不管 location 的跳轉。如果只熟悉 XSS，而不對程序進行逆向，就可能錯過這個點。
再看前面 mobileassetd 的漏洞可以在後臺下載解壓任意文件。一個很有利的點在於，通過 OTA 方式下載的文件和瀏覽器下載不同，不會給文件打上“來自 Internet”的標記。假如裏面包含可執行的應用，運行的時候不會觸發 GateKeeper 檢查，直接運行。因此直接編譯一個可執行的 .app 文件包含在詞典的包當中，再通過這個跳轉漏洞直接打開即可繞過沙箱執行任意命令。
在 macOS 10.15 開發者測試版上，這個打開 URL 的操作被修復過了，只有 http 和 https URL 纔會允許打開，也導致了我們之前的利用代碼栽在了最後一步命令執行上。假設仍然在 10.14 存在問題的版本，這中間顯然還有一段缺口沒解決。我們可以在沙箱裏任意下載替換詞典，那麼怎麼樣纔可以從瀏覽器沙箱裏直接打開詞典？
雖然 dict:///apple 的 URL scheme 可以直接跳轉到某個詞條，但 dict: 不在我們前文提到的信任名單中，瀏覽器會詢問用戶。這時候就要請出一個小功能的幫忙了。
如圖所示，mac 下的瀏覽器可以直接通過 ForceTouch 的方式打開一個浮動窗口，就是一個精簡版的 Dictionary 界面。這個界面來自 LookupViewService 進程，也是一個 WebView。
通過閱讀 WebView 的源代碼，筆者找到一個叫做 WebKit::WebPage::performDictionaryLookupOfCurrentSelection() 的方法。這個方法可以在 WebProcess（沙箱中）通過 WebKit 內置的進程間通信發送給主進程，接着主進程就會打開 LookupViewService 界面載入指定單詞的解釋。這個過程不需要用戶確認，因此我們獲得了第一個跨進程 XSS。
在 LookupViewService 中注入任意 js 代碼之後，通過一行簡單的 location 跳轉即可打開 Dictionary，觸發第二次跨進程 XSS：
location = "dict://ExploitStage2"這時用前文提到的漏洞執行詞典當中包含的惡意 app 即可。
有趣的是，在這個漏洞鏈條當中用到的三個中間進程——mobileassetd、LookupViewService 和 Dictionary.app 全都是有各自的沙箱的。這又得說到 NSWorkspace 啓動進程的特點上。通過 openURL 這種方式運行的 app，最後會調用 LaunchService，啓動出來的應用和調用者並不存在父進程子進程的關係，也不會繼承前者的 sandbox profile，只要求調用者有 lsopen 權限。而 Dictionary.app 正好滿足。
這個 MobileAsset 的漏洞還有一個神奇的副作用。在 mac 上這個 XSS 影響本地的詞典應用，而在 iOS 上問題同樣存在。在覆蓋了本地詞典之後，被攻擊的 iPhone 在桌面上查詢英文單詞的定義時，會在 SpringBoard 進程裏打開一個詞典界面。
由於這個界面所在的進程 SpringBoard 沒有沙箱，而且使用到了 UIWebView 進行網頁渲染，可以導致惡意腳本可以無限制地使用絕對路徑讀取本地文件並上傳，例如相冊和所有的聯繫人、通話記錄和短信。此外，只要有不涉及到 JIT 的 WebKit 瀏覽器引擎漏洞，攻擊者便可以獲得沙箱外完整的代碼執行權限。這是一個潛在的持久化攻擊向量。
我們把這個問題作爲附加分析一同報告給了蘋果，在 iOS 12 之後換成了更安全的 WKWebView。
6.總 結
本議題提出了一種特殊的思路來完成 Safari 瀏覽器沙箱逃逸，將大家熟悉不過的 XSS 從 Web 領域遷移到跨進程通信的場景上，得到了“老樹開新花”的效果。結合其他瀏覽器渲染引擎漏洞，可實現全鏈路的利用。
相比流行的思路，純邏輯漏洞可以獲得百發百中的穩定性，以及完全無視針對內存安全問題設計的各種緩解措施。不過，這些漏洞雖然都可以完美利用，但由於涉及跨 App 的跳轉等操作，會出現肉眼可感知的現象，對攻擊者而言不是最理想的方案。
本文也帶來了一些啓示。對於開發維護者，歷史遺留組件可能拖累整個系統的安全性。如何在保證系統可用性的同時，儘可能地拋棄歷史包袱，是一個需要考慮的問題。而對於攻擊者來說，跨組件之間小問題的有機結合常常會帶來讓人意想不到的效果。
關於作者
螞蟻安全光年實驗室隸屬於螞蟻安全九大實驗室之一，通過對基礎軟件及設備的安全研究，達到全球頂尖破解能力，致力於保障螞蟻集團及行業金融級基礎設施安全。 因發現並報告行業系統漏洞，螞蟻安全光年實驗室上百次獲得Google、Apple等國際廠商致謝。
本文由 Seebug Paper 發佈，如需轉載請註明來源。本文地址：https://paper.seebug.org/1453/