Rust 抓不到的錯誤：從 uutils 審計中學到的教訓

背景

這篇文章探討了 Rust 語言在重寫 GNU 核心工具組（uutils）時所面臨的安全挑戰。儘管 Rust 以記憶體安全著稱，但在 2026 年 4 月 Canonical 揭露的 44 個 CVE 漏洞中，顯示出許多邏輯錯誤、競爭條件（TOCTOU）以及對 Unix 系統底層行為的誤解，依然會導致嚴重的安全隱患。這些問題並非 Rust 編譯器或借用檢查器（Borrow Checker）所能捕捉，而是源於開發者對系統 API 語義的掌握不足。

社群觀點

Hacker News 的討論主要圍繞在「語言安全性」與「系統領域知識」之間的落差。許多資深開發者指出，uutils 暴露出的漏洞大多屬於 Unix 系統開發中的「入門級錯誤」，例如在兩次系統調用之間信任路徑名稱，或是誤將路徑視為單純的字串而非動態的檔案系統指標。評論者 wahern 認為，這些開發者雖然精通 Rust 語法，卻顯然缺乏對 Unix 語義與陷阱的深度理解，而這些問題在 GNU 或 BSD 的老牌開發者眼中早已是數十年前就已解決的常識。這種「業餘感」讓部分社群成員感到憂慮，認為重寫核心工具組的團隊若未曾深入研究原始 GNU 工具的實作邏輯，僅僅是為了用新語言重寫而重寫，將會帶來不必要的安全風險。

針對技術細節，GNU Coreutils 的現任維護者 collinfunk 也參與了討論，他直言 Rust 標準庫（std::fs）的設計過於簡便，反而容易誘導開發者寫出帶有競爭條件的程式碼。他建議 Rust 標準庫應儘速引入類似 openat 的 API，讓操作能錨定在檔案描述符（File Descriptor）而非路徑字串上。此外，他也對文中建議使用 canonicalize 來比較路徑的做法提出異議，認為這在極端路徑深度下會造成嚴重的效能衰退，正確的做法應是調用 fstat 並比較設備號與 inode 編號。他更進一步糾正了原文關於「Rust 版無記憶體安全漏洞」的說法，指出 uutils 過去同樣曾出現過記憶體相關的安全性通報。

另一派討論則聚焦於工具鏈的侷限性。有留言提到，即便 Google 等大企業宣稱 Rust 能顯著降低漏洞率，但這並不代表能自動消除邏輯層面的缺陷。當開發者過度依賴語言提供的安全保障時，可能會忽視對作業系統邊界行為的審查。例如在處理 Unix 管道或環境變數時，Rust 強制使用 UTF-8 的特性若處理不當，反而會導致二進位數據損壞。社群普遍達成共識：語言工具能防止「如何寫」的錯誤，但無法替代「寫什麼」的專業經驗，系統編程的安全性終究建立在對底層運作機制的敬畏與理解之上。

延伸閱讀

• GNU 軟體編寫標準（GNU Coding Standards）：文中提到關於避免任意限制與正確處理檔案語義的規範。
• GitHub 安全諮詢 GHSA-w9vv-q986-vj7x：collinfunk 提供的實例，證明 uutils 亦曾出現過記憶體安全相關問題。