一個潛伏 32 年的漏洞走進一台 Telnet 伺服器 （★ 100 分）
CVE-2026-32746 是 GNU inetutils telnetd 中一項自 1994 年遺留至今的預先驗證遠端程式碼執行風險（RCE，Remote Code Execution）。Telnet 是以 TCP/IP 提供遠端命令列連線的舊式協定，帳密以明碼傳輸，現今通常已由 SSH 取代；但工業設備、嵌入式裝置與舊有系統仍可能持續使用。漏洞位於 Telnet 的 LINEMODE 協商功能，攻擊者可在登入前送入過長的 SLC（Set Linemode Characters，設定行模式控制字元）資料，觸發缺少邊界檢查的緩衝區溢位，覆寫相鄰約 400 位元組的全域記憶體。
研究指出，受影響範圍不只 GNU inetutils，也涵蓋 Ubuntu、Debian、FreeBSD、NetBSD、Citrix NetScaler、macOS Tahoe、TrueNAS Core、Haiku、uCLinux 與 DragonFlyBSD 等採用或衍生相同原始碼的實作。然而，能覆寫記憶體不等於能穩定取得 RCE：Telnet 的封包格式限制攻擊者可寫入的位元組值與長度，64 位元 x86 系統的指標配置也讓完整覆寫格外困難。研究人員未在測試環境做出直接 RCE，但在 32 位元 Debian 環境中發現可操控 `free` 釋放任意位址的條件，並可能洩漏堆積區指標；搭配較單純的嵌入式記憶體配置、Kerberos 驗證等額外複雜功能，仍可能讓高能力攻擊者串接成可用攻擊。
文章建議管理者優先清查對外或內部可連線的 Telnet 服務，確認是否啟用 LINEMODE，並盡快套用修補。研究團隊提供偵測工具：探測模式只確認目標是否公告 LINEMODE，不會觸發溢位；完整偵測則以僅超出緩衝區一個位元組的方式，根據伺服器回傳的 SLC 資料判斷是否受影響。這種測試仍可能使極少數脆弱裝置的連線中斷，因此工業控制或無法停機的設備應先在隔離環境評估。文章發表時，GNU inetutils 2.7 尚未納入正式修補版，管理者需確認發行版是否已回移修補，或採用已修正的上游提交版本重新建置。
Hacker News 討論的焦點之一，是文章指責 inetutils 未發布新版本的措辭是否恰當。實際撰寫修補的維護者表示，漏洞在公開郵件論壇回報後，自己於下班時間驗證問題並迅速送出小型修補，隨後也已轉知 oss-security 郵件論壇；對各 Linux 發行版而言，直接套用修補往往比等待新版本更容易。多名留言者感謝無償維護者長期維護 Telnet，也批評資安研究文章不該將開放原始碼維護者視為應提供企業級服務水準的對象；另有人指出專案當時未明確提供私密漏洞回報管道，回報者採用公開論壇也有其背景。
討論者也認為文章技術說明過於冗長、帶有聳動語氣，核心其實是一次缺少邊界檢查所造成的記憶體破壞，而非已證實可廣泛利用的萬用 RCE。有人更正文中「1994 年 RISC 尚是遙遠夢想」的玩笑並不符合史實，因為 ARM、SPARC、MIPS 與 Intel i960 等精簡指令集電腦當時早已存在。儘管如此，多數意見仍認同此案提醒了關鍵現實：大量全球基礎設施仍依賴數十年前、由少數甚至無償人員維護的開放原始碼，而舊式 Telnet 服務一旦暴露於不受信任網路，就應盡可能淘汰、隔離或修補。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=49721291