2017年3月20日以降、GitHubでSHA-1ハッシュを計算するとき、SHA-1ハッシュの衝突に対するSHAttered攻撃の可能性の兆候があるコンテンツはすべて検出され、拒否されます。 同社はこれについて公式ブログに書いた 。 したがって、同じハッシュを持つが、異なるコンテンツを持つペアからファイルを投稿することはできません。 これまでのところ、 トレント以外のどこでもこのような攻撃を行った人はいませんが、GitHubは万が一に備えて安全にプレイすることを決定しました。
ほぼ1か月前、Googleとアムステルダムの数学およびコンピューターサイエンスセンターが、SHA-1ハッシュ関数の衝突を生成する最初の方法を発表しました 。 SHAttered攻撃は、2013年にアムステルダムの数学およびコンピューターサイエンスセンターの暗号学者Mark StevensがSHA-1衝突を作成するための理論的アプローチについて発表した2年後の研究の結果です。 彼はその後、Googleの同僚と一緒に実用的なハッキング方法を探し続けました。 SHA-1衝突の対象となるメッセージブロックを含むドキュメントを生成する一般原則を説明する科学論文が発行されました。
ドキュメントの公開後すぐに、アプリケーションでの実際の使用の最初の例が登場しました。BitErrant攻撃は、同じハッシュで異なるファイルに対応する2つの同一のトレント（.torrentファイル）を作成できるようにします。 1つは通常の実行可能ファイルで、もう1つはMetasploitフレームワーク用の悪意のあるMeterpreterファイルです。
Linus Torvalds氏は、GitリポジトリでのSHA-1衝突の心配は何もないと述べました。 彼は、暗号化システムでデジタル署名に暗号化ハッシュを使用することと、Gitのようなシステムで「コンテンツID」を生成することには大きな違いがあると説明しました。 最初のケースでは、ハッシュは一種の信頼の声明です。 ハッシュは、他の方法では検証できない人々から根本的に保護する信頼のソースとして機能します。 対照的に、Gitのようなプロジェクトでは、ハッシュは「信頼」に使用されません。 ここで、信頼はハッシュではなく人々にまで及ぶ、とLinusは言う。 Gitのようなプロジェクトでは、SHA-1ハッシュは完全に異なる技術的な目的に使用されます-偶発的な競合を避けるためだけでなく、エラーを検出する本当に良い方法として
Torvaldsの意見にもかかわらず、GitHubの開発者は再保険は決して痛くないと判断したため、このプラットフォームは同じハッシュを持つペアのファイルとコードを配置することから保護されています。
Torvaldsとは異なり、GitHub開発者はSHA-1の正しい操作がGitにとって本当に重要であると考えています。 彼らは彼の推論の論理そのものには賛成ではなく、Gitで実際にそのような攻撃を実行することが実際に可能であることを示しているだけです。 彼らは、そのような攻撃がどのように見えるかを大まかに説明しています。 以前に作成されたオブジェクトに対する攻撃はできないことに注意してください。 それを実行するには、攻撃者は特に同じハッシュを持つ2つの新しいオブジェクトを同時に作成する必要があります。 異なるデータの小さなセクションを除いて、それらは全体を通して同じです。
この場合、攻撃は次のシナリオに従って実行できます。
- 一方が正常に見え、もう一方が悪意のある動作を行うオブジェクトのペアを生成します。 これは、バイナリファイルを使用して行うのが最適です。バイナリファイルでは、違いを目で確認することはできません。
- プロジェクトメンテナーに、ペアの「無実の」半分を受け入れ、彼らがこのオブジェクトにタグ付けするかコミットするのを待つように説得してください。
- 無害なオブジェクトが悪意のあるオブジェクトに置き換えられたリポジトリのコピーを配布します（たとえば、サードパーティのサーバーのどこかに配置し、同一のハッシュを使用してコピーの信頼性の証拠を全員に提示します）。 署名を検証した後、誰もがこのプロジェクトの内容が元のリポジトリの内容に対応していると考えます。
SHAttered攻撃では、常にトレースが残ります。特定の一連のバイトであり、ペアの両方の部分で同じです。 ペアの任意の部分のSHA-1を計算することで検出できます。 GitHubは、ハッシュが計算されるたびにこのチェックを行うようになりました。
バイトの特定のシーケンスを決定するためのコードはマークスティーブンスとダンシャモフによって書かれて、パブリックドメインで発行されました 。
これまでのところ、GitHubでの単一のハッシュ衝突はありませんでした、と彼女は言いました。 元の攻撃例のPDFは、ハッシュを計算するときにGitの技術情報がさらに考慮されるため、Gitリポジトリではなく、独自に同じハッシュを提供します。
自動ブロックアルゴリズムは、後続の置換および攻撃の目的で配置されていないコードまたはファイルで動作する可能性があります。 しかし、やるべきことは何もありません。 ロックを解除するには、コードを変更する必要があります。
GitHub開発者は、ブロックしやすいコードを誤って記述する可能性を計算しました。 500万人のプログラマが1秒間に1つのコミットを生成する場合、Sunが赤い巨人になるまでにランダムに衝突する可能性は約50％です。
GitHub開発者は現在、Gitと連携して、共通プロジェクトに衝突検出用のライブラリを追加しています。 さらに、Gitは現在、既存のリポジトリへのダメージを最小限に抑えながら、SHA-1からより安全なハッシュ関数に移行する計画を開発しています。