PTT數位生活區 / PC_Shopping (個人電腦購買)

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

看板PC_Shopping (個人電腦購買)作者 (綾崎若菜家御用)時間3月前 (2024/08/12 20:31), 3月前編輯推噓57(57推 0噓 66→)
留言123則, 59人參與, 3月前最新討論串3/3 (看更多)
※ 引述《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也有問題吧，我還送刺客教條還算佛了吧 : 水桶都聽到咕嚕咕嚕的聲音了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.134.212.51 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1723465898.A.94D.html
推
08/12 20:35, 3月前 , 1F
解惑給推
08/12 20:35, 1F
推
08/12 20:37, 3月前 , 2F
科普推
08/12 20:37, 2F
推
08/12 20:39, 3月前 , 3F
跟我想的差不多 有看沒有懂
08/12 20:39, 3F
推
08/12 20:51, 3月前 , 4F
推
08/12 20:51, 4F
→
08/12 20:57, 3月前 , 5F
08/12 20:57, 5F
推
08/12 21:01, 3月前 , 6F
懂了 多重宇宙的另個我應該懂了
08/12 21:01, 6F
推
08/12 21:13, 3月前 , 7F
得推一下, 其實真的還寫得蠻容易理解
08/12 21:13, 7F
→
08/12 21:14, 3月前 , 8F
的, 可以明白這個事情大概是怎麼一回
08/12 21:14, 8F
→
08/12 21:14, 3月前 , 9F
事...至於專業的細節, 外行人的我當
08/12 21:14, 9F
→
08/12 21:15, 3月前 , 10F
然是不會懂, 也應該不需要懂(喂~~~
08/12 21:15, 10F
推
08/12 21:18, 3月前 , 11F
好像跟我想的差不多，但我看不懂，推
08/12 21:18, 11F
→
08/12 21:18, 3月前 , 12F
簡單來說就是歷史共業(?
08/12 21:18, 12F
推
08/12 21:20, 3月前 , 13F
推簡單明白，所以這東西就是時代必
08/12 21:20, 13F
→
08/12 21:20, 3月前 , 14F
然產物，以後有機會淘汰就是了對吧
08/12 21:20, 14F
推
08/12 21:20, 3月前 , 15F
在電蝦推 跟我想的差不多 是政確的事嗎?
08/12 21:20, 15F
推
08/12 21:25, 3月前 , 16F
這跟Intel ME的漏洞應該是差不多嚴重
08/12 21:25, 16F
→
08/12 21:25, 3月前 , 17F
架構問題比較難完全修復最好直接蛋雕
08/12 21:25, 17F
跟Intel ME嚴格說來是不太一樣. ME漏洞會直接暴露出來讓人可以直接攻擊,入侵後就 基本無敵什麼都能做,要偷資料要改SPI, 應該都可以做得到. SMM漏洞照說明你得要先想辦法入侵OS取得ring0權限, 然後再跑進SMM去偷做事 不過修復上我就不知道這次對於AMD來說好不好修理. SMM本身並不是造成漏洞的主要因素, 問題是在CPU鎖定SMM要用到的RAM,又叫SMRAM 這個鎖定機制的安全性現在有問題. 所以如果AMD能在AGESA又或是microcode去修改 鎖定機制應該就ok.
推
08/12 21:28, 3月前 , 18F
聽起來是A片的情節
08/12 21:28, 18F
推
08/12 22:13, 3月前 , 19F
推
08/12 22:13, 19F
推
08/12 22:35, 3月前 , 20F
可以篡改ring0 的部分，那一堆事都可以辦
08/12 22:35, 20F
→
08/12 22:35, 3月前 , 21F
到了
08/12 22:35, 21F
推
08/12 22:36, 3月前 , 22F
推推
08/12 22:36, 22F
推
08/12 22:36, 3月前 , 23F
08/12 22:36, 23F
推
08/12 22:40, 3月前 , 24F
推
08/12 22:40, 24F
推
08/12 22:41, 3月前 , 25F
專業推推
08/12 22:41, 25F
推
08/12 22:41, 3月前 , 26F
我還是沒很懂 看起來SMM就是一個弊大於利
08/12 22:41, 26F
→
08/12 22:41, 3月前 , 27F
的東西 為什麼還要讓他繼續存在?
08/12 22:41, 27F
因為幾十年來大家都是這麼過的(X)
推
08/12 22:55, 3月前 , 28F
推淺顯易懂的解說!
08/12 22:55, 28F
推
08/12 23:02, 3月前 , 29F
我猜 存在的理由就是為了相容
08/12 23:02, 29F
→
08/12 23:02, 3月前 , 30F
相容些很古老、很底層的東西
08/12 23:02, 30F
推
08/12 23:09, 3月前 , 31F
推科普 雖然我看不懂
08/12 23:09, 31F
推
08/12 23:10, 3月前 , 32F
08/12 23:10, 32F
推
08/12 23:14, 3月前 , 33F
跟我想的一樣
08/12 23:14, 33F
推
08/12 23:17, 3月前 , 34F
就跟Intel的ME一樣太上皇
08/12 23:17, 34F
推
08/12 23:35, 3月前 , 35F
關機還能入侵嗎？
08/12 23:35, 35F
不能
推
08/12 23:41, 3月前 , 36F
嗯 好 懂了
08/12 23:41, 36F
還有 49 則推文
還有 6 段內文
→
08/13 10:08, 3月前 , 86F
的SMI去硬搞 快速插拔幾次後window
08/13 10:08, 86F
→
08/13 10:08, 3月前 , 87F
s就藍屏了
08/13 10:08, 87F
推
08/13 11:38, 3月前 , 88F
推!
08/13 11:38, 88F
推
08/13 13:30, 3月前 , 89F
看懂了 AMD YES
08/13 13:30, 89F
推
08/13 15:07, 3月前 , 90F
不是太懂，uefi載入不是會有驗證，所以修
08/13 15:07, 90F
→
08/13 15:07, 3月前 , 91F
改後的uefi無法啟動，但為什麼可以改spi
08/13 15:07, 91F
→
08/13 15:07, 3月前 , 92F
rom後還能啟動？
08/13 15:07, 92F
→
08/13 15:09, 3月前 , 93F
喔喔，看到前一篇文有解釋了，原來是系統
08/13 15:09, 93F
→
08/13 15:09, 3月前 , 94F
廠沒開
08/13 15:09, 94F
理由: 1.系統廠沒開AMD提供的驗證機制(Platform Secure Boot) 2.UEFI部分本身的驗證有可能被幹掉 要講這個會講到root of trust/chain of trust的概念. 下次好了:P ※ 編輯: comipa (36.225.63.74 臺灣), 08/13/2024 15:35:17
推
08/13 17:32, 3月前 , 95F
謝謝科普
08/13 17:32, 95F
推
08/13 17:47, 3月前 , 96F
platform secure boot多一個字，是不
08/13 17:47, 96F
→
08/13 17:47, 3月前 , 97F
是跟安全開機不一樣的東西？
08/13 17:47, 97F
推
08/13 17:53, 3月前 , 98F
sb是edk2的吧，amd psp相關的東西
08/13 17:53, 98F
→
08/13 17:53, 3月前 , 99F
也不是系統廠想關就關的
08/13 17:53, 99F
推
08/13 18:06, 3月前 , 100F
psb跟secure boot是不一樣的東西喔
08/13 18:06, 100F
沒錯 他是不同的東西 雖然都是安全性相關 就乾脆順便講下好了. 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. ※ 編輯: comipa (220.134.212.51 臺灣), 08/13/2024 19:49:36 ※ 編輯: comipa (220.134.212.51 臺灣), 08/13/2024 19:50:49 ※ 編輯: comipa (220.134.212.51 臺灣), 08/13/2024 19:51:35 ※ 編輯: comipa (220.134.212.51 臺灣), 08/13/2024 19:54:36
推
08/13 20:05, 3月前 , 101F
想再問Windows裡面有個驅動(系統裝置
08/13 20:05, 101F
→
08/13 20:05, 3月前 , 102F
)叫 dynamic root of trust 也是應用
08/13 20:05, 102F
→
08/13 20:05, 3月前 , 103F
到同一個root of trust來源嗎~?
08/13 20:05, 103F
→
08/13 20:08, 3月前 , 104F
自動更新所裝的這個DRTM不曉得是什麼
08/13 20:08, 104F
推
08/13 20:22, 3月前 , 105F
謝謝，查完看到DRTM也是開機最初載入
08/13 20:22, 105F
→
08/13 20:22, 3月前 , 106F
不受信任的代碼，沒有處理#1之前驗證
08/13 20:22, 106F
推
08/13 20:40, 3月前 , 107F
廠商不肯開psb多半是想保留cpu的二手市
08/13 20:40, 107F
→
08/13 20:40, 3月前 , 108F
場吧，開了會鎖cpu的
08/13 20:40, 108F
→
08/13 20:48, 3月前 , 109F
哇靠 開了會鎖CPU 一種蘋果T1的概念?
08/13 20:48, 109F
推
08/13 22:04, 3月前 , 110F
推
08/13 22:04, 110F
→
08/13 22:59, 3月前 , 111F
沒有二手市場廠商比較爽吧
08/13 22:59, 111F
→
08/14 00:01, 3月前 , 112F
簡單來說就是有人可以潛伏在你的主機板裡面
08/14 00:01, 112F
→
08/14 00:01, 3月前 , 113F
就算你還原系統也沒有用 解決方法就是 離線
08/14 00:01, 113F
→
08/14 00:01, 3月前 , 114F
還原系統 更新補丁 包括覆寫 bios 再上線更
08/14 00:01, 114F
→
08/14 00:01, 3月前 , 115F
厲害一點的就是把它備份起來再把惡意程式抓
08/14 00:01, 115F
→
08/14 00:01, 3月前 , 116F
出來看他裡面到底是什麼
08/14 00:01, 116F
→
08/14 00:04, 3月前 , 117F
再修正一下可能是任何硬體 說不定存在於可程
08/14 00:04, 117F
→
08/14 00:04, 3月前 , 118F
式化的電競滑鼠面 還有無線網路設備都有可能
08/14 00:04, 118F
→
08/14 00:04, 3月前 , 119F
只要是他能夠被改寫系統會讀取的都有可能
08/14 00:04, 119F
→
08/14 00:09, 3月前 , 120F
其實這都還只是在講程式化的部分都還沒有講
08/14 00:09, 120F
→
08/14 00:09, 3月前 , 121F
到晶片的部分
08/14 00:09, 121F
推
08/14 10:52, 3月前 , 122F
知識有長有推
08/14 10:52, 122F
推
08/15 00:24, 3月前 , 123F
推
08/15 00:24, 123F
‣ 更多 comipa 的文章
文章代碼(AID): #1ckW2gbD (PC_Shopping)
PC_Shopping 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 comipa 的文章
文章代碼(AID): #1ckW2gbD (PC_Shopping)