Glibc 包含由 Aurora OS 開發人員準備的針對 memcpy 漏洞的修復程序

Aurora 行動作業系統(開放行動平台公司開發的 Sailfish 作業系統的一個分支)的開發人員分享了一個關於消除 嚴重漏洞 (CVE-2020,6096)在 Glibc 中,僅出現在 ARMv7 平台上。 有關該漏洞的資訊早在 XNUMX 月就已披露,但直到最近幾天,儘管該漏洞已被修復,但仍無法修復 分配的 危險程度很高,並且有一個漏洞利用的工作原型,允許您在 memcpy() 和 memmove() 函數中處理以某種方式格式化的資料時組織程式碼執行。 包修復 Debian и Ubuntu 尚未發布,且該漏洞自公開披露之日起近兩個月內以及自 Glibc 開發人員收到通知之日起五個月內仍未修復。

這個漏洞出現在 ARMv7 的組合語言中的 memcpy() 和 memmove() 實作中,是由於對確定複製區域大小的參數負值的錯誤處理所造成的。 當公司 SUSE и 紅帽 宣布他們的平台不受該問題的影響,因為他們不是針對 32 位元 ARMv7 系統構建的,也沒有參與創建修復程序。 許多嵌入式發行版的開發人員似乎都依賴 Glibc 團隊,也沒有積極參與修復的準備工作。

選項 修補 為了解決這個問題,華為幾乎立即提出嘗試將使用有符號運算元(bge 和 blt)操作的彙編指令替換為無符號類似物(blo 和 bhs)。 Glibc 維護人員開發了一套測試來檢查各種錯誤情況,之後發現華為補丁不合適,沒有處理輸入資料的所有可能組合。

由於 Aurora OS 是 ARM 的 32 位元版本,其開發人員決定自行修復漏洞並向社群提供解決方案。 困難在於,必須編寫該函數的高效彙編語言實現,並考慮輸入參數的各種選項。 已使用未簽名指令重寫了實作。 補丁 結果很小,但主要問題是保持執行速度並避免 memcpy 和 memmove 函數的效能下降,同時保持與所有輸入值組合的兼容性。

3月初,準備了兩個版本的修復程序,分別通過了Glibc維護者的測試框架和Aurora的內部測試套件。 XNUMX 月 XNUMX 日,選擇了其中一個選項並 發送 到 Glibc 郵件列表。 一個星期後
這是 建議 另一個方法類似的補丁,修正了華為之前試圖修復的多架構實作中的問題。 測試花了一個月的時間 合法註冊 由於補丁的重要性。
8月XNUMX日更正 被接受 到即將發布的 glibc 2.32 版本的主分支。 該實作包括兩個補丁 - 第一 用於 ARMv7 的 memcpy 多架構實現,以及 第二 用於 ARM 的 memcpy() 和 memmove() 的通用組合語言實作。

該問題影響數百萬運行Linux 的ARMv7 設備,如果沒有適當的更新,所有者在將它們連接到網路時就會面臨風險(接受無大小限制的輸入資料的網路可存取服務和應用程式可能會受到攻擊)。 例如,識別該漏洞的研究人員準備的漏洞利用程式展示瞭如何透過發送非常大的 GET 請求並獲得系統的 root 存取權限來攻擊汽車資訊系統中內建的 HTTP 伺服器。

來源: opennet.ru

添加評論