思科安全研究人員 細節 () 在 Glibc 中為 32 位元 ARMv7 平台提供的 memcpy() 函數實作中。該問題是由於使用操縱有符號 32 位元整數的彙編程式最佳化而導致對確定複製區域大小的參數的負值處理不正確所致。在 ARMv7 系統上以負大小呼叫 memcpy() 會導致錯誤的值比較，並寫入指定緩衝區邊界之外的區域。
此漏洞可被利用在攻擊者可以組織傳輸複製資料大小的變數的負值的情況下執行程式碼（例如，傳輸超過 2 GB 的資料時會出現負值，但在攻擊過程中，必須傳輸至少 4 GB 才能超出緩衝區）。 memcpy() 函數在應用程式中被廣泛使用，ARMv7 處理器在汽車系統、行動、工業、消費、通訊和嵌入式裝置中很常見，這些裝置可能受到使用藍牙、高清廣播/DAB、USB、CAN 總線、Wi-Fi 和其他外部資料來源的攻擊（例如，接受輸入資料而不受大小限制的網路存取服務和大小限制的網路存取服務和大小）。
作為範例，我們給出了一個可利用的漏洞來攻擊汽車資訊系統內建的 http 伺服器，該伺服器可透過汽車 Wi-Fi 網路存取。外部攻擊者可以透過發送非常大的 GET 請求來利用此伺服器中 memcpy 的漏洞並獲得系統的 root 存取權。
在 32 位元 x86 系統上，問題不會發生，因為此體系結構的 memcpy 實作正確地將大小為 size_t 類型的無符號整數值（在組合語言中 對於 ARMv7，它被視為有符號整數（而不是 size_t）。該修復程序目前可用 ，將包含在 Glibc 2.32 的 XNUMX 月更新中。
修復方法歸結為用無符號類似物（blo 和 bhs）替換對有符號操作數（bge 和 blt）進行操作的彙編指令。
問題尚未解決。 （未出現在 Debian 8 中）， , 、OpenEmbedded、Tizen（使用 glibc）。 и 由於它們不支援 32 位元 ARMv7 系統，因此該問題不會影響它們。 Android 不易受到攻擊，因為它使用自己的 libc 實作（Bionic）。在 預設情況下，大多數建置使用 Musl，但儲存庫也包含 glibc。
來源： opennet.ru
