AUR が攻撃された背景—リポジトリの設計上の課題

「AUR」（Arch User Repository）は、Arch Linux の公式リポジトリには未登録のソフトウェアを配布するコミュニティドリブンなリポジトリです。Arch Linux の公式リポジトリである core や extras は開発者やメンテナーが厳格に監査していますが、AUR はこれとは異なります。

AUR に登録されるパッケージは、メンテナーによる形式的な審査プロセスを経ていません。

AUR に登録されるパッケージは、メンテナーによる形式的な審査プロセスを経ていません。ユーザーがソースコードから構築するための PKGBUILD ファイルが保管されており、現在 107,000 以上のパッケージが登録 されている状況です。そのうち約 14,000 パッケージが孤立した状態（メンテナーがいない） にあり、誰でも引き継ぐことができる設計になっています。

登録ユーザー数は 141,000 人以上 に及びますが、新しいパッケージの採用やアップデートに対して、AUR の運営側による実質的な検証はありません。ユーザーは「このリポジトリのファイルは完全に非公式であり、十分に精査されていない」という警告が示されているものの、実際には PKGBUILD の内容を一つひとつ確認してからインストールするユーザーは少数派ではないでしょうか。

今回の攻撃—「Whac-A-Mole」の状況に

攻撃者（複数の可能性もある）は、以下の流れで被害をもたらしました。

  • 複数の新規アカウントを作成
  • 孤立していたパッケージの所有権を次々と奪取
  • マルウェアをインストールする悪意ある更新をプッシュ

AUR の運営チームはこれに対して数日間にわたって対応を続けましたが、攻撃のペースに追いつくのが精一杯だったと報告されています。この「モグラたたき」的な状況は、AUR の設計上の脆弱性がいかに深刻かを示しています。

具体的な被害ユーザー数は不明とされていますが、AUR の利用者数の多さを考えると、潜在的な影響は非常に大きい可能性があります。

AUR の脆弱性の本質—信頼モデルの崩壊

項目 Arch 公式リポジトリ AUR
パッケージの審査 厳格に実施 なし
バイナリの提供 あり なし（PKGBUILD のみ）
メンテナーの確認 あり ユーザー自身に委ねられる
登録時の制限 管理者のみ 広く開放

AUR は「ユーザーが自分でコードを確認できる」という前提で、ほぼ完全にオープンな寄稿モデルを採用しています。

AUR は「ユーザーが自分でコードを確認できる」という前提で、ほぼ完全にオープンな寄稿モデルを採用しています。これはオープンソースコミュニティの理想を体現したものですが、実際には多くのユーザーが PKGBUILD の内容を十分に検査せずにパッケージをインストール・アップデートしているのが実情です。

さらに問題なのは、AUR が提供する -bin ファイル形式です。これはソースコードではなく、外部からダウンロードしたプリビルド済みバイナリをインストールする仕組みです。便利である一方、ユーザーが内容を検証するすべがなく、攻撃者にとっては理想的な悪用経路になります。

対応策として、AUR は一時的に新規ユーザー登録を停止しました。しかし、長期的な解決策はまだ定まっていません。運営チームはこの「協調モデル」を維持しながら、どのようにセキュリティを強化するかの課題に直面しています。

エンジニアにとっての教訓—信頼の検証の重要性

Linux ユーザーやシステムエンジニアの方が AUR を利用する場合、今回の事件は他人事ではありません。特に自動更新やヘルパーツール（paru や yay）を使ってアップデートを自動化している場合、悪意あるパッケージが知らぬ間にインストールされるリスクがあります。

一方で、この事件は AUR に限った話ではないと考えます。npm、PyPI、Cargo などのパッケージリポジトリも同様の脆弱性を抱えており、過去にも悪意のあるパッケージが流通した事例があります。サプライチェーン攻撃（supply-chain attack）が現実の脅威として認識されるようになった背景には、こうした事例の積み重ねがあります。

インフラエンジニアの方が GCP や AWS でコンテナ化されたワークロードを運用する場合でも、ベースイメージやライブラリの出所を意識することが重要です。同じ原理です。

（出典）