Red Hat Cloud Services全体で悪意のあるnpmパッケージが発見

 (github.com/RedHatInsights)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • この問題は 未解決 の状態であり、本文時点では担当者・マイルストーン・関連ブランチやPRはない
  • @redhat-cloud-services/ スコープの複数の npmリリース で悪意のあるバージョンが発見されたというセキュリティ問題として登録されている
  • 参考資料として、StepSecurityの分析記事とOSS Security Feedの検索結果が示されている
  • 更新された影響リストには、@redhat-cloud-services/chrome、frontend-components、rbac-client、types、vulnerabilities-client など 32個のパッケージ が含まれる
  • 表に記載された侵害バージョンは大半が各パッケージあたり3件で、@redhat-cloud-services/vulnerabilities-client には 2.1.9、2.1.11 の2バージョンのみが含まれる
  • 表全体の基準では侵害されたバージョンは 95件 と集計でき、別途言及された外部PRのタイトルも 95 versions を指している
  • @redhat-cloud-services/frontend-components-* 系列と複数の *-client パッケージがあわせて含まれており、単一パッケージではなく同一スコープ全体のリリース問題となっている
  • コメントでは「What are these?」という質問に対し「all that module is pwned」という回答が付き、リスト全体が侵害されたという理解が共有されている
  • DanielRuf はこの件を supply-chain-incidents に追加したと記している
  • GitHub上の活動には、この問題を参照したコンテンツ要約と検出関連PRが見られるが、本文にはRed Hat側の診断・緩和措置・削除の有無・修正版はまだ示されていない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • クールダウン設定の話でスレッドをもう一度借りても大丈夫だとよいのですが。axios、tanstack、@redhat-cloud-services、そして最近のさまざまな npm サプライチェーン攻撃は、クールダウンがあれば防げていたはずです
    Artifactory/Nexus を使っていればすでにある可能性が高く、なくても設定は簡単です。npm や PyPI の侵害の大半は数時間以内に取り下げられたので、リリースから N 日未満のパッケージを無視する方式で十分です。1日でも効果があり、3日なら妥当、7日はやややりすぎですが機能します
    最新の pnpm はデフォルトで 1 日のクールダウンを入れています: https://pnpm.io/supply-chain-security
    ワンクリックで済ませたいなら https://depsguard.com を使えます。npm、pnpm、yarn、bun、uv、dependabot にクールダウンと推奨設定を追加する CLI で、私がメンテナです
    クールダウンにより特化した https://cooldowns.dev もあり、ローカル設定を支援するスクリプトもあります。どれもオープンソース/無料です
    ~/.npmrc などを自分で編集できるなら必須ではありませんが、身近にワンクリック修正だけ必要な人がいるなら、次の攻撃を避ける助けになるかもしれません
    ただし、新たな重大 CVE を修正しなければならないときはクールダウンを迂回する必要があり、各ツールにはその方法があります。ここ数か月の正確な数字はありませんが、Mythos 的な脆弱性発見の時代であっても、新しいゼロデイ CVE より 悪意あるバージョンの配布 のようなソフトウェアサプライチェーン攻撃のほうがリスクは大きく見えます

    • 組み込み開発者として、ツールチェーンや依存関係を何年も固定することに慣れているので、Web 開発文化は多くの面で衝撃的です
    • sane で少し安全な設定方法をまとめた友人の GitHub リポジトリがあります: https://github.com/jordanconway/package-manager-hardening
    • Docker/Podman イメージの pull にも クールダウンを入れる合理的な方法はあるのでしょうか?
    • ~/.npmrc ファイルを開いて 1 行追加できる人であっても、ワンクリック修正が必要な場合はとても小さな集団のように感じます
    • クールダウンに加えて、より多くのパッケージマネージャーが セキュリティ修正 と通常のリリース（バグ修正/性能改善/新機能）を区別して扱うようになるとよいと思います
      「セキュリティ修正にはセキュリティ修正だけを含め、他の機能を載せてはいけない」と言うのは十分可能です。そうなればセキュリティ研究者もツールも監査しやすくなります
      通常のリリースにはクールダウンを適用し、セキュリティ修正にはクールダウンをなくすか、もっと短くできます
      Debian のように非常に安定したサーバーを置き、unattended upgrades をセキュリティ修正のみに適用するよう設定できる仕組みは参考になります。このような新しいパッケージリリースは、セキュリティ研究者が監査するのもより容易です

  • こうしたスレッドでは、この種の攻撃があたかも npm にしか存在しないかのように振る舞ったり、何の対策もなかったかのように皮肉るコメントが多いが、それは公正ではないと思う
    delay line や pnpm など、パッケージ利用者を保護するために導入された優れた機能に言及するコメントも多い
    あまり語られていないのは、パッケージメンテナ側のツールだ。公開時の MFA: https://docs.npmjs.com/requiring-2fa-for-package-publishing-...、約1年前から提供されている trusted publishers: https://docs.npmjs.com/trusted-publishers
    最近では、両機能の利点を組み合わせた staged publishing も登場した: https://docs.npmjs.com/staged-publishing
    これにより、静的な認証情報なしで CI から公開し、レジストリで実際に公開される前にメンテナが MFA で承認することを必須にできる。必要なら GitHub Actions Environments の保護によって、CI 側で複数承認や時間遅延も要求できる
    コミュニティがこうした公開保護策を採用するよう促すべきであり、そうでなければこの問題は続くだろう

    • [1] によれば、「影響を受けたすべてのパッケージは RedHatInsights/javascript-clients リポジトリから GitHub Actions OIDC を通じて公開されており、これは上流の CI/CD パイプライン自体が侵害されていたことを示している」という
      そうなると、悪意あるパッケージにも緑の星が付き、利用者に「出所証明付きでビルド・署名されています」と安心させてしまったはずだ
      [1] https://lwn.net/Articles/1075742/
    • 起き続けているので、滑稽ではある。npm 攻撃はカレンダーに印を付けられるほどで、誰かが The Onion の古典的な「避ける方法がない」という記事の npm 版パロディまで作っていた
      防ぐための取り組みが進んでいるのは素晴らしいが、それでも起こり続ける。「またか」と思う意味で滑稽だ
    • 全員に必須にして初めて、何かしたと言える
    • 機械的な変更にはあまり感心しないし、この問題を 文化的な問題 と見る人たちがいるように思う
      外から見ると、ウェブ開発には無秩序なフロンティアのようなエネルギーがある。可変性、動的型付け、変わり続ける標準やフレームワーク、継続的デプロイ、CDN、リアルタイム A/B キャンペーン、多数の依存関係、複数のインフラにまたがって散在する機微なユーザーデータがある
      この見方が正しいと言いたいわけでも、「だから言っただろう」という態度が正しいとも思わないが、そうした見方がどこから来るのかは理解できる
    • 私の考えでは、どちらも 豚に口紅 的な解決策だ。結局のところ、どれも「リリースの公開をもっと面倒にしよう」という変種でしかなく、人々に回避策を学ばせるだけだ
      特に、そのどちらも xz-utils バックドアがパッケージ公開に入り込むのを防げなかったはずだ。xz-utils は巧妙な上流侵害のベンチマークであり続けている
      ここでのバグは、すでに信頼している上流をもっと上手く認証すべきだということではなく、上流をセキュリティの唯一の源として信頼できないということだ。上流は、堅牢なリリースエンジニアリングにはあまり関心がなく、また得意でもないハッカーたちの集まりだ
      しかし、それを上手くやれる人たちもいる。Linux 世界の解決策であり、xz-utils で私たちを救ったやり方は、ハッカーが作った上流をユーザーのためにレビュー・監査・パッケージ化・カスタマイズする 第二の人間レイヤー があることだ
      この人たちは別の視点、別の利用者要件、別の品質基準を持っており、上流が見つける準備のできていないバグや悪意を見つけ出す
      NPM、cargo、PyPI などは、この人手の必要性を回避できると考え続けているが、実際にはできない。NPM エコシステムでは特に、非常に速いリリース、緩い互換性要件、極端な再利用に慣れたウェブ開発者が多く、それが Python や Rust よりも node パッケージでこうしたことが頻繁に見られる理由になっている

  • うちの会社では yarn 4 を使っているが、npm パッケージがリリースされてから最初の数日間はインストールを防ぐオプションがある。こうした攻撃の大半はその期間（1〜3日）内に見つかるようだ
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • いくつか提案がある。依存関係クールダウン を 1〜2 日入れるのは、CVE パッチ適用能力を損なわずに非常に効果的なようだ
    npm install、npm test のようにコードが実行される場所はすべて、権限のない環境で動かすべきだ。GitHub Actions では、アーティファクトをビルド・テストするジョブと、デプロイや署名などを行うジョブを分離すれば比較的簡単だ。AI を使うなら、このパターンを強制する skill/ガイドを追加すればよい
    GitHub Actions を使うなら、最新の zizmor を導入するとセキュリティ態勢が大きく改善する
    2 つ目の対策は、もはや「ワームのように伝播可能」ではなくしてくれるため、今の問題の大きな部分を減らせる。1 つ目は、企業が攻撃に対応する時間を稼いでくれる。この分野のいくつかのベンダーも評価する価値がある

    • zizmor が侵害されたらどうする？
      新しいパッケージは遅延すべきだと言った直後だったので、冗談として面白かった
    • こうしたクールダウンの代わりに 隔離されたコンテキスト でビルドを実行すればよいのでは？
      ローカルで Maven プロキシを動かし、すべてのビルドはコンテナ内で行う。Python、npm、Go は公開リポジトリしか使わないので、これらのビルドもコンテナ内で行うが、リポジトリプロキシは不要
    • コードが実行されるあらゆる場所という意味なら、codex や claude-code のような エージェント型オーケストレーター はデフォルトでそうしているようだ

  • Red Hat と IBM がサプライチェーン脆弱性の検知・修正を支援する Project Lightwell を発表したのと同じ日だね
    https://www.redhat.com/en/lightwell

  • 数日前にこの興味深い rant を見た: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    正しいやり方は、使うすべての依存関係をフォークし、必要に応じてアップストリームをレビュー・マージしながら自分のリポジトリからインストールすることだ、という話には一理ある。ただ、ものすごく面倒そう

    • 自動化できない話ではない。Go の世界ではこれを vendoring と呼べるかもしれない: https://go.dev/ref/mod#vendoring
      サードパーティの依存関係ホスティング事業者への依存を減らしたりなくしたりでき、依存関係を自分たちのコードレビュー手段の中に取り込み、長期的に 再現可能なビルド を保証するのに役立つ
    • 問題は、依存関係の依存関係、さらにその下へと何段階にも続いていくこと
    • CLI で依存関係を簡単に監査するために Packj を作った
      Packj(https://github.com/ossillate-inc/packj) は、挙動分析によって悪意のある PyPI/NPM/Ruby/PHP などの依存関係を検出する。静的・動的コード分析で、シェル実行、SSH キー使用、ネットワーク通信、decode+eval の使用といった侵害の指標をスキャンする。タイポスクワッティングのような悪意ある行為者を見つけるために、複数のメタデータ属性も確認する
    • 確率は変えられるかもしれないが、真面目にフォークして今後のすべての脆弱性に monkeypatch し続けない限り、侵害されたフォーク を永遠に配布し続けることになるかもしれない
    • パッケージは最新版にしておくだけでなく、バージョン番号も制限すべきでは?

  • 1週間ほど前にノートPCから Node を消して、気分が良かった
    運悪くエクスプロイトを踏んでも被害範囲を減らせるように、すべての作業を 開発コンテナ や別のサンドボックスでやるようにしている。攻撃者が Claude トークンを盗める可能性はあるが、コンテナを簡単に脱出してホームディレクトリを漁ることはできないはず
    クールダウンとインストールスクリプトの許可リストは、特に CI において多層防御のための良い追加策だ。ただ、根本的に変わるべきなのは OS の権限モデルだと思う。サードパーティソフトウェアをユーザー権限まるごとで信頼するというデフォルトは、もはや機能していない

    • Bubblewrap/Firejail/Flatpak のようなものを使っているのか、あるいはそういう設定がどんな形なのか気になる。似たような考えをしばらく温めてはいるが、まだ実行には移せていない

  • 元の発表へのリンクを貼っておくべきだと思う
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • そう。あとタイトルでは Red Hat の綴りも間違っている

  • パッケージをインストールするとき、今では --before=2026-05-30 フラグを使う癖がついた。指定した日付より前にリリースされたバージョンを選ばせるもので、たいてい 5 日前くらいを指定する

    • npm 11 を使うなら min-release-age を 5 に設定して、流れを単純化できる
      https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
    • 自分は pnpm を使っていて、余裕を持った minimumReleaseAge を設定している
      https://pnpm.io/settings#minimumreleaseage
      幸い v11 からはデフォルトで有効になっている
    • 素の npm (v11.10.0 以上) を使うなら、プロジェクトルートの .npmrc に単に min-release-age=5 を追加すればいい
    • Yarn 4 ならこれを自動化できる

  • NPM は設計段階から壊れていて、コミュニティに蔓延する NIH 症候群のせいで単純な対策すら取れなくなっている

    • 2つ目の文はよく分からない。npm は「Not Invented Here」の逆の問題では?
      自前で作る代わりに外部パッケージを大量に受け入れるせいで、npm プロジェクトは大きく複雑な依存関係ツリーを持ちがちだ。https://www.npmjs.com/package/is-windows のようなパッケージは、同じコードを自分で書くのがあまりに簡単なのに、潜在的な脆弱性と保守上の頭痛の種を生むという不満が昔からあった
    • NIH 側でよくある誤りは、X パッケージを作り直すのに多くの時間がかかると思い込むこと
      しかし当然ながら、全機能を作り直す必要はなく、必要な機能だけを作ればよい
      しかも機能を1つだけコーディングするなら、抽象化や追加の関数インターフェースを作る必要もない。だから安上がりで、おそらく統合もうまくいく
      もう1つの誤りは、バグや脆弱性を生むだろうと思い込むこと。下手なプログラマーならそうかもしれないが、互いに正確に噛み合うよう設計されていない2つのライブラリの統合境界で生じる脆弱性の類は避けられる。そういうケースは多い