前幾天有消息稱 在 C 標準庫 uClibc 和 uClibc-ng 中，用於許多嵌入式和便攜式設備， 已發現漏洞 （尚未分配 CVE），它允許替換 DNS 緩存中的虛擬數據，這可用於欺騙緩存中任意域的 IP 地址，並將對該域的請求重定向到攻擊者的服務器。
關於這個問題，有人提到這個 影響路由器、接入點和物聯網設備的各種 Linux 固件， 以及嵌入式 Linux 發行版，如 OpenWRT 和 Embedded Gentoo。
關於漏洞
脆弱性 是由於在代碼中使用了可預測的事務標識符來發送查詢 的 DNS。 DNS 查詢 ID 是通過簡單地增加計數器而不進一步隨機化端口號來選擇的，這 使毒害 DNS 緩存成為可能 通過搶先發送帶有虛假響應的 UDP 數據包（如果響應在真實服務器的響應之前到達並且包含正確的標識，則響應將被接受）。
與 2008 年提出的 Kaminsky 方法不同，它甚至不需要猜測事務 ID，因為它最初是可預測的（最初，它被設置為 1，隨著每個請求而增加，並且不是隨機選擇的）。
保護自己 反對ID猜測，規範 進一步推薦使用隨機分佈的網絡端口號 發送 DNS 查詢的來源，以彌補 ID 大小的不足。
啟用端口隨機化時，要形成一個虛擬響應，除了選擇一個 16 位的標識符外，還需要選擇網絡端口號。 在 uClibc 和 uClibc-ng 中，沒有顯式啟用這種隨機化（調用 bind 時，沒有指定隨機源 UDP 端口），其實現取決於操作系統配置。
當端口隨機化被禁用時， 確定要增加的請求 id 被標記為瑣碎任務. 但即使在隨機化的情況下，攻擊者也只需要在 32768-60999 範圍內猜測網絡端口即可，為此他可以在不同的網絡端口上大量同時發送虛擬響應。
問題 已在所有當前版本的 uClibc 和 uClibc-ng 中得到確認，包括最新版本的 uClibc 0.9.33.2 和 uClibc-ng 1.0.40。
“重要的是要注意，影響標準 C 庫的漏洞可能非常複雜，”該團隊本週在一篇博客文章中寫道。
“不僅在單個程序中的多個點對易受攻擊的函數進行數百或數千次調用，而且該漏洞會影響配置為使用該庫的無限數量的其他多供應商程序。”
2021 年 XNUMX 月，發送了有關漏洞的信息 到 CERT/CC 進行協調的陣列準備。 2022年XNUMX月， 該問題已與 200 多家製造商共享 與 CERT/CC 相關聯。
XNUMX 月份曾嘗試單獨聯繫 uClibc-ng 項目的維護者，但他回復稱自己無法修復該漏洞，並建議公開披露該問題的信息，希望得到開發修復的幫助。社區。 來自製造商的 NETGEAR 宣布發布更新以消除漏洞。
需要注意的是，影響標準 C 庫的漏洞可能非常複雜。 不僅會在單個程序的多個點對易受攻擊的函數進行數百或數千次調用，而且該漏洞還會影響來自多個供應商的無限數量的其他程序，這些程序配置為使用該庫。
值得注意的是，該漏洞存在於許多製造商的設備中（例如，uClibc 用於 Linksys、Netgear 和 Axis 的固件中），但由於該漏洞在 uClibc 和 uClibc-ng 中仍未修補，因此有關設備的詳細信息和特定製造商的產品存在問題，直到他們被披露。
終於 如果您有興趣了解更多信息，您可以查看詳細信息 在下面的鏈接中。