Arch Linux、マルウェア事故は収束と判断: 1,500超のパッケージに影響
(phoronix.com/news)- Arch Linux の AUR ユーザー投稿リポジトリでマルウェアに感染したパッケージが当初 400超確認された後、最終的に 1,500超へと増加
- 数時間前の更新では、今週の事故で感染したパッケージは約 900件と把握されていた
- その後、Arch Linux 開発者は把握していた 悪意あるコミットをすべて削除し、影響を受けたパッケージ数は 1,579件と集計された
- 1,579件の一覧も、影響を受けたパッケージの 多くを含むが全件ではない一覧とされており、全体の範囲はさらに大きい可能性がある
- ユーザー管理リポジトリ内の多くのソフトウェアが今回の セキュリティ事故の影響を受けており、別の更新では、より巧妙化したマルウェア攻撃が再び発生したとされている
事故の概要
- Arch Linux ユーザー向けの AUR ユーザー投稿リポジトリで、マルウェアに感染したパッケージが 400超見つかり、事故が始まった
- 1日の終わりごろ、Arch Linux 側は影響を受けたコミットはすべて対処済みと判断したが、影響を受けたパッケージ数は 1,500超に増加した
- 今回の事故は、ユーザー管理の Arch Linux リポジトリ内の多くのソフトウェアに影響を与えた セキュリティ事故だった
影響範囲の変化
- 数時間前の更新では、今週の事故で約 900件のパッケージがマルウェアに感染したと把握されていた
- その後、セキュリティ事故スレッドの最後のメッセージ時点で、Arch Linux 開発者は把握していた悪意あるコミットをすべて削除した
- 引用された一覧では、マルウェアの影響を受けたパッケージ数が 1,579件と示されている
残る不確実性
- 1,579件のパッケージが示された一覧も、「影響を受けたパッケージの多くを含むが全件ではない一覧」とされている
- したがって、公表された数字は確認された大規模な影響範囲を示しているものの、一覧自体が全パッケージを網羅しているわけではない
続報
- 別の更新では、Arch Linux AUR がさらに巧妙化したマルウェア攻撃の別の波に見舞われたという内容が続いている
1件のコメント
Hacker Newsの意見
AURチームが事後分析を出したことがあるのか気になる
今回の対応は印象的なほど速かったが、率直に言ってAURのポリシーであれラッパーであれ、何らかの変更が必要に見える
pnpmのようにパッケージの最小経過日数を設定できるべきだし、孤児パッケージを誰でも引き取れるようにしてはいけない引き取りにはグローバルなレート制限を設けて攻撃シグナルとして利用することもできるし、NPMで複数の企業がやっているように公開時の脆弱性スキャンも必要だ
ただし、こうした変更の大半はAURメンテナーよりも、パッケージングヘルパーや第三者側が担うべき仕事に近い
そうすれば所有権が消えず、孤児化そのものが不要になる
pnpmに着想を得て、pakkuにAURの最小経過時間を設けるパッチ[1]を最近作ってみた[1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
[2] https://github.com/zqqw/pakku
制限は必要だが、たとえば一定期間前に登録したユーザーに月1件の引き取りまで認める程度が妥当に見える
どうせローカルにインストールされたAURパッケージへ自動・無審査アップデートを適用する人はいないだろうから、攻撃面はすでにかなり小さい
miasmaワームの本質は、署名とヘルパーの手口があまりに速く変化する点にある
暗号化された悪性インプラントは、アップロードされたGitHub上の配置ごとに異なるAES-128-GCMキーでペイロードを復号し、コードのメソッド名も動的に変化し、暗号化されたシンボルオフセットも混ぜて再利用する
変異型マルウェアなので、シグネチャベースのツールにとっては最悪の相手だ
APT28/29は、GitHubでC2インフラとして使われるユーザーやリポジトリをMicrosoftが自動遮断する速度の遅さに、ある程度依存しているように見える
これがセキュリティ戦略に何を意味するのか考える必要がある
署名や文字列をスキャンできる頃には、すでに完全自動化されたボットネットとのいたちごっこになっており、勝ち目はない
この1週間、このインプラントの変化を追えていたサプライチェーンツールはsocket.dev程度しかなく、他のツールはMiasmaを認識しないまま新たなキャンペーンとして再発見していた
新しいエコシステム向けアダプターが24時間ごとに出てくる速度に追いつけるほど、ペイロードを素早くリバースエンジニアリングする人員とツールチェーンが不足していた
ここでいう完全自動化とは、別のパッケージエコシステムでは48時間も経たないうちに盗まれた認証情報がすでに使われている、という意味だ
メールアドレスと名前が繰り返し現れるが、これはこの自己伝播型ワームの影響を理解していない可能性が高い人たちに見える
たとえば
bunに依存するパッケージを探す侵害指標も、大きな助けにはならないマルウェアは外部手段で再ダウンロードすれば済むからだ
2回目のPyPIキャンペーンでは、RedHatキャンペーンの最初の悪性ドロッパーの波がPyPIメンテナーに表示された後、圧縮されたWHLファイルと自動実行される
setup.pthファイルでドロッパーを取得する方式に変わったこれらのエコシステムのパッケージマネージャーが、
chroot、サンドボックス、ネットワーク・ドメインログ、項目ごとの許可リストを前提に一から書き直されない限り、サプライチェーン攻撃によるマルウェア配布戦略は今後も現実的であり続けるだろう緩和ツールのリポジトリは[1]で、技術的な詳細はブログ記事[2]にある
Composer、Rubygems、NPM、PyPI、Goもすべて影響を受けるなど、あらゆるパッケージマネージャーにまたがる問題だ
パッケージマネージャー全般にどれほど多くの不注意と外部への信頼を積み上げているのか、もっと公に議論すべきであり、これは本当に変える必要がある
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/weblog/articles/malware-insights-mia...
AURから直接インストールできるpacmanラッパーが出始めたとき、本当に不快だった
AURから何かをインストールしたことはあるが、たいていは中間段階を飛ばしてプロジェクトのWebサイトへ直接行くほうを好む
あらかじめ用意されたPKGBUILDは、タイポスクワッティングやnpm・pip依存関係の悪用リスクを引き受けるほど便利ではない
yayのようなラッパーは、更新のたびにPKGBUILDの差分を表示する最初のインストール時にURLを確認し、インストールスクリプトなどが妥当かを見るし、その後の更新では大半がバージョン番号とチェックサムの変更だけだ
タイポスクワッティング攻撃ならかなり明白に現れるはずだ
最初のインストールにはやや弱いが、プロジェクトのWebサイトに行ってダウンロードを押す方法も同じことだ
人生のさまざまな面でも同じだ
Void Linuxを使った後、Archでも同様の分離のために
aurutilsへ切り替えた自前でビルドしてローカルAURリポジトリを簡単に維持でき、
pacmanでインストール・管理できるので、全体のアップグレード作業が改善されるLinuxへ移った理由は、WindowsユーザーのようにWebサイトへ行って「download」を押し、プログラムの更新に時間を浪費するためではなかった
ただ、挙げられている
pacmanラッパーは危険に見えるこうしたリポジトリを使うチュートリアルがあまりに広く出回っているので、ほとんど同僚レビューもない見知らぬ人に無期限のroot権限を与えたくない自分のほうが変人のように感じるほどだ
更新が不要か、あっても稀なパッケージの1バージョンをインストールするために、そんなリスクを負っているわけだ
ざっと読んだところ、npm から
atomic-lockfile、js-digest、lockfile-jsをインストールしていたように見える影響を受けたパッケージの一覧は [1] にある
システムの確認方法をすぐには見つけられなかったので、外部パッケージと日付に関する情報を探すために
pacman -Qmiを実行した出力結果を影響を受けたパッケージ一覧と照合すればよい
また、複数の場所で次のようにファイルを検索できる
grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"grep -rl "atomic-lockfile" ~/.npm 2>/dev/nullgrep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null実行後にパッケージが自分自身を削除するかどうかは分からない
他の情報はあまり役に立たなかったので、せめて基本的なコマンドだけでも共有したかった
[1] https://md.archlinux.org/s/SxbqukK6IA
yayで AUR 由来のインストール済みパッケージ一覧を取得する:yay -Qam > packages_aur.lasthttps://md.archlinux.org/s/SxbqukK6IA# から一覧を取得する:
curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txtその後
grep -wFf compromised.txt packages_aur.lastを実行すれば、両方のファイルに含まれる、つまりある時点で侵害されていたパッケージが出てくるはずatomic-lockfileだけを確認しても不十分js-digestとlockfile-jsも使われており、ある時点では npm ではなく bun に切り替えていた伝説的なプラットフォームだ
emacs-magitがどうして影響を受けたのか分からない自分の知る限りでは JavaScript はまったくない
レビューなしに任意のサードパーティ製パッケージ・ライブラリ・アプリケーションをインストールしないようにという、いつものもっともな注意喚起でもある
幸い今回の件は AUR に限定されており、AUR は実質的に誰でも投稿できるパッケージリポジトリで、公式リポジトリと違ってインストール前の確認が必須だと何度も警告されてきた
ruaのようなコマンドラインツールは、AUR からインストールする前にパッケージを確認しやすくしてくれる同じコンピュータで銀行業務をするなら、依存しているソフトウェアを確認しない言い訳はない
パッケージ数を少なく保ち、本当に必要なものだけを使えば、アップグレード時もずっと単純になる
インストール前にコードを一行残らず全部読めという意味か
バイナリパッケージならどうするのか
インストールするものすべてについて 再現可能ビルド を作れというのか、それともソースベースのディストリビューションに移れというのか
この責任をユーザーに押しつけるのは持続可能な解決策ではない
常識の入る余地はあるが、これをユーザーのせいにするのは筋が通らない
世の中には、一人の人間が一生で読める量をはるかに超えるコードがある
本人ですら、自分のコンピュータで今動いているソースコードの 1% も読んでいない可能性が高い
ではコンピュータの使用をやめたのか
その中で起きていることをどうやって信頼できるのか
Arch Linux 開発者たちは素晴らしい仕事をしていて個人的にも感謝しているが、こうしたサプライチェーン攻撃がこれほど増えている今となっては、ユーザーへの警告 だけではとっくに限界に達していると感じる
簡単な解決策は見当たらないが、公開前のピアレビューや猶予期間のような統制で、問題をある程度は緩和できるかもしれない
パッケージを孤児化としてマークし、2 週間待ったあと元のメンテナーが休暇中で応答できなければ、攻撃者がメンテナーに割り当てられて悪意あるアップデートを配布できるというのはおかしい
immutable なディストリビューション、Wayland、Flatpak にその一部はあるが、重要な穴が残っている
最大の問題は、サンドボックス化がパッケージ形式に結び付けられている点で、これは間違いだと思う
サンドボックス化とアクセス権はシステムレベルの機能であるべきで、任意のバイナリでも簡単に抜け道を使えないようにしなければならない
問題を完全に解決できなくても、被害範囲を大きく減らし、ディストリビューションのユーザーを魅力の低い標的にできる
心配している人向けに、最新のスクリプトとパッケージ一覧をまとめて感染有無の確認に役立つリポジトリを見つけた: https://github.com/lenucksi/aur-malware-check
どちらでも十分だと思う
Arch Linuxユーザーではないが、NodeJSはよく使っていて、こちらでも似たような攻撃が頻繁に起きている。
最近、パッケージ管理をきちんと安全にやれている場所はどこなのか気になっている
今回のような大規模なものではなかったが、そもそも安全ではないことは明らかで、あちこちに危険警告が付いていた
どこもパッケージをレビューし、責任を持つメンテナーがいる。
Arch Linuxも同じ。
AURの本質的な非信頼性はArch Wikiや周辺文化の中で常に明示されており、npmやpipのようなプログラミング言語のパッケージマネージャーとは異なる
AURを使うなら全部確認しなければならない。
ほとんどのディストリビューションも問題なく、大手ディストリビューションはかなり良い実績を持っている
過剰なDRY文化のせいかもしれないし、別の理由かもしれない。
自分が使った中では、これほどの依存関係ツリーの悪夢に近いものはなかった
AURには孤児パッケージが1万5千個ある。
今朝、人気順で並べてほとんど更新されていない3つを引き取ってビルドした。
孤児パッケージを使っているなら、悪意ある人に取られる前に自分で引き取ることを検討してもよい
間違っているかもしれないが、今回の状況はデスクトップLinux採用の増加の兆候のようにも見える
AURが必要だったことはない。
公式リポジトリにないパッケージが必要なら、自分でビルドするか、バイナリリリースがあればそれをダウンロードする。
こうすればビルド時にrootを使う必要がなく、プログラムを単一ユーザー向けにローカルインストールできるので、たいていのデスクトップ用途にはむしろ合っている。
少なくとも開発者 → ユーザーの経路に比べれば、開発者 → メンテナー → ユーザーという一段階分の悪意あるコード挿入の可能性が減る
makepkgはrootで実行すると積極的に拒否する。わざわざ
env EUID=123 makepkg ...のように回避しない限り、rootでは動かない。ただ、pacmanがユーザーレベルのインストールをサポートしてくれるとよい。
現状ではrootでなければインストールを拒否するが、ユーザー名前空間で自分自身をrootにマップする形で回避はできる
今回がAURだったのは理解できる。
AURかどうかに関係なく、パッケージをインストールするときにどんな手順を踏んでいるのか、インストールしようとしているパッケージや依存関係がマルウェアではないことをどう保証しているのかを共有してもらえるとありがたい。
悪いパッケージをインストールしてしまうと、本当に元に戻すのが難しそうに見える