摘要：緩存攻擊是和個人電腦相關(guān)的一種邊信道攻擊，因為高速緩沖區(qū)被不同的進程和用戶使用而導致了信息的泄露。報告中的攻擊方式因此是高度可行的對于攻擊者的假設和限定是實際的運行的時間是實際的給攻擊者帶來的好處也是實際的。

原文 The Spy in the Sandbox – Practical Cache Attacks in Javascript
相關(guān)論文可在 https://github.com/wyvernnot/cache_attack_in_javascript 下載

  
作者和單位
  
  
Yossef Oren (yos AT cs.columbia.edu)
  
Vasileios P. Kemerlis (vpk AT cs.columbia.edu)
  
Simha Sethumadhavan (simha AT cs.columbia.edu)
  
Angelos D. Keromytis (angelos AT cs.columbia.edu)
  
哥倫比亞大學計算機系

我們將展示首個完全運行在瀏覽器里的針對微架構(gòu)的邊信道攻擊手段。與這個領(lǐng)域里的其它研究成果不同，這一手段不需要攻擊者在受害者的電腦上安裝任何的 應用程序來展開攻擊，受害者只需要打開一個由攻擊者控制的惡意網(wǎng)頁。這種攻擊模型可伸縮性高，易行，貼近當今的網(wǎng)絡環(huán)境，特別是由于絕大多數(shù)桌面瀏覽器連接到 Internet 因此幾乎無法防御。這種攻擊手段基于 Yarom 等人在 文[23] 提出的 LLC攻擊，可以讓攻擊者遠程獲得屬于其它進程、用戶甚至是虛擬機的信息， 只要它們和受害者的瀏覽器運行在運行在同一臺物理主機上。我們將闡述這種攻擊背后的基本原理，然后用一種高帶寬的隱藏通道驗證它的效果，最后 用它打造了一個覆蓋整個系統(tǒng)的鼠標和網(wǎng)絡活動記錄器。抵御這種攻擊是可能的，但是所需的反制措施對瀏覽器和電腦的正常使用所產(chǎn)生的代價有點不實際。

邊信道分析是里一種非常強大的密碼分析攻擊。攻擊者通過分析安全設備內(nèi)部在進行安全運算時所產(chǎn)生的的物理信號（功率，輻射，熱量等）來取得秘密信息[15]。 據(jù)說在二戰(zhàn)中便有情報部門在使用，Kocher 等人在1996年首次在學術(shù)情境下討論了這個問題[14]。邊信道分析被證實可以用來侵入無數(shù)的現(xiàn)實世界中的系統(tǒng)，從汽車報警器 到高安全性的密碼協(xié)處理器[8][18]。緩存攻擊（Cache Attack）是和個人電腦相關(guān)的一種邊信道攻擊，因為高速緩沖區(qū)被不同的進程和用戶使用而導致了信息的泄露[17][11]。

雖然邊信道攻擊的能力無可置疑，但是要實際應用到系統(tǒng)上還是相對受限的。影響邊信道攻擊可行性的一個主要因素是對不確定的攻擊模型的假設：除了基于網(wǎng)絡的 時序攻擊，大部分的邊信道攻擊都要求攻擊者非常接近受害者。緩存攻擊一般會假設攻擊者能夠在受害者的機器上執(zhí)行任意的二進制的代碼。雖然這個假設 適用于像 Amazon 云計算平臺這樣的 IaaS 或者 PaaS 環(huán)境，但是對于其它環(huán)境就不那么貼切了。

在這篇報告里，我們用一種約束更少、更可行的攻擊者模型挑戰(zhàn)了這一限制性的安全假設。在我們的攻擊模型里，受害者只需要訪問一個網(wǎng)頁，這個網(wǎng)頁 由攻擊者所擁有。我們會展示，即使在這么簡單的攻擊者模型里，攻擊者依然能夠在可行的時間周期里，從被攻擊的系統(tǒng)中提取出有意義的信息。為了和這樣的 計算設定保持一致，我們把注意力集中在了跟蹤用戶行為而不是獲取密匙上。報告中的攻擊方式因此是高度可行的：對于攻擊者的假設和限定是 實際的；運行的時間是實際的；給攻擊者帶來的好處也是實際的。據(jù)我們了解，這是首個可以輕松擴展至上百萬個目標的邊信道攻擊方式。

我們假設攻擊中受害者使用的個人電腦配備有較新型號的的 Intel CPU ，并進一步假設用戶用支持 HTML5 的瀏覽器訪問網(wǎng)頁。這覆蓋了絕大部分連接到 Internet 的 個人電腦，見 章節(jié)5.1 。用戶被強迫訪問一個頁面，這個頁面上有一個由攻擊者控制的元素比如廣告。攻擊代碼自己會執(zhí)行基于 JavaScript 的 緩存攻擊，見 章節(jié)2，持續(xù)地訪問被攻擊系統(tǒng)的 LLC 。因為所有的 CPU 內(nèi)核，用戶，進程，保護環(huán)等共享同一個高速緩存區(qū)，所以可為攻擊者提供被攻擊用戶和系統(tǒng)的詳細信息。

現(xiàn)代的計算機系統(tǒng)通常會采用一個高速的中央處理器（CPU）和一個容量大但是速度較慢的隨機存取器（RAM）。為了克服這兩個模塊的性能鴻溝，現(xiàn)代的計算機系統(tǒng)會采用 高速緩存 - 一種容量小但是速度更快的內(nèi)存結(jié)構(gòu)，里面保存了 RAM 中最近被 CPU 訪問過的子集。高速緩存通常會采用** 分層** 設計，即在CPU 和 RAM之間 分層 放置一些列逐漸變大和變慢的內(nèi)存結(jié)構(gòu)。圖1 取自 文[22]，展示了 Intel Ivy Bridge 的緩存結(jié)構(gòu)，包括：較小的 level 1(L1) cache，大一些的** level 2 (L2) cache ，最下方是最大的 **level 3 (L3) cache 并和 RAM 相連。Intel 目前代號為 Haswell 的新一代 CPU 采用了另一種嵌入式的 DRAM(eDRAM) 設計，所以不在本文討論范圍內(nèi)。如果 CPU 需要訪問的數(shù)據(jù)當前不在緩存里，會觸發(fā)一個 未命中 ，當前緩存里的一項必須被 **淘汰 **來給新元素騰出空間。

圖1：Intel Ivy Bridge

Intel 的緩存微架構(gòu)是 **嵌套的 **- 所有一級緩存里的數(shù)據(jù)必須同時存在二級和三級緩存里。倒過來，如果某個元素在三級緩存里被淘汰，那它也會立刻被 從二級和一級緩存里移走。需要注意的是 AMD 緩存微架構(gòu)的設計是非嵌套的，所以本文描述的方法并不能立刻應用到該平臺上。

本文重點關(guān)注第三級緩存，通常也被稱為 LLC。由于 LLC 較大，CPU 訪問內(nèi)存的時候如果把整個 LLC 的內(nèi)容都搜索一遍效率會很低。 為了避免這個問題，LLC 通常被分成不同的 組，每一組都對應者內(nèi)存空間的一個固定的子集。每個組包含若干緩存線。例如，Intel Haswell 系列中的 Core i7-3720QM 處理器擁有 8192 = 2^13 個組，每個組有 12 條 64 = 2^6 字節(jié)的緩存線，共同組成 8192 x 12 x 64 = 6 MB 的高速緩存。 CPU 如果要檢查一個給定的物理地址是否在三級緩存里，會先計算出組，然后只檢查組內(nèi)的緩存線。結(jié)果就是，某個物理地址的緩存未命中，會導致同一個組的 為數(shù)不多的緩存線中的一條被淘汰，這個事實會被我們的攻擊反復運用。由64比特長度的物理地址到13比特長度的組索引的映射方法已經(jīng)被 Hund 等人在2013年 通過逆向工程得出來[12]。在表示物理地址的64個比特位里，5到0被忽略，16到6被直接用來作為組索引的低11位，63到17散列后得到組索引的高2位。 LLC 被所有的內(nèi)核、線程、進程、用戶，乃至運行在同一塊 CPU 芯片上的虛擬機所共享，而不論特權(quán)環(huán)或其它類似的保護措施。

現(xiàn)代的個人電腦采用了一種 虛擬內(nèi)存機制，在這種機制里，用戶進程一般無法直接得到或訪問系統(tǒng)的物理內(nèi)存。取而代之的是，進程會被分配不同的虛擬內(nèi)存頁。 如果某個虛擬內(nèi)存頁被當前執(zhí)行的進程訪問，操作系統(tǒng)會在物理內(nèi)存里動態(tài)地分配一個頁框。CPU 的內(nèi)存管理單元（MMU）負責把不同進程對虛擬內(nèi)存地址的訪問 映射到物理內(nèi)存。Intel 處理器的頁和頁框大小一般是4KB，并且頁和頁框的是按照頁對齊的 - 每頁的開始地址是頁大小的倍數(shù)。這意味著，任何虛擬地址 的低12位和對應的虛擬地址是一一對應的，這一事實也在我們的攻擊中用到。

緩存攻擊是針對微架構(gòu)的攻擊手段中一個典型的代表， Aciamez 在他的出色的調(diào)查中將這類攻擊定義為利用 “信任架構(gòu)邊界下方的底層處理器結(jié)構(gòu)” 從不同的安全系統(tǒng)中 獲取秘密信息。緩存攻擊基于這樣的事實：盡管在上層有諸多像沙箱、虛擬內(nèi)存、特權(quán)環(huán)，宿主這樣的保障機制，安全和不安全進程通過高速緩存區(qū)的共用可以互相影響。 攻擊者構(gòu)造一個“間諜”進程后可以通過被共用的緩存來測量和干擾其它安全進程的內(nèi)部狀態(tài)。Hu 在1992年的首次發(fā)現(xiàn)[11]，在隨后的一些研究成果里顯示了邊信道攻擊可被用來獲取 AES密匙[17][4]，RSA密匙[19]，甚至可以允許一臺虛擬機侵入宿主上的其它機器。

我們的攻擊建立在 填充+探測 模型的基礎上，這個方法由 Osvik 在[17]中首次描述，不過是針對一級緩存的。之后由 Yarom 等人在[23]中擴展到啟用了 較大內(nèi)存頁系統(tǒng)的 LLC。我們把這個方法擴展了一下支持更加常見的 4K 的頁大小?？偟膩碚f，填充+探測有四個步驟。第一步，攻擊者建立一個 或多個** 移除集。移除集是內(nèi)存中的一系列地址，這些地址被訪問的時候會占據(jù)受害者進程使用的一條緩存線。第二步，攻擊者通過訪問移除集填充整個組。 這會強制受害者的代碼或指令被從組中淘汰，并使組進入一個已知的狀態(tài)。第三步，攻擊者觸發(fā)或只是等待受害者執(zhí)行和可能使用組。最后，攻擊者通過再次訪問移除集來探測**組。如果訪問的延遲比較低，意味著攻擊者的指令或數(shù)據(jù)還在緩存里。否則，較高的訪問延遲意味著受害者的代碼用到了組，因此攻擊者可以了解受害者的內(nèi)部狀態(tài)。 實際的時間測量是用非特權(quán)的匯編指令RDTSC進行的，這個指令可以得到處理器非常準確的周期數(shù)。再次遍歷鏈表還有第二個目的，那就是強制組進入 受攻擊者控制的狀態(tài)，為下一輪的測量做好準備。

JavaScript 是一種擁有動態(tài)類型，基于對象的運行時求值的腳本語言，它支撐著現(xiàn)代互聯(lián)網(wǎng)的客戶端。JavaScript 代碼以源碼的形式傳到瀏覽器端，由瀏覽器 即時編譯(JIT) 機制來編譯和優(yōu)化。不同瀏覽器廠商之間的激烈競爭使不斷改進 JavaScript 性能備受關(guān)注。結(jié)果就是，在某些場景下，JavaScript 執(zhí)行的效率已經(jīng) 可以和機器語言相媲美。

JavaScript 語言的核心功能是由 ECMA 產(chǎn)業(yè)協(xié)會在 ECMA-262 標準中定義的。語言標準由萬維網(wǎng)協(xié)會（W3C）定義的一系 API 所補充，因此適合開發(fā) Web 內(nèi)容。 JavaScript API 的集合是不斷演進的，瀏覽器廠商依照自己的開發(fā)計劃不斷增加新的 API 支持。我們的工作中用到兩個具體的API: 第一個是類型數(shù)組的定義9，通過它可以高效地訪問非結(jié)構(gòu)化的二進制數(shù)組。 第二個是高精度時間API16，讓應用程序可以進行毫秒以下時間的測量。 如 章節(jié)5.1 所示，大部分當今主流的瀏覽器都同時支持這兩個API。

JavaScript 代碼運行在高度沙箱化的環(huán)境里 - 用 JavaScript 交付的代碼對系統(tǒng)的訪問非常受限。例如，JavaScript 代碼如果沒有用戶的允許不能打開和讀取文件。 JavaScript 代碼不能執(zhí)行機器語言或者加載本地的代碼庫。 最值得注意的是，JavaScript 代碼沒有指針的概念，所以你連一個 JavaScript 變量虛擬地址都沒法知道。

我們的目的是構(gòu)造一個可以通過 Web 部署的 LLC 攻擊。這個過程是充滿挑戰(zhàn)的，因為 JavaScript 代碼沒法加載共享庫或者執(zhí)行本機語言的程序， 并且由于無法直接調(diào)用專用的匯編指令而被迫調(diào)用腳本語言的函數(shù)進行時間的測量。盡管有這些挑戰(zhàn)，我們還是成功地把緩存攻擊擴展到了基于 Web 環(huán)境：

  
我們展示了一種用來在 LLC 上的建立 非典型移除集 特別方法。與[23]不同，我們的方法不要求系統(tǒng)配置成支持較大的內(nèi)存頁，所以能夠很快的 應用到廣泛的桌面和服務器系統(tǒng)。我們展示了該方法雖然是使用 JavaScript 實現(xiàn)的，但是依然可以在實際的時間周期里完成。
  

  
我們展示了一種 功能完善的用無需特權(quán)的 JavaScript 發(fā)動 LLC 攻擊 的方法。我們用隱藏通道的方式，評估了它的性能，包括在同一個機器、不同進程之間 和在虛擬機與它的主機之間。基于 JavaScript 的通道與[23]中用機器語言實現(xiàn)的方法類似，都可以達到每秒幾百 kb 的速度。
  

  
我們展示了怎么利用基于緩存的方法來有效地跟蹤用戶行為。緩存攻擊的這一應用與我們的攻擊模型更相關(guān)，這與密碼分析在其它成果中的應用不同。
  

  
最后，我們分析了針對攻擊可能的反制措施和整個系統(tǒng)的代價。
  

文檔結(jié)構(gòu)： 第二章，攻擊方法不同階段的設計與實現(xiàn)。 第三章，基于攻擊方法建立起來的隱藏通道，這個通道也被用來驗證方法的性能。 第四章，緩存攻擊如何被用來跟蹤用戶在瀏覽器內(nèi)外的行為。 第五章，總結(jié)，提出反制措施和仍未解決的研究挑戰(zhàn)。

正如前文所訴，一次成功的 填充+探測 攻擊包含幾個步驟：為一個或多個相關(guān)組建立移除集，填充緩存，觸發(fā)受害者的操作，最后再次探測組。 雖然填充和探測實現(xiàn)起來很簡單，但是要找到對應于某個系統(tǒng)操作的組并且為它建立移除集就不那么容易了。在本章里，我們描述了這幾個步驟用 JavaScript 如何實現(xiàn)。

正如[23]寫到，填充+探測攻擊方法的第一步是為某個與被攻擊進程共享的組建立一個移除集。這個移除集包含一系列的變量，而且這些變量都被 CPU 映射到相同的 組里。根據(jù) 文[20] 的建議，使用鏈表可以避免 CPU 的內(nèi)存預讀和流水線優(yōu)化。我們首先展示如何為任意一個組建立一個移除集，然后解決尋找與受害者共享組的問題。

文[17]指出，一級緩存是依據(jù)虛擬地址的低位的比特來決定組分配的。假設攻擊者知道變量的虛擬地址，那么在基于一級緩存的攻擊模型里建立移除集很容易。 但是，LLC 里變量的組分配是依照物理內(nèi)存的地址進行的，而且一般情況下，非特權(quán)進程無法知道。文[23]的作者為了規(guī)避這個問題，假設系統(tǒng)用的是 頁較大的模型，在這個模型里，物理地址和虛擬地址的低21位是相同的，并通過迭代算法來獲得組索引的高位。

在我們所考慮的攻擊模型里，系統(tǒng)運行在 4K 的頁大小模型下，物理地址和虛擬地址只有最低的12位是相同的。然而更大的難題是，JavaScript沒有指針的概念， 所以即使是自己定義的變量，虛擬地址也是不知道的。

從64位物理地址到13位的組索引的映射關(guān)系已經(jīng)被 Hund 等人研究過[12]。他們發(fā)現(xiàn)，當訪問物理內(nèi)存里一段連續(xù)的、8MB大小的 “淘汰緩沖區(qū)” 時會讓三級緩存里的所有組 都失效。雖然我們在用戶態(tài)下沒有辦法分配這樣的一個“淘汰緩沖區(qū)” （實際上，文章[12]是通過內(nèi)核模式的驅(qū)動實現(xiàn)的），我們用 JavaScript 在 虛擬內(nèi)存里分配了一個 8MB 大小的數(shù)組（這其實是由系統(tǒng)分配的隨機、不連續(xù)的 4K 大小物理內(nèi)存頁的集合），然后測量遍歷這個緩沖區(qū)在全系統(tǒng)造成的影響。 我們發(fā)現(xiàn)在迭代訪問了這個淘汰緩沖區(qū)后如果立即訪問內(nèi)存中其它不相關(guān)的變量，訪問的延遲會顯著的增加。 另外一個發(fā)現(xiàn)是，即使不訪問整個緩沖區(qū)而是每隔64字節(jié)去訪問它，這個現(xiàn)象依然存在。但是，我們所訪問的 131K 個偏移值到8192個可能的組的映射關(guān)系 并沒有立刻清晰起來，因為我們不知道緩沖區(qū)里各個頁在物理內(nèi)存中的地址。

解決這個問題一個不太靠譜的做法是，給定一個任意的“受害者”在內(nèi)存中的地址，通過暴力手段從 131K 個偏移值中找到12個與這個地址共享組的地址。要完成這點， 我們可以從 131K 個偏移量中選取幾個作為子集，在迭代了所有的偏移量后再測量下訪問的延遲有沒有變化。如果延遲增加了，意味著含有12個地址的子集與 受害者地址共享相同的組。如果延遲沒有變化，那子集里的12個地址中的任何一個都不在組里，這樣受害者地址就還在緩存里。把這個過程重復8192遍，每次用 一個不同的受害者地址，我們就可以識別每個組并且建立自己的數(shù)據(jù)結(jié)構(gòu)。

受此啟發(fā)而立刻寫出來的程序會運行非常長的時間。幸運的是， Intel MMU 的頁幀大?。ㄕ鹿?jié)1.1）非常有幫助，因為虛擬地址是頁對齊的，每個虛擬地址的 低12位和每個物理地址的低12位是一致的。據(jù) Hund 等人所稱，12個比特中的6個被用來唯一決定組索引。因此，淘汰緩沖區(qū)中的一個偏移會和其它 8K 個偏移 共享12到6位，而不是所有 131K 個。此外，只要找到一個組就能立刻知道其它的63個在相同頁幀里的組的位置。再加上 JavaScript 分配大的數(shù)據(jù)緩存區(qū)的時是 和頁幀的邊界對齊的，所以可以用算法1中的貪心算法。

算法1 Profiling a cache set Let S be the set of unmapped pages, and address x be an arbitrary page-aligned address in memory

    1. Repeat k times:
    (a) Iteratively access all members of S
    (b) Measure t1 , the time it takes to access x
    (c) Select a random page s from S and remove it
    (d) Iteratively access all members of Ss
    (e) Measure t2 , the time it takes to access x
    (f) If removing page s caused the memory access to speed up          considerably (i.e., t1 ? t2 > thres),
    then this page is part of the same set as x. Place it back into      S.
    (g) If removing page s did not cause memory access to speed up       considerably,
    then this address is not part of the same set as x.
    2. If |S| = 12, return S. Otherwise report failure.

通過多次運行 算法1，我們可以逐漸的建立一個移除集并覆蓋大部分的緩存，除了那些被 JavaScript 運行時本身所使用的。我們注意到， 與[23]中的算法建立的淘汰緩沖區(qū)不同，我們的移除集是非典型的 - 因為 JavaScript 沒有指針的概念，所以如果我們發(fā)現(xiàn)了一個移除集 我們并沒有辦法知道它對應著 CPU 高速緩存的哪個組。此外，在相同的機器上每次運行這個算法都會得到不同的映射。這也許是因為用了傳統(tǒng)的 4K 頁大小 而不是 2MB 的頁大小的原因，這個問題即使不用 JavaScript 用機器語言也存在。

我們用 JavaScript 實現(xiàn)了 算法1 并且在安裝了 Ivy Bridge， Sandy Bridge，Haswell 系列 CPU 的機器上進行驗證，機器上裝有 Safari 和 Firefox 對應運行在 Mac OS Yosemite 和 Ubuntu 14.04 LTS 操作系統(tǒng)上。系統(tǒng)并沒有被配置使用大的頁而是用默認的 4K 頁大小。列表1 顯示了實現(xiàn) 算法1.d 和 算法1.e 的代碼，展示了 JavaScript 下怎么遍歷鏈表和測量時間。算法如果要運行在 Chrome 和 Internet Explorer 下，需要額外的幾個步驟，在 章節(jié)5.1 中。

列表1

     // Invalidate the cache set
     var currentEntry = startAddress;
    do {
        currentEntry = probeView.getUint32(currentEntry);
    } while (currentEntry != startAddress);

    // Measure access time
    var startTime = window.performance.now();
    currentEntry = primeView.getUint32(variableToAccess);

    var endTime = window.performance.now();

圖2 性能分析算法的累積表現(xiàn)

圖2顯示了性能分析的結(jié)果，運行在 Intel i7-3720QM CPU 上， 裝有 Firefox 35.0.1 和 Mac OS 10.10.2 。我們很高興地發(fā)現(xiàn)在30秒內(nèi)就 映射了超過25%的組，1分鐘內(nèi)就達到了50%。這個算法想要并行運行是非常簡單的，因為大部分的執(zhí)行時間花在了數(shù)據(jù)結(jié)構(gòu)的維護上，只有一小部分花在讓緩存失效和 測量上。整個算法用不到500行 JavaScript 代碼就可以完成。

圖3 Haswell 上兩種方法訪問延遲的概率分布

為了驗證我們的算法能夠辨別不同的組，我們設計了一個實驗來比較一個變量被 flush 前后的訪問延遲。圖3 顯示了兩種方式訪問變量的概率分布函數(shù)。 灰色的代表用我們的方式從緩存中 flush 出去的變量的訪問時間；而黑色是駐留在緩存里的變量的訪問時間。時間的測量用到 JavaScript 的高精度計時器， 所以還包括了 JavaScript 運行時的延遲。兩者的不同是顯而易見的。圖4 顯示的是在較早版本的 Sandy Bridge CPU 上捕捉到的結(jié)果，該型號每個組有16個條目。

通過選取一些列的組，并且不斷的測量它們的訪問延遲，攻擊者可以獲得緩存實時活動非常詳細的圖。我們把這種視覺呈現(xiàn)稱作 “內(nèi)存譜圖”，因為它看起來很像聲音的譜圖。

圖4 Sandy Bridge 上兩種方法訪問延遲的概率分布

圖5 內(nèi)存譜圖示例

圖5顯示的是每隔400ms抓取一次的內(nèi)存譜圖。其中X軸對應時間，Y軸對應不同的組。例子中的時間分辨率是250微秒，檢測了一共128個組。每個點的密度 代表了這個組在這個時間的訪問延遲。黑色代表延遲較低，意味從上次測量到現(xiàn)在沒有其它進程訪問過這個組。白色意味著攻擊者的數(shù)據(jù)在上次測量之后被淘汰了。

細看這個內(nèi)存譜圖可以得到幾個顯而易見的事實。首先，雖然沒用機器語言指令而是用了 JavaScript 的計時器，測量的抖動很小，活躍和不活躍的組 很容易被區(qū)分。圖中有幾條明顯的垂直的線，意味著同一時間間隔里有多個相鄰的組被訪問。因為連續(xù)的組對應的物理內(nèi)存的地址也是連續(xù)的，所以我們 相信這個信號代表著一個超過 64 字節(jié)的匯編指令。還有一些聚在一起的組被同時訪問。我們推斷這代表著變量的訪問。最后，橫著的白線預示著一個變量 被不斷地訪問。這個變量可能是屬于測量代碼的或?qū)儆诋斍暗?JavaScript 運行時。從一個沒有任何特權(quán)的網(wǎng)頁能得到這么多信息真是太了不起了。

移除集讓攻擊者能夠監(jiān)控任意一個組的活動。因為我們得到的移除集是非典型的，因此攻擊者必須想辦法把分析過的組和受害者的數(shù)據(jù)或是代碼的地址 關(guān)聯(lián)起來。這個學習/分類的問題已經(jīng)由 Zhang 和 Yarom 分別在 文章[25] 和 文章[23] 里提出了，他們采用了不同的諸如 SVM 的機器學習的算法試圖從 緩存延遲的測量數(shù)據(jù)里找到規(guī)律。

為了有效地展開學習過程，攻擊者需要誘導受害者做一些操作，然后檢查哪些組被這個操作訪問到，詳見 算法2。

    Let Si be the data structure matched to eviction set i
    1. For each set i:
        (a) Iteratively access all members of Si to prime the cache set
        (b) Measure the time it takes to iteratively access all members of Si
        (c) Perform an interesting operation
        (d) Measure once more the time it takes to iteratively access all members of Si
        (e) If performing the interesting operation caused the access time to slow down considerably, then the operation was
        associated with cache set i.

因為 JavaScript 受到一系列的權(quán)限限制，實現(xiàn)步驟(c)是很有挑戰(zhàn)的。與之形成對比的是 Apecechea 等人能夠用一個空的 sysenter 調(diào)用來觸發(fā)一次細小的內(nèi)核操作。為了實現(xiàn)這個步驟，我們必須調(diào)查 JavaScript 的運行時來發(fā)現(xiàn)有哪些函數(shù)會觸發(fā)有意思的行為，例如文件訪問，網(wǎng)絡訪問，內(nèi)存分配等等。 我們還對那些運行時間相對較短，不會產(chǎn)生遺留的函數(shù)感興趣。因為遺留可能導致垃圾回收，進而影響步驟(d)的測量。Ho 等人在 文章[10] 中已經(jīng)找到了這樣的 幾個函數(shù)。另外一種方式是誘導用戶代替攻擊者執(zhí)行一個特定的操作（比如在鍵盤上按一個鍵）。這個例子里的學習過程可能是結(jié)構(gòu)化的（攻擊者知道受害者 將要執(zhí)行的時機），也可能是非結(jié)構(gòu)化的（攻擊者只能假設系統(tǒng)一段時間內(nèi)的響應緩慢是由受害者的操作導致的）。這兩種方法都被使用，詳見 章節(jié)4。

因為我們的程序會一直檢測到由 JavaScript 運行時產(chǎn)生的活動，比如高性能的計時器的代碼，瀏覽器其它那些與當前執(zhí)行調(diào)用無關(guān)的模塊的代碼，實際上我們 通過調(diào)用兩個相似的函數(shù)并** 對比** 它們兩次活動性能分析的結(jié)果，以此來尋找相關(guān)的組。

正如 文章[23] 所示，LLC 訪問模式可被用來建立一個高帶寬的隱藏信道，有效的用來在同一臺宿主上的兩個虛擬機之間滲透敏感的信息。在我們的攻擊模型里， 攻擊者雖然不在同一臺宿主上的虛擬機里，而是在一個網(wǎng)頁中，隱藏信道的動機不一樣，但是也很有意思。

經(jīng)由動機，我們假設某個安全部門在追蹤犯罪大師 Bob 的蹤跡。該部門通過釣魚項目在 Bob 的個人電腦上裝了一個被稱作 APT( Advanced Persistent Threat ) 的 軟件。APT 被設計用來記錄 Bob 的犯罪記錄并發(fā)送到部門的秘密服務器上。然而 Bob 非常的警覺，他使用了啟用了強制信息流跟蹤 （Information Flow Tracking ） [24] 的操作系統(tǒng)。操作系統(tǒng)的這一功能阻止了 APT 在訪問了可能含有用戶隱私數(shù)據(jù)的文件后再連上網(wǎng)絡。

在這種情況下，只要 Bob 能被誘導訪問一個由安全部門控制的網(wǎng)頁，這個部門就可以立刻采用基于 JavaScript 的高速緩存區(qū)攻擊。APT 可以利用基于高速緩存區(qū) 的邊信道和惡意網(wǎng)站通信，這樣就不用通過網(wǎng)絡傳輸用戶的隱私數(shù)據(jù)，進而不會觸發(fā)操作系統(tǒng)的信息流跟蹤功能。

這個研究案例受到了來自某個安全部門的 “RF retro-reflector” 設計的啟發(fā)，在這個設計里一臺諸如麥克風的收集器，并不會把接收到的信號直接發(fā)送出去， 而是把接受的信號調(diào)制到由一個外部 ”收集設備“ 發(fā)送給它的 “照射信號” 上去。

隱藏信道的設計有兩個需求：第一，保持發(fā)送端的簡單，我們尤其不想讓它執(zhí)行 章節(jié)2.1 中的移除集算法。第二，因為接收端的移除集是非典型的， 它應該足夠簡單，這樣接收端就可以搜索到發(fā)送端的信號調(diào)制到了哪一個組。

為了滿足這些需求，我們的發(fā)射器/ APT 在自己的內(nèi)存中分配了 4K 大小的數(shù)組，并且不斷地把收集到的數(shù)據(jù)轉(zhuǎn)換成對與這個數(shù)組的內(nèi)存訪問的模式。這個 4K 大小 的數(shù)組覆蓋了緩存的 64 個組，這樣 APT 在每個時間周期里就能傳送 64比特 的數(shù)據(jù)。為了能保證內(nèi)存訪問能夠被接收端定位，相同的訪問模式被重復 運用到數(shù)組的幾個拷貝上。 因此，高速緩沖區(qū)的大部分都會被執(zhí)行到，與之形成對比的是 文章[23] 中的方法使用了典型的移除集，因此只會激活兩條緩存線。

接收端的代碼會對操作系統(tǒng)的內(nèi)存做一個性能分析，然后搜索含有被 APT 調(diào)制后的數(shù)據(jù)所在的頁框。真正的數(shù)據(jù)會被從內(nèi)存訪問的模式里解調(diào)出來然后傳回服務器， 整個過程都不會違背操作系統(tǒng)對信息流跟蹤的保護。

我們的攻擊模型假設發(fā)送端使用（相對較快的）機器語言編寫，而接收端是用 JavaScript 編寫。所以，我們假設整個系統(tǒng)性能的限制因素是惡意網(wǎng)站的 采樣速度。

為了評估隱藏信道的帶寬，我們寫了一個小程序用預先設定好的模式來遍歷系統(tǒng)的內(nèi)存（即含有單詞"Usenix"的比特圖）。 接下來，我們用 JavaScript 高速緩存攻擊來嘗試尋找這一訪問模式，并測量 JavaScript 代碼所能達到的最大的頻率。

圖6 主機到主機的隱藏信道

圖6 顯示的內(nèi)存譜圖捕捉到了這一隱藏信道的執(zhí)行。隱藏信道的理論帶寬通過測量大約是 320kbps，這和 文章[23] 中用機器語言實現(xiàn)的跨虛擬機的隱藏信道 1.2Mbps 的帶寬比較吻合。

圖7 主機到虛擬機的隱藏信道
圖7 中的內(nèi)存譜圖比較相似，但并不是由運行在相同主機上的接收端代碼得到的，而是在一臺虛擬機上得到的（Firefox 34 瀏覽器，Ubuntu 14.01 系統(tǒng)， VMWare Fusion 7.1.0 ）。盡管在這個場景下的高峰頻率只能到大約 8kbps，但是一個虛擬機中的網(wǎng)頁竟然能夠探測到底層的硬件，這著實讓人驚訝。

絕大多數(shù)關(guān)于高速緩存區(qū)攻擊的研究都假設攻擊者和受害者位于云計算供應商數(shù)據(jù)中心里的同一臺機器上。這樣的機器一般不會配置成接收交互式的輸入， 所以該領(lǐng)域的大部分研究都聚焦于如何獲得加密鑰匙或其它保密的狀態(tài)信息，譬如隨機數(shù)生成器的狀態(tài)[26]。 本文將研究怎么利用高速緩存區(qū)攻擊來跟蹤用戶的行為 ，這和我們的攻擊模型更相關(guān)。我們注意到 文章[20] 已經(jīng)嘗試了利用 CPU 的一級緩存對系統(tǒng)負載進行細粒度的度量，以此跟蹤按鍵事件的方法。

本案例將演示一個惡意網(wǎng)站怎么用高速緩存區(qū)攻擊去跟蹤用戶的活動。在接下來展示的的攻擊里，我們會假設用戶在一個背景標簽頁或窗口里打開 了一個惡意網(wǎng)站的頁面，并且在另一個標簽頁或是另外一個完全沒有互聯(lián)網(wǎng)連接的應用里執(zhí)行了一些敏感的操作。

我們選擇了把焦點集中在鼠標操作和網(wǎng)絡活動上，因為操作系統(tǒng)負責處理它們的代碼沒有辦法被忽略不計。所以，我們期待這些操作會在高速緩存區(qū)留下比較大的腳印。 而且正如下文所述，它們也很容易被 JavaScript 處處受限的安全模型所觸發(fā)。

兩種攻擊的結(jié)構(gòu)比較類似。首先，進行性能分析，攻擊者用 JavaScript 探測每一個組。接著，在訓練階段，待檢測的活動（網(wǎng)絡活動或鼠標操作）被觸發(fā)， 伴隨著對高速緩存區(qū)的高精度的采樣。在訓練階段一方面通過測量腳本直接觸發(fā)網(wǎng)絡活動（執(zhí)行一個網(wǎng)絡請求），另一方面是不停地在網(wǎng)頁上搖晃鼠標。

通過比較在訓練階段緩存區(qū)在閑時和忙時的活動，攻擊者可以知道用戶操作會對應激活哪部分的組，并且訓練出一個關(guān)于組的分類器。最后， 在分類階段，攻擊者不停地監(jiān)視這些有意思的組從而掌握用戶的活動。

我們用一個基本的非結(jié)構(gòu)化的訓練過程，即假設訓練過程中系統(tǒng)進行的最集中的操作就是被測量的。為了利用這點，我們計算了隨著時間的 每次測量的 Hamming 權(quán)重（等于在某個周期內(nèi)活躍組的個數(shù)），之后應用 k-meas 算法對測量數(shù)據(jù)做聚類。 然后計算每個簇中每個組的平均訪問延遲，從而算出每個簇的中心。遇到未知的測量矢量，我們會計算這個矢量和各個中心的歐幾里得距離， 并把它歸到最近的那一類。

在分類階段，我們用命令行工具 wget 生成網(wǎng)絡流量，并且將鼠標移動到窗口以外。為了獲得網(wǎng)絡活動的真實數(shù)據(jù)，我們同時用 tcp-dump 來測量系統(tǒng)的流量，然后把 tcp-dump 記錄的時間戳和分類器所檢測到時間戳聯(lián)系起來。為了獲得鼠標操作的真實數(shù)據(jù)，我們寫了一個頁面記錄所有 鼠標事件及其時間戳。需要強調(diào)的是，記錄鼠標活動的頁面并不在運行著測量代碼的瀏覽器（Firefox），而是運行在另一個瀏覽器里（Chrome）。

圖8 檢測到的網(wǎng)絡活動

圖9 檢測到的鼠標活動

活動測量的結(jié)果見 圖8 和 圖9 。兩個圖片的頂端都顯示了高速緩存區(qū)一個子集的實時活動。圖片的底端是分類器的輸出結(jié)果和外部收集的真實數(shù)據(jù)。 正如圖片展示的那樣，我們異常簡單的分類器在識別鼠標操作和網(wǎng)絡活動方面非常有效。毫無疑問，使用更加 高級的訓練和分類技巧可以進一步提高攻擊的效果。需要強調(diào)的是，鼠標操作的檢測器并不會檢測網(wǎng)絡活動，反之亦然。

分類器的測量頻率只有　500Hz。結(jié)果就是，它沒有辦法統(tǒng)計單個的包，而只能說明在一個階段里活躍還是不活躍。另一方面，檢測鼠標活動的代碼要比 記錄真實數(shù)據(jù)的代碼采集到的事件多。這是因為　Chrome 瀏覽器對鼠標事件的頻率做了限制，大約是　60Hz。

Chen 等人在一篇著名的文章[5]中證明了對網(wǎng)絡活動的監(jiān)測可以作為深度挖掘用戶行為的奠基石 。雖然 Chen 等人假設攻擊者可以在網(wǎng)絡層 監(jiān)控受害者所有流入和流出的數(shù)據(jù)，但是這里所展示的技術(shù)本質(zhì)上可以讓惡意網(wǎng)站監(jiān)控用戶同時進行的網(wǎng)絡操作。攻擊可以被更多的指標增強， 例如內(nèi)存分配（見文[13]），DOM　布局事件，磁盤寫操作等。

本文顯示了邊信道攻擊的范圍要比預期的大很多。本文提出的攻擊可針對互聯(lián)網(wǎng)上的大部分機器而不局限于某些特定的攻擊場景。如此眾多的系統(tǒng)突然間易受 邊信道攻擊意味著防止邊信道攻擊的算法和系統(tǒng)應當被廣泛使用，而不能只是在某些特定情況下。

我們的攻擊需要一臺個人計算機，并配有 Intel CPU，使用了 Sandy Bridge， Ivy Bridge， Haswell 或者 Broadwell 的微架構(gòu)。據(jù) IDC 的數(shù)據(jù)顯示，2011年 以后售出的個人計算機80%都滿足這一條件。更進一步，假設用戶使用的瀏覽器支持 HTML5 高精度計時器和類型數(shù)組的規(guī)范。表1 列舉了各個瀏覽器廠商支持這些 API 的最早的版本和易被攻擊的版本占全球互聯(lián)網(wǎng)流量的比重，統(tǒng)計數(shù)據(jù)來自 StatCounter GlobalStatas 2015年一月份的報告。如表所示，目前市場上 80% 的瀏覽器 都無法抵御此類攻擊。

攻擊能否取得效果取決于能不能用 JavaScript 高精度時間API 進行精準的測量。雖然 W3C 對這個API規(guī)范定義了高精度時間的單位是 “毫秒，并精確到千分之一”， 但是它并沒有給出該值的最高分辨率，實際上瀏覽器不同、操作系統(tǒng)不同這個值也會有所區(qū)別。舉個例子，我們在測試過程中發(fā)現(xiàn) MacOS 上的 Safari 瀏覽器可以精確 到納秒，而 Windows 上的 IE 瀏覽器只能精確到 0.8 微秒。 另一方面， Chrome 瀏覽器在所有我們測試的操作系統(tǒng)上給出的分辨率都是 1 微秒。

所以 圖3 中，單次緩存命中和緩存未命中的差別大概是 50 納秒，性能分析和測量的腳本在時間分辨率力度更細的操作系統(tǒng)上要稍加改動。 在性能分析階段，我們沒有統(tǒng)計單次未命中的時間，而是重復讀取內(nèi)存來放大時間的差別。 在測量階段，我們雖然沒有辦法放大每次緩存未命中的時間，但是我們可以利用來自相同頁框的代碼通常會讓相鄰的組失效這一點。只要同一個頁框的64個組里有20個 產(chǎn)生了緩存未命中，我們的攻擊就可以在哪怕是毫秒級的分辨率上進行。

我們提出的這種攻擊還可以很容易的運用到手機、平板等移動設備上。值得一提的是，安卓瀏覽器從 4.4 版本開始支持 高精度時間API 和 類型數(shù)組，但在 本文撰寫的時候 iOS Safari （8.1） 還不支持 高精度時間API。

本文描述的攻擊之所以可行，是因為它聚集了從微架構(gòu)這一層到最終的 JavaScript 運行時設計和實現(xiàn)的的一些決定： 怎么把物理內(nèi)存的地址映射到組， 嵌套的高速緩存區(qū)架構(gòu)，JavaScript 高速的內(nèi)存訪問和高精度計時器;最后是 JavaScript 的權(quán)限模型。這里的每一點上都可以采取一些緩解措施， 但是都會對系統(tǒng)的正常使用產(chǎn)生影響。

在微架構(gòu)這層，修改物理內(nèi)存到緩存線的映射方式可以非常有效地阻止我們的攻擊，即不再用地址底12比特中的6個直接選擇一個組。類似的，換用非嵌套的 緩存微架構(gòu)而不是用嵌套的，會讓我們的代碼幾乎不肯能精確地一級緩存中淘汰某項，使得測量更加困難。然而，這兩個設計決定當初被選擇正是為了讓 CPU 的設計 和高速緩存的使用更高效，改變它們會讓其它很多的應用性能受到影響。再說了，修改 CPU 微架構(gòu)可不是一件小事，因為升級已經(jīng)部署的硬件是肯定不行的。

在JavaScript這層，似乎降低高精度計時器的分辨率就可以讓攻擊更難發(fā)動。但是，高精度計時器的建立是為了解決 JavaScript 開發(fā)者的實際需要的， 這些應用范圍可從音樂和游戲再到增強現(xiàn)實和遠程醫(yī)療。

一個可能的權(quán)宜之計是限制應用只有在獲得了用戶許可后才能訪問計時器（例如，通過顯示一個確認窗口）或者通過第三方的認可（例如下載自可信的 “app store”）。

一種有意思的方式是使用啟發(fā)式的性能分析來檢測和阻止此類攻擊。如 Wang 等人利用大量算法和按位指令的存在可以預示這密碼學應用元素 [21] 的存在， 可以注意到我們的攻擊里各種測量步驟訪問內(nèi)存也會有一定的模式。因為現(xiàn)代的 JavaScript 的運行時，作為性能分析引導優(yōu)化的機制的一部分，已經(jīng)能夠 詳細的檢查代碼的運行時性能。所以 JavaScript 運行時應該能夠在執(zhí)行時發(fā)現(xiàn)有性能分析行為的代碼并且相應的修改返回結(jié)果 （例如，在高精度計時器里加上抖動，或者動態(tài)的調(diào)整數(shù)組在內(nèi)存中的位置等）。

在這篇論文里，我們展示了如何有效地通過可疑網(wǎng)頁發(fā)起針對微架構(gòu)的邊信道攻擊，這種方式已被認為是非常有效的。 與高速緩存區(qū)攻擊一般被用于密碼分析應用不同，本文介紹了它怎么被用來有效地跟蹤用戶行為。 邊信道攻擊的范圍已被拓展，這意味著設計新的安全系統(tǒng)時一定要考慮到對邊信道攻擊的反制措施。

我們很感謝激 Henry Wong 對于 Ivy Bridge 緩存淘汰策略的研究和 Burton Rosenberg 對于頁和頁框的講解。

見原文

偶然看到這篇文章 美發(fā)現(xiàn)新的瀏覽器攻擊模式：可監(jiān)控全球八成PC， 非常驚訝 便隨手點開文章里的原文連接 PDF，讀完有種腦洞大開的感覺。論文知識點涉及計算機組成原理、虛擬化、 性能分析、JavaScript、HTML5規(guī)范等，都是我所感興趣的領(lǐng)域，再加上中招的是 老東家 的產(chǎn)品， 因此雖然我是安全領(lǐng)域的小白，但還是嘗試精讀并且斗膽翻譯一下，不足之處歡迎大家批評指正。任何意見和建議請猛戳 issues

本文系 OneAPM 工程師王龑編譯整理。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方技術(shù)博客。