- Unix türevi sistemlerde güvenilmeyen bir depoyu
git clone --recursive ile klonlamak, CVE-2025-48384 nedeniyle uzaktan kod çalıştırmaya yol açabilir; bu yüzden Git'in ve Git'i yerleşik olarak kullanan yazılımların güncellenmesi gerekir
- Neden, Git yapılandırmasını okuma ve yeniden yazma sürecinde carriage return (
\r) işleme biçimlerinin farklılaşması ve doğrulanan değer ile fiilen kullanılan değerin uyuşmamasıdır
.gitmodules içindeki alt modül path değerinin sonuna \r eklenirse checkout yolu doğrulamadan sonra farklı bir yola dönüşebilir- Windows dosya adlarında kontrol karakterlerine izin vermediği için doğrudan savunmasız değildir; ancak macOS hem CVE-2024-32002'ye hem de CVE-2025-48384'e karşı savunmasızdır
- Yama,
\r içeren yapılandırma değerlerini tırnak içine alacak şekilde değiştirerek .git içinde dosya yazma ve Git hook oluşturma gibi saldırı yollarını engeller
Güvenlik açığına genel bakış ve acil önlemler
- CVE-2025-48384, Unix türevi platformlarda güvenilmeyen bir depoyu
git clone --recursive ile klonlarken uzaktan kod çalıştırmaya yol açabilecek bir Git güvenlik açığıdır
- Düzeltilmiş Git sürümüne güncelleyin; GitHub Desktop dahil Git'i yerleşik olarak kullanan yazılımları da birlikte güncellemek gerekir
- Komut satırında yalnızca
git clone çalıştırılırsa alt modüller otomatik olarak klonlanmaz
- Hafifletme için önce
git clone komutunu --recursive olmadan çalıştırıp, .gitmodules dosyasının güvenli olduğunu doğruladıktan sonra alt modülleri başlatmak mümkündür
- GitHub Desktop varsayılan olarak recursive seçeneğiyle klonladığından bu davranışta etkilenebilir
Carriage return ve Git yapılandırma dosyaları
- Carriage return, ASCII karakter numarası 13 olan Carriage Return karakteridir ve C dizgilerinde
\r olarak gösterilir
- Unix satır ayırıcı olarak yalnızca LF, yani
\n kullanmak istemiştir; ancak Windows ve birçok internet protokolü CR+LF, yani \r\n kullanır
- Git'in
.ini tarzı yapılandırma biçimi, kullanıcı yapılandırma dosyalarının yanı sıra depoya dahil edilen .gitmodules dosyasında da kullanılır
- Git yapılandırma ayrıştırıcısı DOS satır sonlarını desteklemek için karakter okurken şöyle davranır
- Geçerli karakter
\r ise sonraki karakteri kontrol eder
- Sonraki karakter
\n ise \r karakterini atar ve bunu satır sonu olarak işler
- Sonraki karakter
\n değilse sonraki karakteri geri koyar ve \r karakterinin kendisini döndürür
- Bu işlem satır bazında uygulandığından, bir satır CR ile bitiyorsa dosyanın genel biçiminden bağımsız olarak ilgili CR kaldırılabilir
Okuma ve yazma arasındaki uyumsuzluk
- Git, yapılandırma dosyalarını okumakla kalmaz;
git config gibi yapılandırma değerlerini yazarken de aynı biçimde key = value çiftleri kaydeder
- Mevcut kod, yapılandırma değerini yeniden yazarken yalnızca aşağıdaki durumlarda değeri çift tırnak içine alıyordu
- Değer boşlukla başlıyorsa
- Değerin içinde
; veya # varsa
- Değer boşlukla bitiyorsa
- Buna karşılık yapılandırma okuma kodu çift tırnaklı dizgileri desteklediğinden,
write_pair tarafından yazılan değer daha sonra yeniden okunduğunda sondaki \r düşebilir
- Örneğin yapılandırma dosyasında
key = "foo^M" varsa, yeniden yazıldıktan sonra key = foo^M biçimine gelebilir
- Burada
^M literal CR karakteridir
- Bu davranış güvenilmeyen
.gitmodules değerleriyle birleştiğinde alt modül yolu işleme süreci kararsız hale gelir
Alt modül yolu karışıklığı ve etki alanı
- Unix tabanlı sistemlerde dosya adlarına kontrol karakterleri konabildiğinden
.gitmodules içindeki path değerine CR içeren bir değer koymak mümkündür
- Örnek şu biçimdedir
[submodule "foo"]
path = "foo^M"
- Bu değer Git yapılandırma kodu tarafından
.git/modules/foo/config dosyasına kaydedildiğinde şu biçime dönüşebilir
[core]
workdir = ../../../foo^M
- Doğrulama,
.gitmodules içinden okunan güvenilmeyen yol için zaten tamamlanmış durumdadır
- Daha sonra yapılandırma yeniden okunurken sondaki
\r kaldırılırsa Git doğrulanan yoldan farklı bir yol kullanır
- Sonuç olarak alt modül klonlama sırasında
path = ... içinden okunan konum ile fiilen kaydedilip kullanılan konum farklılaşabilir
- Bu prensip CVE-2024-32002'ye benzer
- CVE-2024-32002, alt modülde büyük/küçük harf duyarlılığından yararlanarak Git'i yanıltır
- CVE-2025-48384 ise dosya adlarında kontrol karakterlerine izin veren bir dosya sistemi gerektirir
- Windows dosya adlarında kontrol karakterlerine izin vermediğinden bu belirli hataya doğrudan savunmasız değildir
- macOS hem CVE-2024-32002'ye hem de CVE-2025-48384'e karşı savunmasızdır
Yama ve saldırı olasılığı
- Yama,
write_pair içinde değerde \r varsa dizgiyi tırnak içine alacak şekilde değiştirir
- Değişiklik, yalnızca
; veya # kontrol eden koşula '\r' ekleyen basit bir biçimdedir
for (i = 0; value[i]; i++)
- if (value[i] == ';' || value[i] == '#')
+ if (value[i] == ';' || value[i] == '#' || value[i] == '\r')
quote = "\"";
- Yol karışıklığıyla alt modülün kötü amaçlı dosyaları dosya sisteminde neredeyse istenen herhangi bir konuma yerleştirilebilir; doğrulama atlatılmış durumda olduğu için depo dışındaki sembolik bağlantılar da izlenebilir
- En doğrudan istismar yöntemi,
.git dizini içine dosya yazıp bir Git hook script'i oluşturarak Git hook'u çalıştırdığında saldırganın kontrolündeki kodun çalışmasını sağlamaktır
- Başka bir olasılık
.git/config dosyasının üzerine yazılmasıdır
- PoC henüz yayımlanmadı, ancak CVE-2024-32002 exploit'inin neredeyse önemsiz bir değişiklikle uyarlanabileceği belirtiliyor
- Düzeltme commit'indeki test, saldırı yöntemi hakkında önemli ipuçları verebilir
Tekrarlayan CR sorunu ve çıkarılan dersler
- Carriage return'ün Git'te sorun yarattığı ilk vaka bu değil
- Ocak ayında RyotaK, carriage return ile kandırılabilen credential helper protokolü sorununu keşfetti
- 2023'te André Baptista ve Vítor Pinho, yapılandırma ayrıştırmadaki mantık hatası olan CVE-2023-29007'yi keşfetti
- Bu güvenlik açığı C dilinin kendisinden kaynaklanan bir sorun değil, neredeyse her dilde ortaya çıkabilecek bir mantık hatasına daha yakındır
- Ortak nokta, Git iç bileşenleri arasında veya Git ile dış süreçler arasındaki süreçler arası iletişimde ortaya çıkmalarıdır
- HTTP'deki CRLF injection, request smuggling ve SMTP smuggling ile de benzer bir yapı görülebilir
- Geçmişte internet, Postel'in sağlamlık ilkesi olan “gönderirken muhafazakâr, alırken hoşgörülü ol” yaklaşımına dayanıyordu; ancak bugün bu en makul tavsiye olmayabilir
- Bu konu RFC 9413 içinde daha ayrıntılı ele alınır
Teşekkürler ve ilgili düzeltmeler
- Bu güvenlik açığı Git denetimi sırasında bulundu
- Aynı sürümde farklı önem düzeylerine sahip başka hatalar da birlikte düzeltildi
- G-Research Open Source bu çalışmayı mümkün kıldı
Henüz yorum yok.