GitHub üzerinde “Verified” yani doğrulanmış olarak işaretlenen commitlerin hash değerleri değiştirilerek yeni hashler oluşturulabiliyor; ancak bu işlem imza doğrulamasını etkilemiyor. Bu durum, birçok güvenlik sisteminin commit hash’ini içeriğin benzersiz ve kalıcı bir adı olarak kabul etmesi sebebiyle önemli bir güvenlik açığı teşkil ediyor.
Saldırı Mekanizması ve Teknik Ayrıntılar
Temel sorun şu: kötü amaçlı bir commit hash’e göre engellendiğinde, saldırgan aynı içeriği alıp farklı ve hâlâ “Verified” olarak işaretlenmiş yeni bir hash ile tekrar gönderebiliyor. Bu, engelleme listeleri, çoğaltma önleme mekanizmaları ve orijin kayıtları gibi hash tabanlı sistemler için zayıf nokta yaratıyor. Ayrıca, saldırganlar, kötü amaçlı veya ele geçirilmiş aynalar aracılığıyla, orijinal kaynak sistemdeki hash’den farklı ama geçerli imzalı commit’leri kullanıcılara iletebiliyor.
Burada imza doğrulamasından farklı kod geçirme durumu söz konusu değil; dosyalar her kopyada aynı kalıyor. Bu yüzden hash’e bağlı kod sabit kalıyor veya erişilemiyorsa hata veriyor. Şu an için bir CVE kaydı veya tedarikçi uyarısı bulunmuyor, ayrıca kullanıcıların kendi depolarında değişiklik yapması gerekmiyor. Sorun, “Verified” ifadesinin ne anlama geldiğini belirleyen platformun (forge) tasarımında ve çözümü de ancak platform tarafında uygulanabilir.
İmza Malleability ve Hash Zinciri
Bu açığın arkasında “signature malleability” yani imza değiştirilebilirliği yatıyor. Commit hash’i, imza ham verileri de dahil olmak üzere tüm commit içeriği üzerinden hesaplanıyor. İmzalar birçok farklı ama geçerli biçime dönüştürülebiliyor; böylece imzaya dokunmadan commit’in ham verisi ve hash’i değiştirilebiliyor.
Üç temel yöntemle bu sorun ortaya çıkıyor:
- ECDSA anahtarlarında klasik eliptik eğri cebiri kullanılarak (s değerini n-s ile değiştirme) iki geçerli imza formu oluşturulabiliyor.
- RSA ve EdDSA anahtarlarında imzanın “unhashed” yani imzalanmamış kısmına, kontrol edilmeyen ekstra alan ekleniyor.
- S/MIME (X.509) imzalarında DER yapısındaki uzunluk alanı, standart dışı ama geçerli bir forma dönüştürülüyor.
GitHub, imzayı kontrol etmeden önce normalizasyon uygulamadığı için bu varyasyonları kabul ediyor. Ayrıca her commit hash’i için “Verified” kaydı oluşturup bunu yeniden kontrol etmiyor; bu da, imzalama anahtarı iptal olsa bile commit’in doğrulanmış görünmesini sağlıyor.
Bitcoin’den Tanıdık Bir Sorun
Bu problem yeni değil. Bitcoin topluluğu da benzer ECDSA simetrisi sorununu yıllar önce yaşadı. Bir işlem imzasındaki s değeri tersine çevrilebiliyor, böylece işlem ID’si değişiyor ama imza geçerli kalıyordu. Çözüm olarak sadece “low-S” formu kabul edildi ve SegWit ile imzalar işlem ID’sinden ayrıldı.
Benzer şekilde, bu sorunun çözümü de imzaların geçerli hale gelmeden önce standart bir biçime sokulması (canonicalization) yönünde. Bu, yeni bir kriptografi değil, bilinen bir yöntem.
Etki ve Önlemler
Bu açığın yakın zamanda yaşanan GitHub Actions etiket kaçırma saldırılarıyla bağlantısı da var. Özellikle 2025 ve 2026 saldırılarında önerilen, hareketli etiketler yerine tam commit hash’lerine sabitlenmekti. Bu tavsiye hâlâ geçerli. Çünkü sabit hash kullanımı, bu tür yeniden yazılmış commitlerle yapılan saldırıları engelliyor.
Burada geliştiricilerin yapması gereken bir şey yok; pinned (kilitlenmiş) hash doğru içeriği getiriyor. Asıl sorumluluk, kod barındırma platformlarına (forgelar) düşüyor. İmzalar güvenilmeden önce standart bir forma getirilmezse, bu tür saldırı yöntemleri kullanılmaya devam edecek. Ayrıca commit hash’i bazlı engelleme, çoğaltma önleme veya kaynak takibi yapan araçların da imzaları doğrulayıp standart hale getirmesi gerekiyor.
Sistem Yöneticileri ve SOC Ekiplerine Öneriler
- GitHub ve benzeri platformlarda “Verified” etiketiyle işaretlenmiş commitlere şüpheyle yaklaşın, özellikle hash değişimi ihtimalini göz önünde bulundurun.
- Commit hash’lerine dayanan otomatik engelleme sistemlerinde imza doğrulaması ve normalizasyonu ekleyin.
- CI/CD boru hatları ve kod inceleme süreçlerinde, imza biçimi ve hash tutarlılığını kontrol eden araçlar kullanın.
- GitHub Actions gibi üçüncü parti kod entegrasyonlarında, tam commit hash’lerine kilitlenmeyi tercih edin, hareketli etiketlerden kaçının.
- Olay müdahale süreçlerinde, şüpheli commitlerin hash’lerinin yeniden yazılmış versiyonlarını da takip edin.
Sonuç olarak, commit hash’leri kodun benzersiz kimliği olarak görülse de, imza malleability sebebiyle bu kimlik sabit kalmayabiliyor. Bu da kod tedarik zinciri ve yazılım güvenliği alanında yeni riskler doğuruyor. Platformların buna uygun çözümler geliştirmesi, güvenlik seviyesini artıracaktır.