Git'in carriage return ve clone RCE zafiyeti

 (dgl.cx)
1 puan yazan GN⁺ 2025-07-09 | 1 yorum | WhatsApp'ta paylaş
  • Git deposundaki carriage return karakterlerini kullanan bir saldırı tekniği tanıtılıyor
  • Bu zafiyet, uzaktan kod çalıştırma (RCE) olasılığına yol açıyor
  • Belirli git clone süreçlerinde kötü amaçlı komutlar çalıştırılabiliyor
  • Etkinin Linux ve Windows ortamlarında görüldüğü doğrulandı
  • Güvenlik açısından zayıf git depo yönetiminin riskleri vurgulanıyor

Carriage return karakteri ve Git zafiyeti

  • Git deposu içinde carriage return (\r) karakteri içeren dosya adları oluşturulabiliyor
  • Bu tür dosya adlarını içeren bir depo git clone ile kopyalandığında, komut yorumlama sürecinde istenmeyen komutların çalıştırılması mümkün hale gelebiliyor

Uzaktan kod çalıştırma (RCE) senaryosu

  • Saldırgan, carriage return karakteri eklenmiş bir dosyayı depoya ekleyip commit ediyor
  • Kullanıcı bu depoyu git clone ile klonladığında, dosya sistemi ve git komutlarının hatalı yorumlanması nedeniyle istenmeyen kod çalıştırma riski ortaya çıkıyor
  • Özellikle hook script'lerinin (ör. .git/hooks klasöründeki kodlar) otomatik çalıştırılması sağlanabiliyor

Etkilenen ortamlar ve alınacak önlemler

  • Linux ve Windows dahil çeşitli işletim sistemlerindeki git sürümlerinde görülebiliyor
  • Git depolarını yöneten veya sık sık harici depoları klonlayan geliştiriciler ve şirketler için ciddi bir güvenlik tehdidi oluşturuyor

Güvenlik önerileri

  • Güvenilmeyen harici git depolarını klonlarken en güncel sürümü kullanmak ve güvenlik durumunu kontrol etmek gerekiyor
  • Depo içindeki olağandışı karakterler (özellikle carriage return gibi) içeren dosya adları tespit edilmeli ve klonlamadan önce incelenmeli

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-09
Hacker News görüşü

  • Tüm bunların sonucu olarak, alt modül klonu yapılırken okumanın path = ... biçiminde gerçekleşip yazmanın ise ^M ile bitmeyen başka bir yola yapılabildiği durum açıklanıyor

    • Yazıda sözü edilen "uzaktan kod çalıştırma"nın burada tam olarak nasıl gerçekleştiği ve güvenlik açısından ne kadar ciddi olduğu soruluyor

    • Henüz bir PoC yayımlanmadı, ancak bunun CVE-2024-32002 exploit'inin neredeyse aynen değiştirilmiş hâli olduğu ve bunu düzelten commit'teki testlerin de büyük ipuçları verdiği belirtiliyor

    • CVE-2024-32002 açıklamasından alıntı: Alt modül içeren bir depo kötü niyetle hazırlanarak Git'teki bir hatadan yararlanıp dosyaları alt modül worktree'sine değil .git/ dizinine yazabiliyor. Bu sayede klonlama sırasında hemen çalışan bir hook yazılabiliyor ve kullanıcıya gerçekten çalışacak kodu inceleme fırsatı bile kalmayabiliyor

    • Özetle, depoya kötü amaçlı bir git hook yerleştirilebiliyor; normalde git hook'ları git clone sırasında kurulmaz, ancak bu saldırı bunu mümkün kılarak klon sürecinde hook çalıştırılabilmesini sağlıyor

    • Yeni CVE hakkında daha fazla bilgiye buradan ulaşılabileceği belirtiliyor

      • Git'in yapılandırma değerlerini okurken CR ve LF karakterlerini kaldırdığı, ancak yazarken CR'yi escape etmediği için okuma sırasında veri kaybı oluştuğu açıklanıyor
      • Alt modül yolunun sonunda CR karakteri varsa, bu karakter çıkarılmış yolun kullanılabildiği ve alt modülün yanlış konuma checkout edilebildiği belirtiliyor
      • Bu çıkarılmış yol ile alt modül hook dizini arasında önceden bir symlink varsa, saldırganın post-checkout hook'u üzerinden rastgele kod çalıştırabildiği söyleniyor
      • Bu CVE dışında da çok sayıda Git açığı olduğu ve onlara da bakmanın faydalı olduğu görüşü paylaşılıyor

    • Rastgele dosya yazma imkânı varsa bunun çoğu zaman RCE'ye uzanabildiği şeklindeki basit ama rahatsız edici gerçek dile getiriliyor

  • Ad-hoc DSL ile yapılandırma dosyası yazmanın risklerinden söz ediliyor

    • Çoğu durumda sözdizimi için resmî bir spesifikasyon olmadığı ve parse etmenin gerçek ölçütünün elde yazılmış serileştirme/serisizleştirme kodlarına dağılmış olduğu eleştiriliyor

    • İkisi farklı davranmaya başladığında (örneğin parser'a yeni sözdizimi eklenip writer'a eklenmemesi gibi) parser farklarının patlamaya hazır bir bomba hâline gelebileceği vurgulanıyor

    • Çıkarılan dersin, tek bir source of truth olması ve buna bağlı parçaların bunun üzerinden otomatik üretilmesi gereken bir yapı olduğu söyleniyor

    • Bu hatanın source of truth sorunundan ayrı olduğu da belirtiliyor

      • Bunun saf bir mantık hatası olduğu, Unix'te böyle standart bir sistem kütüphanesi olsaydı aynı sorunun orada da birebir yaşanabileceği açıklanıyor
      • Eğer böyle bir standart kütüphanede olsaydı etkisinin çok daha ağır olacağı, şimdi ise zararın daha çok geliştiricilerle sınırlı kaldığı ifade ediliyor

    • Burada kullanılan DSL'in (ini dosya biçimi) ad-hoc olsa da çok yaygın, tanıdık ve yeterince düzenli olduğu, bu yüzden pratikte çoğu zaman yeterli bir spesifikasyon sayılabileceği görüşü paylaşılıyor

      • Hatanın özünün biçimde değil, araya girmiş elde yazılmış parser'da (veya lexer'da) olduğu ve artık bu tür kodların bırakılması gerektiği savunuluyor
      • Akıllıca elde yazılmış çözümlerin gerekli olduğu bazı alanlar hâlâ var, ama veri değişim biçimlerinde asla kullanılmaması gerektiği; ini gerekiyorsa toml, o da değilse JSON, hatta YAML, gerçekten acı aranıyorsa XML ve ille de ikili biçim deniyorsa protobufs öneriliyor
      • Sonuç olarak, bir programlama dili yazarı değilseniz parser'ınızı kendiniz yazmamanız ve mutlaka kütüphane kullanmanız gerektiği vurgulanıyor

  • Sorun bizzat yeniden üretilmiş ve bu depoya yüklenmiş

    • Hemen Git'in en güncel sürümüne geçmeye çalıştığı, ancak bunun Arch'ta henüz bulunmadığı söyleniyor

    • Yeni yama gelene kadar pull yapmaktan kaçınacağı, otomatik pull yapan popüler depolarda sorun çıkabileceği için yükseltmenin zaman alabileceğinden endişe edildiği belirtiliyor

    • Bu açığın yama çıkmadan önce mi kamuya açıklandığı soruluyor

      • Eskiden bir açığın nasıl istismar edilebildiğini anlatan yazılar çoğunlukla yamadan aylar sonra çıkardı; artık ise her gönderide "bu şu anda gerçekten tehlikeli" ile "zaten yamalandı, endişe etmeyin" ayrımının açıkça belirtilmesi istendiği söyleniyor

  • Mevcut exploit'te "yalnızca basit bir varyasyon" yapıldığı ifadesi görülünce Git'in neden Landlock kullanmadığı soruluyor (Landlock, Linux'a özgü bir sandbox güvenlik özelliğidir)

    • git clone işleminin config dizinine salt-okunur erişim, hedef klon dizinine okuma/yazma erişimi ve alt süreç çağrılarının yasaklanmasıyla çalışması gerektiği öne sürülüyor

    • Her exploit'te sürekli hesap makinesi açılmasını tiye alan bir yorum yapılıyor

    • Alt süreç çağrılarının yasaklanmasının post-checkout gibi tüm git hook'larını bozacağına dikkat çekiliyor

      • Gerekli değilse seccomp benzeri konteyner ortamlarında Git çalıştırılabileceği, ancak pek çok özelliğin kısıtlanacağı açıklanıyor

    • Ayrıca alt süreçler olmadan SSH üzerinden Git kullanımının da mümkün olmayacağı belirtiliyor

  • Homebrew'ün kendisinin sorunlu olup olmadığı, yani recursive clone yapıp yapmadığı soruluyor

    • Bu kodda buna dair bir olasılık bulunduğu söyleniyor

    • Homebrew'ün amacının zaten depo kodunu çalıştırmak olduğu, bu yüzden recursive clone yoksa asıl bunun garip olacağı görüşü paylaşılıyor

      • RCE'nin ancak klonlanan verinin çalıştırılmaması gereken durumlarda anlamlı olduğu, böyle durumların ise nadir olduğu belirtiliyor

  • Jon Postel'in CR+LF ile ilgili ünlü sözü görünce nostalji yaşandığı anlatılıyor

    • Bu yazı bağlantısı paylaşılırken, 2003'e kıyasla bugün bu tavsiyenin artık doğru olmayabileceği değerlendirmesi yapılıyor
    • Mark Crispin'in o dönemde açıkladığı gibi insanların bunu yanlış anladığı ve 1990'ların sonunda Daniel J. Bernstein'ın insan-makine dönüşümlerinde (parsing/quoting) ortaya çıkan sorunlara dikkat çektiği örnekle bağlantı kuruluyor
    • 25 yıl sonra bile CR'yi escape etmeyen quoter kodu sorununun tekrarlandığı, hatta düzeltildikten sonra bile tüm whitespace'in kontrol edilmediği gözlemleniyor
    • git blame çıktısına göre sorunlu kodun 19 yıl önce yazıldığı ve bunun Bernstein'ın 10. yıl dönümü değerlendirmesiyle zamansal olarak çakıştığı belirtiliyor
    • İlgili commit, qmail makalesi gibi ek kaynaklar paylaşılıyor
    • Sonuçta, 20. yüzyılda zor öğrenilen derslerin 21. yüzyılda da yeniden öğrenilmek zorunda kalındığı vurgulanıyor

  • Homebrew'de git 2.50.1 güncellemesi henüz olmadığı için biraz daha beklemek gerekeceği söyleniyor

    • Bu issue ya da brew install git --HEAD ile güncelleme denenebileceği belirtiliyor

  • Hem Homebrew hem de Debian Bookworm'un hâlâ savunmasız sürümleri sunduğu bilgisi paylaşılıyor

    • Artık Homebrew'de de 2.50.1 sürümünün kullanılabildiği bildiriliyor

  • Dizin listesini getiren sistem çağrısının, dosya adında ASCII kontrol karakterleri (byte'lar) varsa bu dosyanın varlığını reddetmesi mi, bunu disk bozulması sayması mı yoksa başka türlü mü davranması gerektiği sorgulanıyor

    • Geçerli locale'de bu byte'ların başka anlamlar taşıyabileceği, Windows'taki gibi tüm dosya adlarının UTF-16 olduğunu varsaymadığımız için beklenmedik durumlar çıkabileceği belirtiliyor

    • Unix benzeri sistemlerde dosya adlarının (ve diğer dizelerin) sadece birer byte dizisi olmasının yol açtığı bir sorun olduğu kısaca ifade ediliyor