GitHub様、
さて、問題はこうです。しばらく前から公然の秘密となっているセキュリティ問題があります。人々はイシュートラッカーでそれについて話します。セキュリティ開示で取り上げられます。そして、最終的には「...しかし、GitHubが実際にそのデータを公開する必要があります。」という結論になるSlackスレッドで議論されます。
この件についてお伝えするのは、いつも同じように議論が終わるのを見るのにうんざりしているからです。セキュリティコミュニティは、すでに持っているデータへの可視性を求めているだけです。それがなければ、私たちは立ち往生してしまいます。パッケージレジストリはユーザーに警告できません。セキュリティツールは疑わしい参照を特定できません。一方、攻撃者はこの盲点を完全に理解しています。彼らはすでにそれをエクスプロイトしており、Shai Huludが行ったように。
休暇期間が近づいてまいりました。今年は十分に貢献できたと考えております。唯一の願いは、エコシステムをより良く保護するためのツールをご提供いただけることです。これは過度な要求ではないと願っております。
問題は何ですか？
npmのようなパッケージマネージャーは、BunやPyPIといったサードパーティと共に、開発者がGitHubリポジトリを直接依存関係としてインストールすることを可能にします。GitHub Actionsもこの同じプリミティブに依存しています。
npm install github:trusted-org/trusted-package#commit-sha
bun install github:trusted-org/trusted-package#commit-sha
pip install git+https://github.com/trusted-org/trusted-package#commit- uses: trusted-org/trusted-package@commit-shaほとんどの人はこれを見て、こう考えるでしょう。「セキュリティ上の問題はどこにあるのか？私はまさに正確なリポジトリを指定しているのに。」
ええ、私も同じことを思いました。
しかし、ここで何が起こるかというと、そのコミットSHAがリポジトリのフォーク に存在する場合、フォークからコードをプルすることになります。URL内のリポジトリからではなく、フォークから。一体どういうことでしょうか？
少し考えてみてください。少々お待ちください…。URLにはこうあります。 trusted-org/trusted-package。しかし、攻撃者がそのリポジトリをフォークし、悪意のあるコミットを追加して、そのコミットのSHAを参照させた場合、意図しないコードをインストールしてしまいます。指定したリポジトリのコードではなく、攻撃者のコードです。
なぜこのようなことが起こるのでしょうか？
これはGitHubの「Fork Network」が原因で発生します。
おそらく聞いたことがないでしょう。その仕組みはこうです。リポジトリをフォークしても、完全に独立したコピーが得られるわけではありません。フォークはネットワークに参加し、オリジナルのリポジトリや他のすべてのフォークと基盤となるGitオブジェクトストアを共有します。これがGitHubがスケーラビリティに対応する方法です。彼らは同じコミットを何百万も保存しているわけではありません。理にかなっています。
これがこの攻撃が機能する理由でもあります。
上記のコマンドは最終的にGitHubの「に到達しますリポジトリアーカイブ (tar) をダウンロード「」エンドポイント。ドキュメントには、これについて以下のように記載されています。 オーナー パラメーター：
コードが直接リポジトリに属しているという保証はなく、フォークからプルされる可能性についての警告もありません。正直なところ、アーキテクチャを考えると、この挙動は理にかなっています。コミットは共有グラフに存在し、GitHubがそれを配信します。これは間違いではありません。
何ですか です 問題は、これが誰も見抜けないような曖昧さを生み出すことです。要求されるのは trusted-org攻撃者からコードを受け取ります。GitHubはリクエストに応じましたが、求めていたものとは異なるものが提供されただけです。そして、GitHub以外のツールではその違いを判別できません。
非対称性
GitHub.comに警告バナーを追加していただいたこと、心から感謝しております。このようなコミットに対する警告が表示されるのは非常に有用です。これは、貴社がこの問題を表面化させる価値があると認識していることを示しています。
しかし、問題はここにあります。パッケージマネージャーはウェブサイトを見ません。彼らはAPIを呼び出します。そして、APIは異常が発生していることを一切示しません。フラグも、メタデータも、文書化されたものもありません。そのため、npmはユーザーに警告できません。PyPIも、Bunも警告できません。情報は存在し、すでにフロントエンドで表示されています。しかし、エコシステムはそれにアクセスできません。
なぜですか？
厳しくする時が来ました
私たちが話した「リポジトリアーカイブ（tar）をダウンロード」エンドポイントを覚えていますか？現時点では、それが最も弱いリンクです。しかし、そこが修正すべき明白な場所でもあります。
一つのアイデアとして、～を追加します。 厳格 パラメーター。これが設定されている場合、コミットがフォークにのみ存在し、指定された実際のリポジトリに存在しない場合はリクエストが失敗します。パッケージマネージャーはオプトインし、それ以外のユーザーは現在の動作を維持するため、何も壊れません。
その警告バナーのために、すでにフロントエンドでこのチェックを実施しています。APIにも同様の機能を持たせるべきです。一般的に、APIでより多くのフォークネットワーク情報を公開できれば理想的ですが、少なくともこれで最も明白な問題は解決されます。
良い休暇を！
私はこれを苦情として書いているわけではありません。私たちが皆、安全で信頼できるエコシステムを望んでいるという点で一致しているため、これを書いています。GitHub.comで警告を表示することで、すでにこの問題を認識されています。今、同じシグナルをAPIを通じて公開すれば、エコシステムがそれに対応できるようになり、大きな違いが生まれるでしょう。
わずかな改善が、エコシステム全体にわたる大幅な改善を可能にするでしょう。それが最良の改善ではないでしょうか？
そして、今はまさにホリデーシーズンですので、水面下で耳にしていることを共有したいと思います。ここ数週間、エコシステム内の主要な関係者数名と話しましたが、皆が大切な人と過ごすために休暇を取ろうとしている間に、何か問題が起こるかもしれないという静かな共通の懸念があります。もちろん、この一つの問題を解決してもそのリスクがなくなるわけではありませんが、この懸念は現実のものであり、広く共有されています。
GitHubの皆様、良い休暇を。穏やかな年末になりますように。
