Microsoft、AI支援でRust標準ライブラリのメモリ安全性の問題を発見　保守担当者と修正へ

何が起きたのか

Microsoftの研究組織FORGE Labは、Rustに標準で付属するstdとcoreのライブラリを調べた。一部の不具合の発見には、AIによる脆弱性調査システムMDASHの研究用システム「Hyenas」を使った。研究者はコードを調査し、不具合を再現したうえでセキュリティへの影響を評価し、Rustの保守担当者へ報告して修正を進めた。AIによる発見、人による検証、保守担当者による対応を組み合わせた取り組みである。^[1]

Rustは型や所有権の仕組みでメモリの扱いを制限する。一方、OSと直接やり取りする処理などでは、開発者が安全性の条件を守る責任を負うunsafeのコードを使う。標準ライブラリは、この内部処理を通常の安全なAPIで包んで提供している。APIは、利用者が機能を呼び出すための窓口だ。今回の調査は、その内部処理が前提とする条件に着目した。^[1]

報告された問題は3つの型に分かれる。処理が途中で中断しないと信頼すること、呼び出し元が渡す実装を正しいと信頼すること、OSやCライブラリと共有する状態が想定どおりだと信頼することである。たとえば、途中で処理が止まった時に初期化前のメモリを後片付けしたり、別のスレッドが扱う状態を変更したりすると、内部の安全性の条件が崩れる。^[1]

なぜ今なのか

Rustの標準ライブラリは、多くのソフトウェアの基礎になっている。MicrosoftはRustを社内の主要言語に位置付け、GitHubもCopilotのエージェント実行基盤をRustで書き直したと発表している。利用が広がる中、共通の基盤を調べて修正する取り組みは、それを使う開発チームの安全性にも関わる。今回の調査対象は、標準ライブラリ内部のunsafeコードである。^[1]

研究チームは2021年にも、静的解析ツールRudraでRustのメモリ安全性を調べていた。今回、特に有望な調査領域として挙げたのは、RustとOS・Cライブラリの接点だ。この接点を調べるには、プログラム内のコードに加えて、システム全体の振る舞いを理解する必要がある。言語モデルが持つ知識を使うことで、その前提を照合する調査を進めやすくなったという。^[1]

子スレッドからの終了処理で、動作中の主スレッドが使うシグナル処理用メモリを片付けてしまう問題は、2015年から存在していた。修正では、主スレッド用のそのメモリを終了時に片付ける処理をやめた。研究者は攻撃への利用可能性も調べ、検証した条件では信頼できる悪用経路を見つけられず、実用的な悪用の可能性を低いと評価した。この評価は、その問題についての調査結果である。^[1]

修正は複数の段階にある。試験的なAPIでは、安定化の前に設計を変えた例がある。文字列の置換処理では、入力の型を変えて文字コードの条件を満たす入力を受け付けるようにした。メモリを確保するAllocator APIでは、処理途中の巻き戻しを起こさないことを実装者に求めた。一方、発表時点で研究チームが報告した問題のうち2件は未解決であり、個々の課題と修正状況を追う必要がある。^[1]

日本の企業にとって何が変わるか

Rustを採用する日本企業の開発・セキュリティ担当者は、自社で利用するAPIと実行条件を確認したい。Microsoftは、重大な脆弱性となるかは実際のプログラムが問題を起こす使い方に達するかで決まると説明する。利用するRustのバージョン、標準ライブラリの機能、独自の実装、OSとのやり取りを照合すると、調査すべきコードを絞れる。^[1]

独自のライブラリでunsafeを使っている場合は、外部から渡された処理を呼ぶ箇所が確認点となる。コピー、比較、後片付け、繰り返し処理などが途中で失敗した場合にも、内部の状態を安全に保つ必要がある。Microsoftは、失敗する可能性のある作業を先に終える方法や、後片付けの際に状態を戻す仕組みを挙げている。担当者は正常終了だけを前提にした実装がないか確認できる。^[1]

呼び出し元から値を受け取る処理では、同じ関数を複数回呼んだ時に結果が変わる条件も確認する。報告書は、値を1回だけ取得して保持する、返された内容を検証する、安全な型に必要な条件を組み込むといった対応を示した。文字列や要素数を扱う共通部品のレビューでは、利用者が実装できる処理の結果をどこで信頼しているかを具体的に追える。^[1]

AIによる調査を開発工程へ取り込む際には、発見後の検証を担当する人も決めておきたい。今回のFORGE Labの工程では、研究者が再現と影響評価を行い、保守担当者と修正を進めた。自社でも、不具合を起こす条件、影響する処理、修正の状態をそろえることが、対応の優先度を決める材料になる。公開課題を確認する際は、修正済み・審査中・未解決という状態を分けて扱う。^[1]

1. 利用中のRustのバージョンと、報告されたAPIを使う箇所を照合する。
2. unsafeの処理で、途中の失敗や呼び出し元の実装に置いた前提を点検する。
3. AIの検出結果を再現・影響評価・修正状況の確認へつなぐ担当を決める。

まとめ

今回の調査は、AIを使って基盤ソフトウェアの前提を調べ、人が安全性への影響を判断した事例である。Rustの型や所有権による安全性を保つには、標準ライブラリの内部処理でも、途中の失敗やOSとの相互作用を考慮する必要がある。開発担当者が実際の利用条件を調べることで、発見された不具合と自社の対応を結び付けられる。^[1]

保守担当者による修正には、処理の変更に加えて、APIの型や実装者の責任を明確にする対応も含まれる。利用する側は、採用している機能と修正状況を確認し、更新やコードの見直しを判断する。AIを使う調査と、人による再現・影響評価・修正の確認をつなぐことが、この事例から学べる実務上の要点である。^[1]