記憶體洩漏漏洞 Squidbleed 的技術原理解析
最近安全研究人員在知名開源代理伺服器 Squid 中發現了一個名為 Squidbleed 的漏洞，編號為 CVE-2026-47729。這個漏洞最令人驚訝的地方在於，導致問題的程式碼邏輯竟然早在 1997 年就寫入了，至今潛伏了將近 29 年。
對於剛接觸系統安全或網路工程的開發者來說，這個漏洞是一個非常典型的 Heap Over-read 案例。所謂 Heap Over-read，是指程式在讀取堆積記憶體（Heap Memory）時，沒有正確檢查邊界，導致讀取超過了原本預定緩衝區（Buffer）的範圍，進而將記憶體中不應該被公開的資料讀出來。
漏洞觸發的技術細節
這個漏洞發生在 Squid 處理 FTP 目錄列表的解析器中。當時為了相容舊款 NetWare 伺服器（這類伺服器會在列表資訊中加入額外的空格），開發者寫了一段迴圈來跳過所有空白字元。
在 C 語言中，程式使用 strchr 函數來尋找特定字元。漏洞的核心在於，當攻擊者控制的 FTP 伺服器傳回一個特殊的列表行，且該行在時間戳記後直接結束而沒有檔名時，指標會剛好落在字串的結束符號 NUL（Null Terminator）上。
由於 strchr 在處理 NUL 字元時的行為，導致迴圈無法正常停止，程式會繼續向後讀取記憶體，直到遇到下一個符合條件的字元為止。隨後，Squid 會將這段超出範圍的記憶體內容當作檔名，直接回傳給攻擊者。
為什麼這會導致敏感資訊洩漏
在高效能的伺服器程式中，為了減少記憶體分配的開銷，系統經常會重複使用已經釋放的記憶體緩衝區，而不會在每次釋放時將其清零（Zeroing）。
當一名受害者透過 Squid 代理伺服器發送 HTTP 請求時，該請求（包含身分驗證標頭 Authorization Header 或 Session Token）會暫時儲存在記憶體中。當該記憶體被釋放後，如果隨即被 Squid 的 FTP 解析器重新分配使用，原本受害者的資料可能依然殘留在記憶體中。
攻擊者只要讓 Squid 讀取其控制的惡意 FTP 伺服器，就能觸發上述的 Over-read 行為，將殘留在記憶體中的受害者 HTTP 請求內容給讀出來。
攻擊條件與影響範圍
這個漏洞並非任何網路上的駭客都能隨意攻擊，它有幾個關鍵的限制條件：
首先，攻擊者必須是受信任的客戶端。也就是說，攻擊者必須已經被允許使用該 Squid 代理伺服器。這在學校、辦公室或公共 Wi-Fi 等共享網路環境中非常常見。
其次，洩漏的內容僅限於明文 HTTP 流量。現代主流的 HTTPS 流量通常使用 CONNECT 隧道，Squid 僅負責轉發加密封包而無法看到內部內容，因此不會洩漏。但如果企業配置了 TLS 終止（TLS Termination）讓 Squid 進行解密檢查，則 HTTPS 內容也會面臨風險。
最後，攻擊者必須能誘導 Squid 連接到其控制的 FTP 伺服器（預設連接埠 21），而 Squid 預設是開啟 FTP 支援的。
實務上的防禦建議
面對此漏洞，有兩種主要的處理方式。
第一是更新版本。雖然官方已在 v7 分支中修復，但由於不同 Linux 發行版（如 Debian）的打包方式不同，建議開發者不要只看版本號，而應確認 FtpGateway.cc 檔案中是否已加入 NUL 字元檢查的防護邏輯。
第二是從攻擊面縮減（Attack Surface Reduction）的角度出發。這是最推薦的做法：直接關閉 Squid 的 FTP 功能。由於現代瀏覽器（如 Chromium）早已停止支援 FTP 協定，且絕大多數企業網路不再需要透過代理伺服器存取 FTP，關閉此功能可以完全消除此漏洞的威脅，而不會影響正常業務。
總結
Squidbleed 提醒我們，即便是在運行數十年的成熟程式碼中，微小的邊界檢查缺失也可能在特定條件下演變成嚴重的資安漏洞。對於工程師而言，處理外部輸入的解析時，嚴格的邊界檢查與記憶體清理習慣是防止此類漏洞的唯一途徑。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。