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