プライベートデータと削除されたコンテンツに永久にアクセス可能、GitHub公式：意図的に設計

最近、オープンソース コミュニティに衝撃を与えたニュースがありました。GitHub 上の削除されたコンテンツとプライベート リポジトリ内のデータには永続的にアクセスできますが、これは公式によって意図的に設計されたものです。

オープンソースのセキュリティ ソフトウェア会社 Truffle Security は、ブログ投稿でこの問題について詳しく説明しました。

Truffle Security に新しい用語が導入されました: CFOR (クロスフォークオブジェクトリファレンス): リポジトリフォークが別のフォークの機密データ (プライベートフォークや削除されたフォークからのデータを含む) にアクセスできる場合、CFOR 脆弱性が存在します。

安全でない直接オブジェクト参照と同様に、CFOR では、ユーザーはコミット ハッシュ値を提供することでコミット データに直接アクセスできます。そうでない場合、データは表示されません。

以下は Truffle Security ブログのオリジナルのコンテンツです。

削除されたフォーク リポジトリからデータにアクセスする

次のワークフローを想像してください:

• GitHub 上のパブリック リポジトリをフォークする

• フォーク リポジトリにコードをコミットする

• フォークリポジトリを削除した場合。

つまり、フォークに送信したコードにはアクセスできないはずです。フォーク リポジトリを削除したためです。ただし、永続的にアクセス可能であり、ユーザーの制御下にあるわけではありません。

以下のビデオに示されているように、リポジトリをフォークしてそこにデータを送信し、フォークしたリポジトリを削除すると、「削除された」送信されたデータに元のリポジトリを通じてアクセスできるようになります。

この状況はよくあります。 Truffle Security は、大手 AI 企業の頻繁にフォークされた 3 つのパブリック リポジトリを調査し、削除されたフォークされたリポジトリから 40 個の有効な API キーを簡単に発見しました。

削除されたリポジトリからのデータへのアクセス

次のワークフローを考えてみましょう:

• GitHub 上にパブリック リポジトリがあります

• ユーザーがリポジトリをフォークします。

データの送信後にデータをコミットしますフォークすると、フォークされたリポジトリが更新内容と同期されることはありません
リポジトリ全体を削除します。

その後、ユーザーがリポジトリをフォークした後も、送信したコードには引き続きアクセスできます。

GitHub は、元の「上流」リポジトリがルート ノードとして機能し、リポジトリとフォークされたリポジトリをリポジトリ ネットワークに保存します。フォークされたパブリック「アップストリーム」リポジトリが「削除」されると、GitHub はフォークされたダウンストリーム リポジトリの 1 つに root 役割を再割り当てします。ただし、「アップストリーム」リポジトリからのコミットはすべてまだ存在しており、フォークされたリポジトリを通じてアクセスできます。

この状況は特殊なものではなく、先週、次のようなことが起こりました:

Truffle Security が P1 脆弱性を大手テクノロジー企業に提出しました。これは、従業員を誤って GitHub に提出したことを示しています。 GitHub 組織全体への重要なアクセス。同社はすぐにリポジトリを削除しましたが、リポジトリはフォークされていたため、フォークされたリポジトリが元の「上流」リポジトリと同期されていなかったにもかかわらず、機密データを含むコミットにはフォークされたリポジトリを通じて引き続きアクセスできました。

つまり、パブリック リポジトリにコミットされたコードは、そのリポジトリに少なくとも 1 つのフォーク リポジトリがある限り、永続的にアクセスできます。

プライベート リポジトリ データにアクセスする

次のワークフローを考えてみましょう:

最終的に公開されるプライベート リポジトリを作成します
そのリポジトリのプライベート ビルドを (フォーク経由で) 作成し、追加のコードをコミットします。公開を意図していない機能の場合
「アップストリーム」リポジトリを公開し、フォーク リポジトリを非公開にします。

その後、プライベート機能と関連コードが一般公開されます。ツールを作成したリポジトリの内部フォークとツールのオープン ソースの間でコミットされたコードは、パブリック リポジトリを通じてアクセスできます。

「アップストリーム」リポジトリを公開すると、プライベート フォーク リポジトリに対して行われたコミットは表示されなくなります。これは、プライベート「アップストリーム」リポジトリの可視性を変更すると、プライベート バージョン用とパブリック バージョン用の 2 つのリポジトリ ネットワークが作成されるためです。

残念ながら、このワークフローは、オープンソース ソフトウェアを開発する際にユーザーや機関が使用する最も一般的な方法の 1 つです。その結果、機密データが GitHub パブリック リポジトリで誤って公開される可能性があります。

データにアクセスするにはどうすればよいですか?

GitHub リポジトリ ネットワークでの破壊的な操作 (上記の 3 つのシナリオのような) は、標準の GitHub UI および通常の Git 操作からデータをコミットする参照を削除します。ただし、データはまだ存在しており、アクセス可能です (コミットハッシュ)。これは、CFOR 脆弱性と IDOR 脆弱性の間のリンクです。特に Git プロトコルではコミットを参照するときに短い SHA-1 値の使用が許可されているため、

コミット ハッシュは GitHub の UI を介して総当たり攻撃することができます。短い SHA-1 値は、別のコミット ハッシュとの衝突を避けるために必要な最小文字数であり、絶対最小値は 4 です。すべての 4 文字の SHA-1 値のキー スペースは 65536 (16^4) です。すべての可能な値をブルートフォースで実行することは、比較的簡単に達成できます。

興味深いことに、GitHub はパブリック イベント API エンドポイントを公開しています。また、サードパーティが管理するイベント アーカイブ内のコミット ハッシュをクエリして、リポジトリが削除された後でも、過去 10 年間のすべての GitHub イベントを GitHub の外部に保持することもできます。

GitHub の規定

Truffle Security は、GitHub の VDP プログラムを通じて GitHub 関係者に調査結果を提出しました。 GitHub は「これは仕様です」と文書を添付して返答しました。

ドキュメント: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks -リポジトリが削除されたとき、または変更されたときの可視性

Truffle Security は、GitHub がそのアーキテクチャについて透明性を保っていることを賞賛していますが、Truffle Security は次のように考えています: 一般のユーザーはプライベート リポジトリとパブリック リポジトリの分離をセキュリティ境界と見なしており、パブリック ユーザーはプライベート リポジトリ内のデータにアクセスできないとみなされます。残念ながら、上で述べたように、これは常に当てはまるわけではありません。

Truffle Security は、フォーク リポジトリが存在する限り、そのリポジトリ ネットワークへのコミット (つまり、「アップストリーム」リポジトリまたは「ダウンストリーム」フォーク リポジトリでのコミット) は永久に存続すると結論付けました。

Truffle Security はまた、パブリック GitHub リポジトリ上の侵害されたキーを安全に修正する唯一の方法はキーのローテーションであると主張しています。

GitHub のリポジトリ アーキテクチャには、これらの設計上の欠陥があります。残念ながら、GitHub ユーザーの大多数はリポジトリ ネットワークが実際にどのように機能するかを決して理解しておらず、その結果、セキュリティが危険にさらされることになります。

^{元のリンク: https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github}

以上がプライベートデータと削除されたコンテンツに永久にアクセス可能、GitHub公式：意図的に設計の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。