Re: [情報] 研究人員揭露AMD晶片的Sinkclose漏洞，存

※ 引述《hn9480412 (ilinker)》之銘言：
很久沒發文賺P幣了 是時候稍微增加一下收入

就稍微來聊一下System Management Mode大概是什麼東西好了.

先引用一下英文Wiki, 中文有寫跟沒寫一樣..
https://en.wikipedia.org/wiki/System_Management_Mode

用很白話文很簡單的比喻來說的話 他就是一個 時間暫停的魔眼
一旦啟動 其他程序的時間包括作業系統 就像時間凍結了一樣
這時候只有在SMM裡面的人(程式碼)還能活動 直到退出SMM
甚至作業系統搞到當機了, 除非CPU本身也完全涼透無法執行任何指令,
不然SMM在這情況下他應該都還能工作.

至於進入SMM的條件 就叫做SMI, System Management Interrupt.
他可以由單純硬體觸發 也可以從軟體觸發 要離開就由SMM裡面的程式碼去執行特殊指令

在SMM裡面, 幾本上就是可以為所欲為, 沒有什麼東西可以限制你.
系統平台上近乎所有資源, 還有記憶體的內容, 通通在你的控制之中.
至於離開之後, 除非SMM本身程式是故意留下足跡, 不然外界理論上是有可能不知道
你在裡面幹了什麼好事的. 所以SMM本身必須是很重視安全性.

至於SMM裡面要做什麼事情, 他本身也是一些程式碼構成, 這時候你可能會想說.
這不是雞生蛋蛋生雞了嗎? SMM一開始的程式碼又是哪來的?

x86 CPU一開始開機的時候 多半會從SPI ROM讀取程式 也就是我們俗稱的BIOS/UEFI
而要準備用在SMM裡面的程式碼其實也包含在內 我們就以UEFI為例.
UEFI開機會去初始化記憶體 在這個階段其實會預留4MB~8MB(好像吧,忘了)給SMM使用
這塊記憶體是獨佔性的 然後在接下來初始化各種UEFI軟體功能時 會載入一套
用在SMM裡面的程式碼到這塊記憶體 然後將這塊記憶體給標記鎖住
一旦鎖住之後 基本上就不允許修改記憶體中"可執行"的程式碼部分, SMM以外的人
也再也無法看到這塊內容 這邊其實應該就是這次AMD漏洞會影響到的部分 等等會講

當SMM程式碼全數載入/鎖定後, 也就相當於開啟了SMM功能, 之後就可以從軟硬體來
觸發SMM.

舉例來說我在另一篇文章提過 SPI的讀寫其實有一些保護機制 其中一個就是利用SMM,
透過不允許SMM以外的來源直接寫入SPI ROM, 並讓這個動作經過SMM程式碼的驗證
來達到避免入侵者修改程式碼的目的.

: 研究人員揭露AMD晶片的Sinkclose漏洞，存在近20年
: 文/陳曉莉 | 2024-08-12發表
: 資安業者 IOActive的兩名安全研究人員Enrique Nissim與Krzysztof Okupski在上周舉行的
: Defcon駭客會議上，揭露了一個存在於AMD晶片的安全漏洞，被研究人員命名為Sinkclose的
: 漏洞將允許駭客於系統管理模式（System Management Mode，SMM）執行程式碼，而且已存在
: 近20年。Sinkclose的漏洞編號為CVE-2023-31315，波及絕大多數的AMD處理器，從行動處理
: 器、桌面處理器、工作站處理器到資料中心處理器等，估計影響數億臺裝置。
: 根據AMD的簡要說明，CVE-2023-31315漏洞存在於模型特定暫存器（Model Specific Regist
: er，MSR）的驗證不當，允許具備Ring 0存取權限的惡意程式，即便是在系統管理中斷（Sys
: tem Management Interrupt，SMI）上鎖時，都能修改SMM配置，因而可執行任意程式。接下來就跳到這邊 也就是上面講的問題. SMM本來身為最高權限的程式碼, 並且設計
上在鎖定之後就不允許修改 從而保證程式碼是安全的.

可是這邊開了個洞 讓入侵者有機會從OS階段的ring0就直接修改SMM裡面的東西
先不管這件事情的先決條件是什麼(原文也沒有講清楚).如果載入的OS本身 ring0也已
經被污染那就的確可以透過這個漏洞去入侵SMM, 再來就如上面的例子, 也許可以修改
SPI ROM內容了. SPI ROM被污染後 那下次開機執行的自然還是污染的程式碼.

: 至於Nissim與Okupski則說，SMM為x86架構最強大的執行模式之一，該層級的程式碼對於Hyp
: ervisor及作業系統等級的保護機制而言是不可見的，包括反欺騙引擎及反病毒系統；在研究
: AMD處理器時，他們發現用來保護SMM的一個重要元件含有缺陷，而且快20年了都沒有被發現
: 。
: 即使研究人員並未公布詳細的漏洞細節，也承諾尚不會釋出概念性驗證攻擊程式，但他們向
: Wired透露，此一漏洞最早可追溯到2006年甚至更早之前的AMD晶片，但駭客必須先可存取AM
: D的PC或伺服器，之後擴張其權限，進而於晶片上植入無法受到系統或防毒軟體偵測或保護的
: 惡意程式，就算是重新安裝作業系統也無濟於事。
: 這個意思就是，倘若使用者的AMD處理器已被駭客入侵，唯一的解法就是將它丟掉，沒有其它
: 的修補方法。
至於這部分 濠洨吧=_= 原文好像也沒這麼講.
SMM也只不過就是 一個權限最高的"RAM", 所以除非你能寫入SPI ROM,
不然開機他就會消失, 不存在什麼要丟掉. 就算SPI ROM被寫入
完整重新改寫SPI ROM也能夠消除掉

除非CPU SOC內建SPI ROM還鎖住不能改寫..x86現在市面上應該沒有這種東西

說到SMM在現代系統中的應用,大概有一些像是, 剛說的SPI保護
還有某些安全性驗證, 或是一些廠商自訂的介面/服務, 在Server則是有很重要的
RAS(可靠性、可用性和可維護性)應用, 的確可謂之重要而又脆弱.

其實之前UEFI三不五時就一直在修各種SMM漏洞, 像是利用buffer溢位之類有的沒有
的東西去"騙" SMM裡面的程式碼作一些不該做的事情.
當然照這次的漏洞, 看起來好像是可以更直觀的去改SMM程式, 的確是有相當高的危險性

不過x86陣營自然也有意識到SMM的缺點 最大的問題就是時間暫停這件事情
SMI一多必然會影響系統效能, 在大型Server時間就是金錢的世界中,x86陣營也一
直在盡量避免SMM的使用, 不久的將來也許就可以在周邊條件符合的環境下,直接
關閉SMM功能了.

到這邊P幣就騙夠了 謝謝各位的耐心觀看:P

: 不過，不管是IOActive或AMD都認為要攻陷CVE-2023-31315漏洞並不容易。
: AMD已於上周修補了大多數的處理器，但並不打算修補AMD Ryzen 3000 Series桌面處理器，
: 使得有用戶抱怨，3000系列是在2019年及2020年推出，它們存在還不到5年，還有很多人在使
: 用，也依然強大，呼籲AMD應該要重視這些用戶。
: https://www.ithome.com.tw/news/164412
: Intel：你看AMD也有問題吧，我還送刺客教條還算佛了吧
: 水桶都聽到咕嚕咕嚕的聲音了

--

跟Intel ME嚴格說來是不太一樣. ME漏洞會直接暴露出來讓人可以直接攻擊,入侵後就 基本無敵什麼都能做,要偷資料要改SPI, 應該都可以做得到. SMM漏洞照說明你得要先想辦法入侵OS取得ring0權限, 然後再跑進SMM去偷做事 不過修復上我就不知道這次對於AMD來說好不好修理. SMM本身並不是造成漏洞的主要因素, 問題是在CPU鎖定SMM要用到的RAM,又叫SMRAM 這個鎖定機制的安全性現在有問題. 所以如果AMD能在AGESA又或是microcode去修改 鎖定機制應該就ok.

因為幾十年來大家都是這麼過的(X)

不能

SMM是CPU的隱藏第二人格 ME是隱形地縛靈管家, CPU是住在這個家的人.

沒錯你拔掉以前能靠SMM擋住的一些東西又要另外處理了

理論上當然是Server影響比較大, 畢竟上面還會跑一些重要的服務, 又真正關係到 資安問題 對於client來說,要怎麼從這個漏洞去盜取你的重要資料, 以這個年代來說 也就是一些帳號密碼, 那是另外一個故事了.

窩不知道, 可能要問小姐姐

不是喔, 其實有很大的差別. 與Intel ME同等地位的, 目前來說算是AMD PSP, ARM上可以把他想成類似XCP. 跟SMM完全不同的地方在於 Intel ME/ AMD PSP本身不是跑在你主要CPU上的 他們兩個都是在PCH or CPU SOC上面有多埋一顆小晶片,ME好像是類似atom架構 PSP則其實是一顆小ARM. 這個小晶片才是在執行ME/PSP的人. SMM真正要找個對應的東西的話, 他比較像是ARM的Trust Zone. 都是在同一顆主晶片上分割一部分資源來執行, SMM/TrustZone都有高於一般程序的權限, 而且對一般程序來說這兩個都 像是隱形人. 不過TrustZone的執行不像SMM會整個進入時間暫停一樣的狀態

其實以Windows/Linux來說 他本身是不需要SMI的. SMM設計上其實就是故意要獨立於OS之外, 讓OS看不見他 但Windows下/Linux下有沒有會遇到SMI的狀況呢? 還是有. 要舉例又要提到SPI寫入, 例如當Windows/Linux需要寫入UEFI variable, 他會呼叫UEFI service, 然後uefi service會轉發SMI進SMM再去寫入SPI ROM. 對OS來說其實他是不知道後半段UEFI service發了SMI這件事情的. 另外一個例子是shutdown或是sleep, 這個部分則是晶片組會在收到OS要求shutdown/ sleep要求時, 發出SMI, 再跑去SMM裡面處理一些前置作業, 才進入shutdown/sleep.

理由: 1.系統廠沒開AMD提供的驗證機制(Platform Secure Boot) 2.UEFI部分本身的驗證有可能被幹掉 要講這個會講到root of trust/chain of trust的概念. 下次好了:P

沒錯 他是不同的東西 雖然都是安全性相關 就乾脆順便講下好了. UEFI的secure boot是什麼? 簡單來說就只是 驗證"將要執行"的模組的可靠性 問題在於 那從CPU開機第一時間拾取程式碼的時候, 誰知道這個程式碼可不可靠? 這就是所謂的root of trust, 你的整個系統平台上誰來負責做第一棒安全性驗證的問題 以純UEFI沒有其他機制輔助的情境會變成: 1. CPU fetch UEFI (SEC/PEI/DXE...etc) 2. UEFI 安全性模組啟動 3. UEFI 安全性模組負責在接下來的模組要被執行的時候一一做安全性驗證 4. UEFI 安全性模組最後要驗證OS的開機程序 5. 交棒給OS 所以在#2之前其實也沒有辦法保證安全性 AMD 的Platform Secure Boot或是其他廠商的類似功能就是在 #1之前(或同時)就去驗證整個UEFI又或是其他韌體的可靠性 接著才允許CPU開始執行fetch來的程式, 在這裡他就是root of trust的角色 而且這個root of trust同時必須保證自己的安全性 所以通常會搭配某種機制讓平台上可以去進行某種綁定以策安全 然後我們跟著上面的途徑走, #2以後負責驗證的這個角色換成了UEFI安全性模組 在系統有多個韌體模組的情況下, 這就會像是接力賽跑一樣, 負責做驗證的人一棒 一棒往下接力,這個就是所謂的chain of trust.