IT行業的災難：所有操作系統內核都可能被劫持或崩潰！因程序員誤
時間:2018-05-13 作者:xnit 點擊: 次

在英特爾這家芯片巨頭更新手冊的同時，趕緊打上那些補丁。

 

Linux、Windows、macOS、FreeBSD和實現Xen的一些操作系統存在一個設計缺陷；這個缺陷輕則會讓攻擊者得以使搭載英特爾和AMD芯片的計算機崩潰。

 

在最糟糕的情況下，攻擊者有可能“訪問敏感的內存信息或操控低級別的操作系統功能”；換句話說，因而可以窺視內核內存里面的信息，或者劫持運行系統的關鍵代碼�，F在已有了可以糾正幾乎影響全行業的編程失誤的補丁。

 

正如計算機緊急響應小組（CERT）在周二詳細描述的那樣（https://www.kb.cert.org/vuls/id/631579），這個名為CVE-2018-8897的安全漏洞似乎是由微軟、蘋果及其他公司的開發人員引起的，他們誤解了英特爾和AMD處理器處理一種特定的特殊異常的方式。

 

 

的確，CERT特別指出：“這個錯誤似乎歸咎于開發人員對現有文檔解讀有誤。”換句話說，程序員們誤解了英特爾和AMD的手冊，這些手冊可能不是非常明確。

 

中斷被觸發

 

言歸正傳。這個問題的核心是POP SS指令，該指令從運行中程序的堆棧中獲取一個用于選擇堆棧段的值，并將該數值放入到CPU的堆棧選擇器寄存器。這完全與現代操作系統基本上忽視的內存分段有關，你可能也忽視了。POP SS指令由CPU專門處理，那樣如果該指令在執行時出現中斷觸發的情況，堆棧不至于處于不一致的狀態。

 

應用程序可以為POP SS將從堆棧獲取堆棧選擇器的內存位置設置一個調試斷點（debug breakpoint）。也就是說，應用程序使用POP SS時，一旦處理器觸及內存的某個特定部分以獲取堆棧選擇器，它就會生成特殊異常。

 

現在，問題的關鍵來了。緊跟POP SS指令之后的指令必須是INT指令，該指令觸發中斷。軟件生成的這些中斷有時被用戶程序用來激活內核，以便內核可以為運行中的進程執行任務，比如打開文件。

 

在英特爾和AMD機器上，緊跟POP SS之后、軟件生成的中斷指令促使處理器進入內核的中斷處理程序。然后，調試異常被觸發，因為POP SS導致了異常被延遲。

 

操作系統的設計人員沒有料到這一點。他們閱讀英特爾的x86-64手冊后，斷定處理程序一開始處于不可中斷的狀態。而現在在中斷處理程序內部的早期階段就有意料之外的調試異常需要處理。

 

 

 

如果指令POP SS執行，調試寄存器被設置成一訪問該堆棧位置就斷開，下一個指令又是INT N，那么進入中斷門后就會觸發等待的#DB，就像它對大多數成功的分支指令所做的那樣。操作系統開發人員以為不可中斷的狀態是從中斷門語義授予的，而不是非可屏蔽中斷或可能的機器檢查異常。這可能導致開發當初想到這些影響的操作系統監控（supervisor）軟件錯誤地使用非特權軟件所選擇的狀態信息。

 

這是一個嚴重的安全漏洞，也是操作系統開發商的一大疏忽，起因是介紹POP SS指令及其與中斷門語義的相互關系方面的注意事項的說明文檔語焉不詳，可能甚至不全面。

 

結果是，在英特爾系統上，用戶的應用程序可以控制中斷處理程序中的特殊指針寄存器GSBASE；在AMD系統上，用戶應用程序可以控制GSBASE和堆棧指針寄存器。這可以用來使內核崩潰（只需讓內核觸及未映射的內存）、提取受保護的內核內存的一部分，或者篡改內部結構以破壞系統或操縱其操作。

 

我們認為，任何企圖鉆空子的嘗試更有可能導致內核崩潰，甚至搞任何嚴重的破壞。不過就bug而言，正如Meltdown那樣，這讓行業有點難堪；它需要打上補丁，為了安全起見。

 

操縱手法

 

針對這個問題的FreeBSD安全公告作了進一步的解釋。該操作系統的開發人員寫道：“在x86架構系統上，堆棧由堆棧段和堆棧指針這個組合來表示，兩者必須保持同步才能指令確保正常運行。與操縱堆棧段有關的指令有特殊的處理機制，以便與堆棧指針方面的更改保持一致。”

 

“MOV SS和POP SS指令禁止調試異常，直到緊挨下一條指令的指令邊界。如果該指令是一個系統調用或將控制權轉交給操作系統的類似指令，調試異常就會在內核環境中加以處理，而不是在用戶環境中處理。”

 

結果怎樣？“通過身份驗證的本地攻擊者也許能夠讀取內核內存中的敏感數據、控制低級別的操作系統功能，甚至可能導致系統崩潰。”

 

據微軟的內核安全公告（https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8897）顯示，想在Windows上鉆這個漏洞的空子，意味著“攻擊者先得登錄到系統。然后攻擊者運行一個專門編寫的應用程序以控制受影響的系統。”

 

這并不是一種可能性很小的場景，除非你運行的是完全可信任的代碼。

 

Red Hat已準備發布補丁，Ubuntu和蘋果MacOS也是如此。

 

早在2018年3月23日，Linux內核也已得到了修復。版本4.15.14、4.14.31、4.9.91、4.4.125以及更早的4.1、3.16和3.2分支版本已經有了補丁。

 

微軟已拿出了相應的補丁，適用于Windows版本7到10、Windows Server版本2008到1803。Xen為版本4.6到4.10拿出了補丁。VMware的虛擬機管理程序并未面臨風險，但vCenter Server有一個變通方法，vSphere Integrated容器在等修正版出來，但兩者都只是被評為“可能受影響”。

 

請參閱上面的CERT鏈接，了解所有受影響的廠商及其應對情況，必要的話打上相應的更新版。

 

所有消息人士特別指出，雖然這個問題源自x86-64指令，但要怪內核程序員，而不是怪英特爾。許多程序員似乎只是誤解了如何處理調試異常，并且在很長的時間內犯了類似的錯誤。

 

英特爾發布了第67版的軟件開發者手冊，中斷方面已作了相應的修改。

 

眾多操作系統開發人員會被公司派去學習強制性的再教育課程，進一步深入了解x86-64架構�，F在英特爾已更新了手冊，以闡明堆棧選擇器指令的處理機制；讀者應趕緊打上補丁。

 

 

文章來源 云頭條