7月に予定されるこの変更は、よく使われる攻撃ベクターの一つを封じると見られています。開発者たちは、なぜGitHubがここまで時間をかけたのか、また他のリポジトリがなぜもっと早く行動したのかを疑問視しています。
npmにおける自動インストールスクリプト実行を攻撃者が悪用できる状況が、7月にGitHubから予定されている変更によってついに終止符を打たれます。開発者はこの機能を引き続き有効にすることができますが、デフォルト設定ではブロックされるようになります。
GitHubはChangelog上でV12においてデフォルト設定が変更されると発表し、「現在は自動的に実行されるnpm installの動作を、明示的にオプトインする必要があるものに変えます」と説明しています。
具体的には、「allowScriptsのデフォルトがオフになります。npm installは、プロジェクトで明示的に許可されていない限り、依存関係のpreinstall、install、postinstallスクリプトを実行しなくなります。これにはネイティブのnode-gypビルドも含まれます。binding.gypを持ちながら明示的なインストールスクリプトを持たないパッケージも、npmが暗黙的にnode-gyp rebuildを実行するためブロックされます。git、file、link依存関係のprepareスクリプトも同様にブロックされます」と説明されています。
アナリスト、コンサルタント、ユーザーからはこの変更を歓迎する声が相次いでいますが、サプライチェーン攻撃へのエクスポージャーを排除するのではなく、縮小するにとどまるという見方も示されています。
攻撃の矛先は別の経路へ
OWASPインキュベータープロジェクトのCVE Lite CLIメンテナーであるSonu Kapoor氏は、自動実行を悪用したサプライチェーン攻撃は、この変更によって別の経路へと移行せざるを得なくなるだろうと述べています。
「これはnpmのサプライチェーンリスクを排除するものではなく、主要な自動実行パスを取り除くものです」とKapoor氏は語っています。「攻撃者はほかの経路に移行できます。アプリケーションの実行時に動作する悪意のあるパッケージコード、メンテナーアカウントの侵害、依存関係の混同、タイポスクワッティング、汚染されたGitHub Actionsワークフロー、悪意のある推移的依存関係、または盗まれた公開トークンなどです。これで非常に危険な扉の一つは閉まりますが、家全体のセキュリティが確保されるわけではありません。」
それでも、この設定を悪用した攻撃はサプライチェーン攻撃において常套手段となってきました。
一方、セキュアな医療機器企業Threat Detectiveのディレクターを務めるAlan Parkinson氏は、より高度な攻撃者はすでにこの脆弱性を超えた手法に移行していると指摘しています。
「インストールスクリプトの攻撃ベクターは、何年も前から知られています」とParkinson氏は述べています。「ほとんどのセキュリティチームはこれをリスクの低いものとして扱い、より高リスクの脅威への対応に移っていました。この問題が注目を集めるようになったのは、技術的な悪用可能性が変わったからではなく、著名な被害者が続出し、一部の脅威アクターが公然と名声を求めるようになったからです。」
同氏はさらに、「preおよびpostインストールスクリプトはそもそも洗練された攻撃ベクターではありませんでした。インストールフックからコードを実行することは粗雑で目立ちやすく、それが大きな被害をもたらした理由でもあります。より高度な攻撃者はすでに別の手法に移行しているため、v12が主に阻止するのは、それほど高度でない脅威アクターです」と付け加えています。
GitHubはインタビューの要請を断りましたが、GitHubのプリンシパルエンジニアであるZach Steindler氏がメールで質問に回答しました。同氏は、サプライチェーン攻撃の件数と速度の増加が、デフォルト設定の変更を余儀なくさせたと述べています。
「攻撃者がこれらの機能を標的にして、一つの侵害されたパッケージから多数へと攻撃を素早く伝播させる事例を目にしてきました。何年にもわたるセキュリティとユーザビリティの研究から、安全な機能を利用可能にするだけでは不十分であることが分かっています。広く採用されるためには、安全な経路がデフォルトでなければなりません」とSteindler氏は述べています。
同氏はまた、「これらの変更は、影響の大きいセキュリティのデフォルト設定を提供しつつ、状況によっては必要な機能に頼れるオプションを一部のユーザーに残す優れた方法だと考えています」と付け加えています。
遅すぎた変更
Greyhound Researchのチーフアナリスト、Sanchit Vir Gogia氏は、GitHubがデフォルト設定を変更した最後のリポジトリだったと指摘しています。「競合他社が先に動きました。Yarn、pnpm、Bunはいずれも独自の方法でサードパーティのインストールスクリプトをデフォルトでブロックしています」とGogia氏は述べています。「npmは新しい方針を打ち出しているのではありません。ようやく既存の方針を採用しているのです。」
Steindler氏はGogia氏のコメントに異論を唱えませんでした。
「世界最大のパッケージリポジトリの管理者であることは容易ではありません。どのセキュリティ機能を標準とすべきか、また破壊的変更を行うタイミングについてのコミュニティの合意は、時間の経過とともに変化します。コミュニティとの継続的な対話を通じて、今こそこの変更を行う時だと明確になりました」とSteindler氏は述べています。
「最近の攻撃は憂慮すべき事態です」と同氏は述べ、「しかし、パッケージリポジトリの管理は一時的な取り組みではなく、数十年にわたる継続的な努力を要します。攻撃が進化するにつれ、防御のセキュリティ能力も進化していきます。私たちは長期的な取り組みとして臨んでいます」と続けています。
Gogia氏は、この変更は遅きに失したものの、良い変更だと評価しています。
「npmは、ソフトウェアサプライチェーンリスクの最も居心地の良い隠れ場所の一つを取り除こうとしています。それは開発者がinstallと入力した瞬間に実行されるコードです」とGogia氏は述べています。「npm v12では、実行は承認され、プロジェクトに記録され、レビューのためにコミットされなければならないものになります。これは設計上の調整ではありません。コントロールの哲学における変化です。」
悪いデフォルトがインフラになる
Gogia氏は、GitHubがなぜこれほど長く待ったのかについて、独自の見解を示しています。
「npmが待ったのは、リスクのあるデフォルト設定が支持層を獲得したからです。2016年には早くも、npmの公式見解はインストールスクリプトの利便性がワームリスクを上回るというものでした。慎重派のためにオプトアウトフラグが用意されていました。このトレードオフは、見落としではなく、文書化された製品上の意思決定でした」と同氏は述べています。
「悪いデフォルト設定の問題は、それがインフラになってしまうことです」と同氏は続けています。「ネイティブモジュールのビルド、PlaywrightやCypressのようなブラウザインストーラー、Electronのダウンロードフロー、Huskyフックはすべて自動実行を前提に成長してきました。それをオフにすることは、技術的な調整というよりも、体制の改革になってしまっていたのです。」
責任の所在が変わった
しかし、変更への本当の圧力は規制当局からもたらされました。
「より深い答えは、責任の所在が変わったということです。EUサイバーレジリエンス法や証券開示規則のような規制によって、サプライチェーンの失敗が企業のバランスシートに影響を与えるようになると、文書化された安全でないデフォルト設定は弁護の余地がなくなりました」とGogia氏は述べています。
Kapoor氏も、長年使われてきた慣行がこのセキュリティホールを本来よりも長く存続させたという点で同意しています。
「これが長い間実施されなかった理由はおそらく互換性にあります」と同氏は述べています。「インストールスクリプトは攻撃者だけが使うものではありません。多くの正当なパッケージが、ネイティブモジュールのコンパイル、プラットフォーム固有のバイナリのダウンロード、ファイルの生成、またはセットアップ手順の完了のために使用しています。デフォルトを変更すると、npmエコシステムで長年存在してきた前提が崩れます。セキュリティ上の変更がしばしばゆっくりとしか行われない理由がここにあります。より安全なデフォルトはセキュリティの観点からは明らかですが、エコシステムの互換性の観点からは苦痛を伴うものです。」
さらに同氏は、「より重要な点は、パッケージマネージャーが暗黙的な信頼から明示的な信頼へと移行しているということです。それは正しい方向性です。開発者はインストール時にどの依存関係がコードを実行できるかを承認しなければなりません。しかし承認は盲目的なチェックボックスになってはいけません。チームはどのパッケージがスクリプトを実行しようとしているのか、それが直接依存か推移的依存か、なぜそこにあるのか、そしてそもそもそのプロジェクトに必要なものかどうかを把握できる必要があります」と指摘しています。
Kapoor氏はさらに、この変更が重要な理由として、インストール時の実行はトークン、シークレット、内部レジストリ、ビルド成果物、またはデプロイパスへのアクセスを持つ特権環境で行われることが多いためだと述べています。「スクリプトが本番環境を直接侵害しない場合でも、攻撃の次のステージを支援するのに十分なコンテキストを盗み出せる可能性があります」と同氏は述べています。
苦痛の中にある価値
サイバーセキュリティコンサルタントでFormerGovのエグゼクティブディレクターを務めるBrian Levine氏も、このセキュリティホールが閉じられることは非常に良いことだと同意しています。
「過去10年間のほぼすべての主要なサプライチェーン攻撃は、同じ原罪を持っているように思えます。それはエコシステムが許容したために自動的に実行されたコードです。npmがデフォルトでその扉をついに閉じることは遅きに失しましたが、真に重要な意味を持ちます。これは月に数千億ダウンロードを誇るパッケージマネージャーです」とLevine氏は述べています。
「npmがデフォルト設定を変更すると、世界中のほぼすべてのエンタープライズ開発環境のセキュリティ態勢が変わります。npmはこの種の自動実行を依然として許可していた最後の大規模コードリポジトリだったかもしれません。」
Levine氏はさらに、この変更は単にセキュリティホールを塞ぐだけでなく、新しいプロセスがセキュリティを実質的に向上させる可能性があると付け加えています。
「この移行の苦痛の中に、実は価値あるものが埋もれています。どのパッケージがコードを実行できるかを開発者が明示的に承認し、そのリストをソース管理にコミットすることは、多くの組織がこれまで持ち合わせていなかったソフトウェアサプライチェーンガバナンスの一形態です」とLevine氏は述べています。「それは監査可能な記録を生み出します。これは特に規制業界にとって大きな意味を持ちます。」
この記事はもともとInfoWorldに掲載されたものです。
