利用 Linux 內核中的空引用
最近有消息稱，Google Project Zero 團隊的研究人員開發了一種方法，可以利用 Linux 核心中因 NULL 指標解引用而導致的漏洞。
到目前為止，與空指標解引用相關的核心問題還沒有得到應有的重視，因為將此類問題轉化為導致權限提升或執行自身程式碼的攻擊被認為是不切實際的（禁止將非特權進程映射到位址空間的較低區域）。
一般而言，此類錯誤會導致核心產生 oops 警告，之後問題任務會完成，狀態會恢復，而無需停止系統。
這種新的攻擊方法是基於對「oops」狀態的處理，這會導致引用計數器（refcount）的值增加，進而導致計數器溢位並釋放與 refcount 關聯的記憶體。
在這種情況下，利用被簡化為釋放後使用攻擊的典型操作（出現對象的引用計數變為零，內存被釋放，但實際上有工作鏈接指向已釋放內存的情況）。
目前，當 Linux 核心在進程上下文中觸發空指標解引用時，會產生一個oops 錯誤，這與核心 panic 不同。內核 panic 發生在內核判定沒有安全的方法可以繼續執行，因此必須停止所有執行時。然而，核心在 oops 錯誤發生時並不會停止所有執行；相反，核心會盡量恢復並繼續執行。
取消引用 NULL 指針在這裡用作以受控方式生成“oops”狀態的方法。 問題是大約需要 232 次“oops”狀態調用才能達到 32 位引用計數溢出。
從實際角度來看，利用所提出的漏洞進行攻擊大約需要連續生成八天的非原地（OOP）狀態。如果攻擊成功，該漏洞允許您在核心層級執行程式碼。
漏洞利用中使用的 NULL 指針取消引用已於 XNUMX 月修復，但由於類似問題並不少見，並且以前被視為錯誤，而不是漏洞，開發人員將對 Linux 內核添加一般保護，以防止操縱“oops”生成的攻擊”
在任務的情況下，這意味著丟棄現有的內核堆棧並直接轉到調用 do_exit 的 make_task_dead。 內核還將向 dmesg 發布“崩潰”日誌和內核跟踪，顯示錯誤發生時內核所處的狀態。 當明顯發生內存損壞時，這似乎是一個奇怪的選擇； 然而，其目的是讓內核錯誤更容易檢測和記錄，因為運行中的系統比停機系統更容易調試。
具體來說，內核 6.2 包含限制「oops」最大次數的變更。當達到限制（預設為 10 次 oops，如果需要，可以使用 oops_limit 參數更改此值）後，核心將啟動向「panic」狀態的轉換，然後重新啟動，這將阻止將引用計數重設為零所需的迭代次數。
還計劃將限制轉移到以前發布但仍受支持的內核分支，以及流行發行版的內核包。
最後，如果您有興趣了解更多相關信息，可以點擊以下連結查看詳情。