GitButler yazısı, Git 3.0'ın varsayılan SHA-256 geçişini getirisine kıyasla maliyetli bir değişiklik olarak nitelendiriyor

Git 3.0, obje depolamada kullanılan varsayılan hash algoritmasını SHA-1'den SHA-256'ya değiştirmeye hazırlanıyor ve şu anda Hacker News ana sayfasında yer alan, GitButler'un sitesinde yayımlanan bir blog yazısı bu geçişin pratikte hiçbir güvenlik faydası sağlamayan, küresel ölçekte pahalı bir aksaklık olduğunu ve geliştiricilerin çoğunun bunun geldiğinden haberdar olmadığını savunuyor.

Git hash'leri nasıl kullanıyor

Git, içerik adreslenebilir bir veritabanıdır: her dosya, tree ve commit için bir hash hesapler ve bu hash'i bir anahtar/değer deposuna anahtar olarak kullanır. Özdeş içerik yalnızca bir kez saklanır ve her commit ebeveyninin hash'ini kaydettiği için, geçmiş içerikte yapılan herhangi bir değişiklik, onu izleyen tüm hash'leri de değiştirir. Uçtaki (tip) commit'i hash'lemek, fiilen tüm proje geçmişine parmak izi basar.

Bu hash fonksiyonu, Linus Torvalds'ın Git 2005'te yaratıldığında SHA-1'i seçmesinden beri SHA-1 olagelmiştir. GitButler yazısına göre, şimdiye kadar yapılmış tüm Git repository'lerindeki milyarlarca obje arasında tek bir kazara çakışma (collision) bile kaydedilmemiştir ve SHA-1'in 160 bitlik çıktısındaki doğum günü sınırı, kazara bir çakışmanın mümkün olabilmesi için tek bir projenin yaklaşık 1,4 septilyon rastgele dosyaya ihtiyaç duyacağı anlamına gelir.

Burada "kırılmış" ne demek

SHA-256'ya yöneliş, yayımlanmış çakışma saldırılarının — 2017'deki SHAttered ve 2020'deki SHA-1 is a Shambles — ardından geldi; bu saldırılar, özel amaçlı çakışmaları tahminen on binlerce dolar karşılığında modern GPU çiftliklerinin erişimine soktu. Kriptografik açıdan "kırılmış", belirli içerik biçimlerinde çakışmaların kasıtlı olarak üretilebilmesi anlamına gelir; makul iki dosyanın kazara çakışacağı anlamına gelmez.

Yazı, çakışma saldırıları ile ikinci-preimage (second-preimage) saldırıları arasına keskin bir çizgi çiziyor. Bir çakışma, saldırganın zararsız bir dosyayı ve kötü niyetli bir ikizini önceden hazırlamasını, sonra zararsız sürüm güven kazandıktan sonra ikisini yer değiştirmesini gerektirir. İkinci bir preimage — başkasının yazdığı bir dosyanın hash'ine uyan kötü niyetli bir dosya üretmek — çok daha tehlikeli olurdu; ancak yazarın da belirttiği gibi, tamamen kırılmış olan MD5 dahil, yaygın olarak kullanılan hiçbir hash fonksiyonu pratikte buna karşı savunmasız değildir. Dolayısıyla Git'e yönelik gerçekçi herhangi bir saldırı, saldırganın içeriğin özgün yazarı olmasını gerektirir.

Güven hash'lerden değil, dağıtımdan gelir

Argümanın özü, hash'lemenin hiçbir zaman kaynak kontrolünde güvenin temeli olmamasıdır. Yazı, Torvalds'ın 2005 tarihli sözlerini aktarıyor: "sha1'in 'güvenlik' olduğunu gerçekten düşünmüyorum. Gerçek güvenlik dağıtımdadır." Geliştiriciler bir repository'ye, obje hash'lerinin gücünden değil, nereden pull yaptıklarından dolayı güvenirler.

Yazar, ikinci preimage'lerin üretilmesinin ucuz olduğu varsayılsaydı bile, gerçekçi olmayacak kadar cömert bir senaryoda bile saldırganın, kendilerini tanımayan insanlar tarafından kötü niyetli dosyanın fetch edilip çalıştırılması sorununuyla karşı karşıya kalacağını savunuyor; yazıya göre bu pratik engeller, bu geçişe dair tartışmalarda büyük ölçüde eksik kalıyor. Kötü niyetli dosyaların gerçekten codebase'lere sızdığı kabul ediliyor, ama bunun nedeni birilerinin eşleşen checksum'lar üretmek için GPU zamanına servet harcaması değil.

Yazar, SHA-256 geçişinin yetenekli insanların yıllarca sürdürdüğü bir emeğin ürünü olduğunu kabul ediyor, ancak bunun ekosistemin muazzam zamanını, temelde teorik kalan kazanımlar uğruna tüketeceğini öngörüyor.

Neden önemli

SHA-256, Git 3.0'da varsayılan hale gelirse, ortaya çıkacak geçiş çalışması yalnızca Git'in maintainer'larıyla sınırlı kalmayacak. SHA-1 varsayımları üzerine inşa edilmiş repository'ler, hosting platformları ve araçların hepsi etkilenecek ve GitButler yazısı, zaman ve aksaklık açısından bu maliyetin neredeyse hiç kimsenin farkında olmadığı bir değişiklikle tüm topluluğa bineceği konusunda uyarıyor.

Yazı ayrıca sektör için daha geniş bir tartışmayı yeniden çerçeveliyor: koddaki güven sonuçta hash gücünden değil, dağıtım kanallarından ve incelemeden (review) geliyorsa, hash fonksiyonunu sağlamlaştırmaya harcanan kaynaklar supply chain'in yanlış katmanını ele alıyor olabilir. Git'e ağır şekilde bağlı olan ekipler Git 3.0 sürüm planlarını yakından izlemeli, hash geçişinin kendi araçları için ne anlama geldiğine karar vermeli ve değişiklik hâlâ şekillendirilebilirken görüşlerini bildirmelidir.