歡迎來到 黑吧安全網 聚焦網絡安全前沿資訊,精華內容,交流技術心得!

盤點并分析2019年發現的Chromium IPC漏洞

來源:本站整理 作者:佚名 時間:2020-01-21 TAG: 我要投稿

一、概述
在本篇文章中,我們將深入對2019年新發現的Chromium IPC漏洞進行研究。我們將探討一些新的發現,以及來自更廣泛的安全研究領域的最新發現,期望能揭示Chrome IPC攻擊面中反復出現漏洞的成因。感謝Ned Williamson針對IPC接口與libprotobuf-mutator之間的模糊測試的研究,以及Mark Brand關于如何調用、如何從Javascript進行模糊測試方面的工作,這些研究成果共同證明,Chromium IPC攻擊面是導致許多漏洞的源頭。在我們本次的研究中,共涉及六個新漏洞,分別是:CVE-2019-13688(995964)、CVE-2019-5876(997190)、CVE-2019-13700(998431)、CVE-2019-13687(998548)、CVE-2019-13699(1001503)和CVE-2019-13695(1004730)。
所有這些漏洞均已披露,并且已經在2019年9月至10月之間的Chromium版本(M77、M78)中實現修復。這些漏洞的嚴重程度屬于高危,如果被攻擊者成功利用,將允許受感染的渲染器實現Chromium沙箱逃逸。
由于Chromium的安全問題在14周以后受到限制,并且關于漏洞的詳細信息可以公開找到,因此我在本文中將不會詳細介紹每個漏洞的詳細細節,而是向大家展現我是如何找到這些漏洞的,以及說明我如何利用CodeQL來幫助發現這些漏洞。
如果各位讀者對漏洞的詳情感興趣,大家可以前往Chromium網站的Issue頁面查看。除了ID為1001503的漏洞(CVE-2019-13699)以外,所有這些問題均是在CodeQL的幫助下通過人工代碼審計發現。
首先,我要介紹Chromium的沙箱模型,以及這些IPC問題的影響。之后,我將研究這種類型的幾個典型漏洞,并將其分為不同的類別。這樣的分類將幫助我集中精力去發現新的漏洞。
二、Chromium的多進程結構
Chromium的多進程體系結構已經在官方文檔中得到了充分的說明,因此在這里我只做簡要的介紹。Chromium瀏覽器在不同的進程中運行,每個進程都具有不同的特權,并負責不同的任務。這種架構不進位瀏覽器提供了更高的穩定性,例如:渲染器崩潰將不會影響瀏覽器或任何其他渲染器,并且還通過使用操作系統級的沙箱將沙箱應用于不同的進程,從而提供了更為精細的特權模型。不同的進程通過IPC消息相互通信,低特權進程可以通過發送IPC消息來請求高特權進程執行特定任務。
從安全的角度來看,有兩個主要的進程上下文:渲染器進程池和瀏覽器進程。渲染器進程池是一組低特權進程,其中運行v8和blink等等。通常,渲染器進程在所有Chromium進程中具有最低的特權,并且它們被大量沙箱化。通常情況下,渲染器進程中的遠程執行代碼漏洞需要與瀏覽器進程中的另一個漏洞共同利用,以實現沙箱逃逸。但是也有例外,例如,在Android上,Android binder進程和一些Android服務都可以在渲染器沙箱內部訪問,并且這些進程中的漏洞也可以用于沙箱逃逸,可以參考這里、這里和這里。另一個值得關注的例外是在2019年3月披露的漏洞,該漏洞允許渲染器直接利用Windows 7上win32k.sys內核驅動程序中的漏洞。
在本文中,我將重點介紹通過IPC通道觸發的漏洞。
三、Chromium IPC接口
在Chrome的進程之間,有兩種主要的IPC通道。一種是Mojo接口,這種方式較新且較為常見。另一種是一個舊IPC接口,該接口并不常見但是仍在使用。
3.1 Mojo接口
有關Mojo接口的詳細信息可以在這里找到。在本節中,我將重點放在代碼中如何表示接口,以及在哪里尋找接口,在這里不會過多地重復文檔中已有的內容。
Mojo接口在Chromium源代碼的.mojom文件中定義。在構建Chromium時,這些文件用于生成C++源代碼和JavaScript綁定。在構建后,可以在Chromium檢出的src/out/\
這些Mojo接口在瀏覽器進程中的實現主要位于content/browser目錄下。但是有一些例外,例如PaymentRequest接口就位于/src/components/payments中。
要使用JavaScript訪問這些接口,可以使用Mojo.bindInterface方法。例如,在Mark Brand的項目中,PaymentRequest接口的用法如下:
var payment_request = new payments.mojom.PaymentRequestPtr();
    Mojo.bindInterface(payments.mojom.PaymentRequest.name,
                       mojo.makeRequest(payment_request).handle);
其中,第一行創建了PaymentRequestPtr,它作為渲染器端的代理,可以綁定到在瀏覽器過程中實現的PaymentRequest。在第二行中,Mojo.bindInterface用于將payment_request綁定到在瀏覽器進程中運行的payments.mojom.PaymentRequest接口。之后,可以從JavaScript調用此接口定義的方法。例如:
      payment_request.init(
        payment_request_client,
        [],
        payment_details,
        payment_options);
這樣一來,將在PaymentRequest中調用init方法。
測試或模糊測試IPC接口的另一種方法,可以借助例如Fuzz Harness的小型單元測試來實現與之直接交互。例如,Ned Williamson編寫的AppCacheFuzzer使用libprotobuf-mutator創建IPC消息,直接對組件進行模糊測試。通常情況下,這要通過編寫針對目標組建的模糊工具來完成,在模糊工具中還要設置正確的環境,然后提供一個.proto文件進行定義,改文件定義了用于對接口進行模糊處理的消息。例如,對于AppCache,命令定義了mojo接口中公開的不同方法:
// Based on blink::mojom::AppCacheBackend and blink::mojom::AppCacheHost
// interfaces.
// See third_party/blink/public/mojom/appcache/appcache.mojom
message Command {
  oneof command {
    RegisterHost register_host = 1; //
對于每個命令,在另一條名稱相同的消息中定義了明確的使用方式:
message RegisterHost {
  required HostId host_id = 1; //

[1] [2] [3]  下一頁

【聲明】:黑吧安全網(http://www.650547.live)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。
  • 最新更新
    • 相關閱讀
      • 本類熱門
        • 最近下載
        安徽快3自由的百科 江苏11选5任十 上证指数如何开户 今日股票推荐短线个股推荐 广东快乐10分连图带线 吉林十一选五开奖结果查询 彩票软件app大全下载 广西快乐双彩开奖结果查询 青海11选五5开奖结果 吉林十一选五计划 天津11选5选号方法