悪意のあるRustクレート「arrayref」がビルド時に不正コードを実行
人気のRustクレート「arrayref」が乗っ取られ、ビルド時に不正なペイロードを実行する事件が発覚し、Hacker Newsで話題になった。
スレでは「Cargoのbuild.rsをサンドボックス化すべきだ」という技術的な提案から、「なぜRustは4つのマクロだけの小さなクレートに依存する文化なのか」という設計思想への疑問まで議論が広がった。Node.jsやRuby譲りの「小さな依存を積み重ねる」文化そのものを問題視する声と、Goや.NETのような標準ライブラリが充実した言語への乗り換えを勧める声が交錯した。
悪意のあるRustクレート「arrayref」が、ビルド時に不正なペイロードを実行する
出典: safedep.io / 元記事はこちら
Cargoにはbuild.rsスクリプトのサンドボックス化がどうしても必要だ。過去にも試みられたことはあるが、あまり進まなかった。(参照: rust-lang.github.io/goals/2024h2/sandboxed-build-scr…)
依存関係を更新しろと言ってくる人たちへ、これが更新しない理由だ。怠慢じゃない、紛れもない先見の明だよ。
>>4
『紛れもない』って言葉、ここで何の意味があるんだ?誇張が過ぎると思う。『先見の明だ』とシンプルに言い切った方がよっぽど強い。まあ人によるけど。
『紛れもない』って言葉、ここで何の意味があるんだ?誇張が過ぎると思う。『先見の明だ』とシンプルに言い切った方がよっぽど強い。まあ人によるけど。
>>4
そのバージョンにセキュリティ上の問題が無い限りはね…
そのバージョンにセキュリティ上の問題が無い限りはね…
Rust公式ブログにも投稿あり(blog.rust-lang.org/2026/08/20/supply-chain-attack-on…)。関連スレ: news.ycombinator.com/item?id=49372853
『arrayrefは4つのマクロだけの小さなクレートだ』とあるけど、なぜこんなにも多くの言語がこのひどい慣習に陥ってしまうんだ?
>>7
ちょうどこの疑問を扱った講演があった(Richard Feldman『Dependency Cultures』)。要するに文化の問題らしい。RustはおそらくNode.jsからこの慣習を受け継ぎ、Node.jsはRubyから受け継いだ。個人的には、Rustのオンライン界隈には『言語のある部分を使いこなせるほど賢くないなら、それを肩代わりするライブラリを入れておけ』という空気が特に強いと思う。
ちょうどこの疑問を扱った講演があった(Richard Feldman『Dependency Cultures』)。要するに文化の問題らしい。RustはおそらくNode.jsからこの慣習を受け継ぎ、Node.jsはRubyから受け継いだ。個人的には、Rustのオンライン界隈には『言語のある部分を使いこなせるほど賢くないなら、それを肩代わりするライブラリを入れておけ』という空気が特に強いと思う。
>>7
この手のクレートの存在自体は別に不思議じゃない。GitHubでしょうもないプロジェクトを見つけるのと同じで、みんな好きに作ってるだけだ。
この手のクレートの存在自体は別に不思議じゃない。GitHubでしょうもないプロジェクトを見つけるのと同じで、みんな好きに作ってるだけだ。
>>7
C++がかつてスレッドは標準ライブラリの範疇じゃないと考えていて後で方針転換したのと同じように、Rustもいずれ方針を変えると予想してる。
C++がかつてスレッドは標準ライブラリの範疇じゃないと考えていて後で方針転換したのと同じように、Rustもいずれ方針を変えると予想してる。
この点に関しては、RustはNodeとほとんど変わらないように見える。堅牢な標準ライブラリを持つGoや.NETのような言語の方が、大半のプロジェクトには向いているんじゃないか。
なぜこの手の乗っ取りはランタイム攻撃を仕込まないんだろう?下流のユーザーを侵害するというより、ビルドマシンにワームを送り込むこと自体が目的に見える。今後はbubblewrapか何かのサンドボックスの中で全部のビルド・テストをするべきなんじゃないか。
>>10
更新された依存関係が実際にユーザー向けのリリースに乗るまでには普通時間がかかるから、その頃には攻撃が発覚している可能性が高いんだと思う。
更新された依存関係が実際にユーザー向けのリリースに乗るまでには普通時間がかかるから、その頃には攻撃が発覚している可能性が高いんだと思う。
この悪意のあるコードは実際には何をするんだ?
crates.ioが、新たにproc macroやbuild.rsを追加したクレートの配信にもっと厳しい基準を設けていないのは残念だ。単純な対策のはずなのに。
>>12
他の人も言ってる通り、攻撃者にとってはクレートのランタイムコードを書き換える方も同じくらい簡単だよ。
他の人も言ってる通り、攻撃者にとってはクレートのランタイムコードを書き換える方も同じくらい簡単だよ。
なぜ今もこんなことが起きるんだ?過去に何度もサプライチェーン攻撃があったのに、なぜパッケージリポジトリの管理者は今も誰でもセキュリティ監査無しにパッケージをアップロード・更新できる状態を許しているんだ?
>>7
少なくとも、そのマクロの中身は単純とは言えない: docs.rs/arrayref/0.3.9/src/arrayref/lib.rs.html#202-…
少なくとも、そのマクロの中身は単純とは言えない: docs.rs/arrayref/0.3.9/src/arrayref/lib.rs.html#202-…
>>16
C/C++の依存関係管理という地獄へようこそと言いたい。Make?cmake?qmake?conf?autoconf?configure?autotools?サブモジュール???うわあああああああああああ
C/C++の依存関係管理という地獄へようこそと言いたい。Make?cmake?qmake?conf?autoconf?configure?autotools?サブモジュール???うわあああああああああああ
>>29
自分ならツールを一つ選んで、必要なライブラリをコードベースにベンダリングして終わりにする。Eigen、liboption++、Catch2、Easylogging++(残念ながら今はアーカイブされてメンテもされていない)でそうしてきた。シンプルなmakefileを組めば、あとはそれで十分動く。少なくとも自分のケースではね。
自分ならツールを一つ選んで、必要なライブラリをコードベースにベンダリングして終わりにする。Eigen、liboption++、Catch2、Easylogging++(残念ながら今はアーカイブされてメンテもされていない)でそうしてきた。シンプルなmakefileを組めば、あとはそれで十分動く。少なくとも自分のケースではね。
>>16
まさにその通りだと思う。Rustは結局のところ『どっちがすごいか』を張り合うだけの世界で、だから自分は絶対に使わない。
まさにその通りだと思う。Rustは結局のところ『どっちがすごいか』を張り合うだけの世界で、だから自分は絶対に使わない。
>>30
『張り合うだけの世界』?何言ってるんだ、ただのプログラミング言語だろう。嫌なら依存関係ゼロでやればいいし、全部ベンダリングしてもいい。誰もサードパーティの依存関係を使えと強制してるわけじゃない。
『張り合うだけの世界』?何言ってるんだ、ただのプログラミング言語だろう。嫌なら依存関係ゼロでやればいいし、全部ベンダリングしてもいい。誰もサードパーティの依存関係を使えと強制してるわけじゃない。
>>19
Rustは実際、標準ライブラリにどんどん機能を取り込んでいってる。このクレートの機能自体は2024年から標準ライブラリに入っている。エコシステム側の移行が遅いだけだ(全部がメンテされているわけじゃないし)。
Rustは実際、標準ライブラリにどんどん機能を取り込んでいってる。このクレートの機能自体は2024年から標準ライブラリに入っている。エコシステム側の移行が遅いだけだ(全部がメンテされているわけじゃないし)。
>>31
Rustはゴミ
Rustはゴミ
>>21
外部依存を一切使わない実用的なPythonやGoのプロジェクトなんて見たことがない。同程度の規模のGoとRustのプロジェクトなら、依存関係の量は同じくらいだと思う。
外部依存を一切使わない実用的なPythonやGoのプロジェクトなんて見たことがない。同程度の規模のGoとRustのプロジェクトなら、依存関係の量は同じくらいだと思う。
>>21
全く同感だ。セキュリティを本気で考えるなら、Goの採用を検討すべきだと思う。
全く同感だ。セキュリティを本気で考えるなら、Goの採用を検討すべきだと思う。
>>27
『そのセキュリティ監査は誰が費用を出すんだ?みんな無償のボランティアでやるものなのか?』というけど、Rustプロジェクト全体を支えているのと同じ人たちがやればいい。その多くはボランティアじゃないのか。少なくとも中核的なパッケージについては、同じことができてもおかしくないと思う。
『そのセキュリティ監査は誰が費用を出すんだ?みんな無償のボランティアでやるものなのか?』というけど、Rustプロジェクト全体を支えているのと同じ人たちがやればいい。その多くはボランティアじゃないのか。少なくとも中核的なパッケージについては、同じことができてもおかしくないと思う。
>>40
中核的なパッケージ(randやregexなど)は実際にはかなり厳しく監査されている(とはいえ認証情報の漏洩までは検知できないかもしれないが)。今回のクレートはそこには含まれていない。
中核的なパッケージ(randやregexなど)は実際にはかなり厳しく監査されている(とはいえ認証情報の漏洩までは検知できないかもしれないが)。今回のクレートはそこには含まれていない。
>>40
『Rustプロジェクト全体を支えているのと同じ人たちがやればいい、その多くはボランティアじゃないのか』というけど、自分の理解では、Rustプロジェクトは基本的に『ボトムアップ』で、ボランティアは自分がやりたいことをやるのであって、上位の管理者が采配できる時間のプールに参加しているわけじゃないと思う。
『Rustプロジェクト全体を支えているのと同じ人たちがやればいい、その多くはボランティアじゃないのか』というけど、自分の理解では、Rustプロジェクトは基本的に『ボトムアップ』で、ボランティアは自分がやりたいことをやるのであって、上位の管理者が采配できる時間のプールに参加しているわけじゃないと思う。
>>40
ボランティアの開発者集団に対して、追加の報酬や見返りも無しに今の何倍もの作業をやれと期待するのは、正気の沙汰じゃないし、あまりにも図々しい。
ボランティアの開発者集団に対して、追加の報酬や見返りも無しに今の何倍もの作業をやれと期待するのは、正気の沙汰じゃないし、あまりにも図々しい。
※本記事は5ch(Hacker News)スレッド「Malicious Rust Crate Arrayref Runs a Build-Time Payload」より抜粋・要約して構成しています。
まだコメントはありません。