RustによるGNU coreutilsの再実装「uutils」で44件の脆弱性公開：システムプログラミングの安全性の限界を指摘
Canonical社は、Rust言語で書き直されたGNU coreutilsの再実装である「uutils」において、44件のCVE（脆弱性）を公開しました。これらの脆弱性のほとんどは、26.04 LTS（長期サポート）に向けた外部監査から発見されたものです。特筆すべき点として、これらのバグは、開発者が意図的に書いた、安全性が高いとされるRustのプロダクションコードベース内に存在し、標準的な安全機構であるボローチェッカー、クリッピーリンツ、カーゴ監査といったツールでは検出されなかったことが報告されています。
主な脆弱性のクラスターとして、「パスを介した二度のシステムコール（syscall）の利用」が挙げられています。これは、パスのチェック（Time of Check）と、そのパスに対する操作（Time of Use）の間に、攻撃者がシンボリックリンクを挿入し、特権的な操作を意図しないターゲットに誘導できるTOCTOU（Time Of Check To Time Of Use）型の問題です。この問題に対処するため、開発者はパス（`&Path`）を値として扱うのではなく、ファイルディスクリプタ（File Descriptor）を基点として操作を行うべきだと警告しています。
また、別の重要な教訓として、「パーミッション設定のタイミング」が指摘されています。ディレクトリの作成後にパーミッションを修正するのではなく、`OpenOptions`などを用いて、ファイルやディレクトリが「生まれる瞬間」に適切なパーミッションを設定することが必須です。さらに、パスの比較においても、単なる文字列比較ではなく、`fs::canonicalize`を用いてパスを正規化（canonicalize）してから比較し、真のファイルシステム上の同一性を確認することが求められています。
さらに、Unix環境特有の「バイト列（raw bytes）」の取り扱いに関する問題も浮き彫りになりました。Rustの標準的な`String`型はUTF-8を前提としますが、Unixのパスや環境変数、ストリームの内容は生のバイト列（`&[u8]`）として扱われるべきです。ここで`from_utf8_lossy`のような損失を伴う変換を行うと、データがサイレントに破損する危険性があります。最後に、信頼できない入力（untrusted input）を処理する際には、パニック（panic!）を発生させるのではなく、必ずエラー（`?`や`Result`）として処理し、アプリケーションの境界で失敗を適切に伝えるべきであるという、堅牢なシステム設計の原則が強調されています。
背景
Rust言語は、メモリ安全性と並行処理の安全性を高めることで、システムプログラミング分野で注目を集めています。しかし、本記事は、その安全機構（ボローチェッカーなど）をすり抜ける、より高度で複雑なシステムレベルの脆弱性（TOCTOU、バイトエンコーディングなど）が存在することを、具体的な監査結果を通じて示しています。これは、単なる言語のバグではなく、OSやファイルシステムとのインターフェース設計上の課題を浮き彫りにしています。
重要用語解説
- CVE: Common Vulnerabilities and Exposuresの略。世界中のセキュリティ脆弱性を識別し、公開するためのリスト。この番号は、発見された特定のセキュリティ欠陥を指し示す。
- TOCTOU: Time Of Check To Time Of Useの略。あるリソース（ファイルやパスなど）の状態をチェックした時点と、実際にそのリソースを使用する時点の間に、攻撃者によって状態が変更されてしまうことで発生する脆弱性。
- canonicalize: ファイルシステムにおけるパスを、シンボリックリンクや相対パス（../, ./）を解決し、絶対的かつ標準的な形式（正規化されたパス）に変換するプロセス。パスの真の同一性を比較するために重要である。
今後の影響
本記事が示す知見は、Rustを用いたすべてのシステムプログラミング開発者にとって極めて重要です。単に言語の構文を学ぶだけでなく、OSのシステムコールやファイルシステムとのやり取りにおける「安全な設計パターン」を意識する必要があります。今後の開発では、ファイルディスクリプタの利用や、バイト列の取り扱いなど、より低レベルな安全対策が必須となり、Rustの信頼性をさらに高めるためのガイドラインとなるでしょう。