當前位置:
首頁 > 新聞 > Intel官方對5月15號曝出的CPU側信道漏洞「ZombieLoad」的詳細技術分析(上)

Intel官方對5月15號曝出的CPU側信道漏洞「ZombieLoad」的詳細技術分析(上)

背景了解

5月15號有媒體曝出,安全研究人員在在一個月之前在Intel 晶元中發現了一種被稱為「ZombieLoad」的新漏洞,此漏洞可讓攻擊者獲取當前處理器正在處理的敏感數據。

攻擊者可以利用這個漏洞發起對Intel 晶元的側信道攻擊,這也是繼此前Meltdown、Spectre與Foreshadow之後,最為嚴重的安全漏洞,研究員們在一個月之前向Intel 報告了這些漏洞。

「ZombieLoad」直接的理解就是「殭屍載荷」,即處理器無法理解或正確處理的大量數據,迫使處理器向處理器的微碼請求幫助以防止崩潰。應用程序通常只能看到自己的數據,但是這個漏洞允許數據流過這些邊界牆。研究人員表示,ZombieLoad將泄漏處理器內核當前載入的所有數據。這意味著,黑客利用的實際上是設計缺陷,而不是注入的惡意代碼。

攻擊方式

與此前三個側信道攻擊(Meltdown、Spectre與Foreshadow)方式類似,新的攻擊方式也是利用處理器的推測執行過程中的漏洞。

此漏洞由此前參與Meltdown、Spectre漏洞研究的部分安全人員以及Bitdefender安全人員聯合發現,其實際為微架構數據採樣(MDS)攻擊,可利用微體系結構中的推測執行操作推斷出其他應用在處理器中處理的數據。

Intel 表示,ZombieLoad 包括 4 個漏洞。分別是針對存儲緩衝區的攻擊(CVE-2018-12126/Fallout)、載入緩衝區(CVE-2018-12127)、行填充緩衝區(CVE-2018-12130/Zombieload/RIDL)以及內存區(CVE-2019-11091)。其中Zombieload是嚴重性最高的,能夠獲取最大量且隱秘的數據。

影響範圍

自2011年以來發布的所有Intel處理器很可能都會受到影響,尤其是雲主機服務可能會受到較大的衝擊。同時Intel也指出MDS攻擊方式實際上利用難度較高,其實際影響不會有那麼大。

漏洞修復

目前Intel已經發布了微代碼更新,且新處理器不會受到影響。這其中包括英特爾至強、Broadwell、Sandy Bridge、Skylake 和 Haswell 等晶元型號。Kaby Lake、Coffee Lake、Whiskey Lake 和 Cascade Lake,以及所有的凌動和 Knights 處理器也都受到影響。

目前,蘋果、微軟和谷歌都已經分別發布補丁。

英特爾對微結構數據採樣的分析

微架構數據採樣(MDS)的工作原理

MDS可以允許可以在本地執行系統上的代碼的惡意用戶推斷受架構機制保護的數據,雖然使用漏洞「ZombieLoad」在系統上定位特定數據可能很困難,但惡意攻擊者可以通過收集和分析大量數據來查找受保護數據。具體過程請參閱《深潛中的MDS表:CPUID枚舉和體系結構MSR》,通過這種辦法以獲取可能受MDS影響的處理器列表。MDS只涉及與一級數據緩存(L1D)以外的微體系結構結構相關的方法,因此不包括異常數據緩存載入(RDCL)或L1終端故障(L1TF)。

MDS推測執行側通道方法可用來泄露以下微架構結構中的數據:

1.存儲緩衝區:用於保存存儲地址和數據的臨時緩衝區;

2.填充緩衝區:CPU緩存之間的臨時緩衝區;

3.載入埠:將數據載入到寄存器時使用的臨時緩衝區;

這些結構比L1D小得多,因此可以保存更少的數據,並且更頻繁地被覆蓋。使用MDS方法來推斷與特定內存地址相關的數據也更加困難,這可能需要惡意攻擊者收集大量數據並進行分析來查找任何受保護的數據。

新的微代碼更新(MCUs)正計劃被發布,以幫助程序緩解這些漏洞。Intel建議在切換到以前的程序不可信的程序時更新微代碼並清除微架構緩衝區。這些緩解措施將需要對操作系統、虛擬機管理程序和Intel 程序保護擴展(Intel SGX)進行更改和更新。

本文檔中的微體系結構詳細信息只適用於受MDS技術影響的處理器,而不是所有Intel 處理器的通用處理器。有關受影響的處理器列表,請參閱CPUID枚舉和體系結構MSR。

微架構存儲緩衝區數據採樣(MSBDS)CVE-2018-12126

執行存儲操作時,處理器將數據寫入稱為存儲緩衝區的臨時微體系結構。這使得處理器能夠在將數據寫入高速緩存或主內存之前繼續執行存儲操作之後的指令。另外, I / O寫入(例如,OUT)也保存在存儲緩衝區中。

當載入操作從與早期存儲操作相同的內存地址讀取數據時,處理器可以直接從存儲緩衝區將數據轉發給載入操作,而不是等待從內存或緩存載入數據,這種優化過程就被稱為存儲庫載入轉發(store-to-load forwarding)。

在某些條件下,來自存儲操作的數據可以從存儲緩衝區推測性地轉發到針對不同內存地址的故障或輔助載入操作。由於存儲的大小小於存儲緩衝區寬度,或者尚未執行存儲的數據部分,因此存儲可能不會覆蓋存儲緩衝區內的整個數據欄位。這些情況可能導致轉發的數據包含來自以前存儲的數據。由於載入操作將導一個fault/assist1並且其結果也將被丟棄,因此轉發的數據不會導致漏洞的程序執行或架構狀態更改。但是,惡意攻擊者可能能夠將這種僅用於推測的數據轉發給一個開源的gadget框架(disclosure gadget ),從而允許他們推斷出這個值。

MSBDS的跨線程影響

對於受MSBDS影響的處理器,物理內核上的存儲數據緩衝區將在該內核上的活動線程上進行靜態分區。這意味著具有兩個活動線程的內核將有一半的存儲緩衝區條目僅用於線程1,一半僅用於另一個線程。當線程進入休眠狀態時,其存儲緩衝區條目可能會被其他活動線程使用。這會導致以前用於進入睡眠狀態的線程(並且可能包含過期數據)的存儲緩衝區條目由其他(活動)線程重用。當線程從休眠狀態被喚醒時,存儲緩衝區將重新被分區。這會導致存儲緩衝區將存儲緩衝區條目從已經處於活動狀態的線程傳輸到剛剛被喚醒的線程。

微架構填充緩衝數據採樣(MFBDS)CVE-2018-12130

填充緩衝區是一個內部結構,用於收集第一級數據緩存丟失的數據。當內存請求丟失L1數據緩存時,處理器會分配一個填充緩衝區來管理對數據高速緩存行的請求。另外,填充緩衝區還會臨時管理響應內存或由I / O操作返回或發送的數據。填充緩衝區可以將數據轉發到載入操作,也可以將數據寫入數據緩存。一旦來自填充緩衝區的數據被寫入高速緩存,處理器就會釋放填充緩衝區,從而允許在未來的內存操作中重用該條目。

填充緩衝區可能會保留以前內存請求中的過期數據,直到新的內存請求覆蓋填充緩衝區。在某些條件下,填充緩衝區可以推測性地將數據(包括過期數據)轉發到將導致故障的載入操作。不過,這不會導致程序執行漏洞,因為故障載入永遠不會停止,因此不會修改架構狀態。然而,開源的 gadget框架可能能夠通過側信道時序分析來推斷轉發的填充緩衝器條目中的數據。

MFBDS的跨線程影響

填充緩衝區在同一物理內核上的線程之間共享,無需任何分區。因為填充緩衝區是在兄弟線程

線程之間動態分配的,所以填充緩衝區中的過期數據可能屬於另一個線程所進行的內存訪問。例如,在兄弟線程(sibling thread)上執行不同應用程序的情況下,如果其中一個應用程序處於惡意攻擊者的控制之下,則可能在特定條件下使用MFBDS來推斷受害者的某些數據通過填充緩衝區的值。

微架構載入埠數據採樣(MLPDS)CVE-2018-12127

處理器使用稱為載入埠的微架構結構來從內存或I / O執行載入操作,在載入操作期間,載入埠從內存或I / O系統接收數據,然後將該數據提供給寄存器文件和更新的相關操作。在一些實現中,每個載入埠內的回寫數據匯流排可以保留來自以前載入操作的數據值,直到較新的載入操作覆蓋該數據為止。

在這些情況下,微架構載入埠數據採樣(MLPDS)可以向惡意攻擊者顯示過期的載入埠數據:

1. 一個大於64位的故障或輔助(faulting/assisting)向量(SSE/IntelAVX/IntelAVX-512);

2.一個跨64位元組邊界的故障或輔助載入;

在這些情況下,故障/輔助載入操作推測性地提供從內部數據結構到較新的依賴操作的過期數據值。故障/輔助載入操作永遠不會停止,因此不會修改架構狀態。然而,接收過期數據的新依賴操作可以是開源的 gadget框架的一部分,該開源的 gadget框架可以向惡意攻擊者泄露過期的數據。

MLPDS的跨線程影響

載入埠在同一物理內核上的線程之間共享,因為載入埠是在線程之間動態分配的,所以載入埠中的過期數據可能屬於另一個線程進行的內存訪問。例如,在兄弟線程上執行不同應用程序的情況下,如果其中一個應用程序受惡意攻擊者控制,則可能在特定條件下使用MLPDS推斷受害者的某些數據通過裝載埠的值。

微架構數據採樣不可緩存內存(MDSUM)CVE-2019-11091

使用不可緩存(uncacheable ,UC)內存類型的數據訪問不會將新行填充到處理器高速緩存中,在受微架構數據採樣不可訪問內存(MDSUM)影響的處理器上,對不可訪問內存進行故障或輔助的載入操作仍然可能從這些內核或數據訪問中推測出數據。因為不可緩存的內存訪問仍然通過存儲緩衝區、填充緩衝區和載入埠移動數據,並且這些數據值可能在故障或輔助載入時被推測性地返回。因此,惡意攻擊者可以通過上面討論的MSBDS,MFBDS和MLPDS機制推測出這些數據值。

微架構數據採樣漏洞的緩解措施

硬體緩解

有關受影響的處理器的完整列表,請參閱《深潛中的MDS表:CPUID枚舉和體系結構MSR》。

以下MSR枚舉使程序能夠檢查處理器是否受MDS方法的影響:

值為1表示處理器不受RDCL或L1TF的影響。此外,值為1表示處理器不受MFBDS的影響。

·IA32_ARCH_CAPABILTIES [0]:RDCL_NO

·IA32_ARCH_CAPABILITIES [5]:MDS_NO

值為1時表示處理器不受MFBDS / MSBDS / MLPDS / MDSUM的影響。

請注意,如果設置了RDCL_NO或MDS_NO位(或兩者都設置了),則可以緩解MFBDS。一些現有處理器也可能僅在載入微代碼更新後枚舉RDCL_NO或MDS_NO。

受影響的處理器的緩解措施

對於微體系結構數據採樣漏洞的緩解措施包括在轉換到可能許可權較少的執行實體之前,例如,在操作系統(OS)執行IRET或SYSRET指令返回應用程序之前,清除存儲緩衝區、填充緩衝區和載入埠。

有兩種方法可以覆蓋受MDS影響的微體系結構緩衝區:MD_CLEAR功能和程序序列。

處理器支持緩衝區覆蓋(MD_CLEAR)

Intel 將發布微碼更新和枚舉MD_CLEAR功能的新處理器。在枚舉MD_CLEAR的處理器上,應使用VERW指令或L1D_FLUSH命令使處理器覆蓋受MDS影響的緩衝區值,因為這些指令優先於程序序列。

VERW指令和L1D_FLUSH命令將覆蓋受MSBDS影響的處理器上當前邏輯處理器的存儲緩衝區值,對於受MFBDS影響的處理器,這些指令將覆蓋物理內核上所有邏輯處理器的填充緩衝區。對於受MLPDS影響的處理器,這些指令將覆蓋物理內核上所有邏輯處理器的載入埠寫回匯流排。受MDSUM影響的處理器也受MFBDS,MSBDS或MLPDS中的一個或多個影響。因此,如上所述覆蓋緩衝區也將覆蓋包含不可緩存數據的任何緩衝區條目。

VERW緩衝區覆蓋細節

VERW指令已經定義為返回一個段是否可以從當前許可權級別寫入,MD_CLEAR枚舉VERW的內存操作數變體(例如,VERW m16)已擴展到覆蓋受MDS影響的緩衝區。

VERW的寄存器操作數變體不保證具有這種緩衝區覆蓋功能,無論VERW許可權檢查的結果如何,以及當選擇器為空或導致描述符載入段違例時,都會發生緩衝區覆蓋。但是,對於最低延遲,Intel建議使用指示有效可寫數據段的選擇器。

示例用法:

MDS_buff_overwrite():

sub $8, %rsp

mov %ds, (%rsp)

verw (%rsp)

add $8, %rsp

ret

請注意,VERW指令更新EFLAGS寄存器中的ZF位,因此在現有代碼中使用上述序列時請務必謹慎。還要注意,VERW指令不能在實際模式或虛擬8086模式下執行。

不管在同一物理內核上的另一個邏輯處理器上執行的是什麼,添加到VERW的微代碼將正確地覆蓋邏輯處理器的所有相關微體系結構緩衝區。

設置推測障礙

一些枚舉MD_CLEAR支持的處理器可以在VERW之後立即推測性地執行指令,這種推測性執行可能在VERW緩衝區覆蓋功能清除推測指令線程之前發生。

由於這種可能性,應該在調用VERW和執行不能通過MDS觀察受保護數據的代碼之間設置一種推測障礙。

為了說明這種可能性,請考慮以下指令序列:

1.代碼區域A;

2. VERW m16;

3.代碼區域B;

4.推測障礙(例如,LFENCE);

5.代碼區域C;

假設可以通過代碼區域A中的指令訪問受保護的數據,VERW指令覆蓋代碼區域A中的指令位於受MDS影響的緩衝區中的任何數據。然而,代碼區域B中的指令可以在緩衝區覆蓋發生之前推測性地執行。因為代碼區域C中的載入是在推測障礙之後執行,所以它們將不會通過代碼區域A觀察位於緩衝區中的受保護數據。

當與VERW一起使用時,以下是在受影響的處理器上為VERW設置合適的推測障礙的示例:

1.LFENCE;

2.當前許可權級別的任何更改(例如SYSRET從管理器返回到用戶模式);

3.VM的進入或退出;

4.成功進入睡眠狀態的MWAIT;

5.WRPKRU指令;

6.在體系結構上序列化指令或事件;

例如,如果OS在從 ring 0轉換到 ring 3之前使用VERW,則ring 轉換本身就是合適的推測障礙。如果在進程內的安全子域之間使用VERW,則合適的推測障礙可能是VERW; LFENCE序列。

由於篇幅過長,譯者將本文差分為兩個部分,第二部分敬請期待!


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

繞過nftables/PacketFilter防火牆過濾規則傳輸ICMP/ICMPv6數據包的漏洞詳解(上)

TAG:嘶吼RoarTalk |