60 saniyede CVE-2024-6387 (regreSSHion)
OpenSSH’in sshd servisi, uzaktan gelen SSH bağlantılarını kabul eden sunucu sürecidir. Bir istemciye kimlik doğrulaması yapması için sınırlı bir süre (LoginGraceTime) tanınır. Bu süre dolduğunda, işletim sistemi sshd sürecine bir SIGALRM sinyali iletir ve sürecin tamamlanmamış oturumu sonlandırmasını sağlar.
Portable OpenSSH 8.5p1 ile 9.7p1 sürümleri arasında, bu alarm sinyal işleyicisi (signal handler) doğrudan loglama fonksiyonlarını çağırıyordu. Loglama ilk bakışta zararsız görünse de, glibc tabanlı Linux sistemlerinde syslog() fonksiyonu arka planda malloc() ve free() gibi karmaşık bellek yönetimi çağrıları yapabilir. Bir işletim sistemi sinyali ise ana program akışını neredeyse her an — heap allocator’ın kendi iç durumunu güncellemesinin tam ortası da dahil olmak üzere — asenkron olarak kesebilir.
Alarm sinyali bu kritik zamanlama penceresinde gelirse, sinyal işleyicisi ilk işlem henüz tamamlanmadan bellek ayırıcıya (allocator) ikinci kez girebilir (re-entrancy). Doğrudan sonuç genellikle bir çökmedir (crash). Ancak Qualys araştırmacıları; özenle yapılandırılmış SSH paketleri ve tekrarlanan zamanlama denemeleriyle bu heap bozulmasının 32-bit Linux/glibc hedefinde kimlik doğrulaması gerektirmeyen uzaktan root seviyesinde kod çalıştırma (RCE) zafiyetine dönüştürülebileceğini kanıtladı.
Saldırı yolu (attack path) şu şekildedir:
Uzak istemci bir SSH bağlantısı açar
-> İstemci kasıtlı olarak kimlik doğrulamasını tamamlamaz
-> LoginGraceTime süresi dolar ve SIGALRM sshd sürecini keser
-> Sinyal işleyicisi güvenli olmayan loglama kodunu çağırır
-> syslog, heap durumu tutarsızken malloc/free'ye yeniden girer
-> Tekrarlanan denemeler yarış durumunu (race condition) kazanmaya çalışır
-> Saldırgan kontrollü heap bozulması root kod yürütmeye ulaşabilir
Savunmasız yola ulaşmak için geçerli bir kullanıcı adı, parola veya SSH anahtarı gerekmiyordu. Asıl zorluk zamanlamadaydı: Saldırgan sinyalin o dar pencerede gelmesini sağlamak ve ASLR korumasını aşmak için binlerce denemeyi tekrarlamak zorundaydı.
sshd, LoginGraceTime ve SIGALRM nedir?
sshd, OpenSSH’in internete açık sunucu sürecidir. Uzak kullanıcı kimlik doğrulaması yapmadan önce bağlantıyı işlemeye başlar; çünkü protokolü müzakere etmek ve kimlik doğrulama paketlerini incelemek zorundadır. Bu ön kimlik doğrulama işlemlerinin bir kısmı ayrıcalıklı bir süreçte gerçekleşir.
LoginGraceTime, bir istemcinin oturum açmak için harcayabileceği maksimum süredir (varsayılan 120 saniyedir). Bu süre dolduğunda sshd asenkron bir işletim sistemi sinyali olan SIGALRM alır.
Burada kilit kelime “asenkron”dur. Sıradan bir fonksiyon çağrısı programın belirlediği kontrollü bir anda gerçekleşir. Bir sinyal işleyicisi ise, ilişkisiz bir işlem geçici olarak bir lock tutarken veya bir veri yapısını yarı yarıya güncellemişken aniden araya girebilir. Bu nedenle POSIX, bir sinyal işleyicisi içinde yalnızca küçük bir dizi async-signal-safe (asenkron sinyal için güvenli) işlemin yapılmasına izin verir. Genel loglama fonksiyonları bu güvenli listede yer almaz.
Zafiyet SSH’in bir zaman aşımına sahip olmasından kaynaklanmadı. Zaman aşımı yönetiminin, ayrıcalıklı ve asenkron bir bağlamda güvenli olmayan işlemler gerçekleştirmesinden kaynaklandı.
Ne oldu?
Kronoloji şu şekildedir:
- 2006 yılında OpenSSH, ölümcül sinyal yolunun loglama yapmak yerine doğrudan
_exit(1)ile sonlanmasını sağlayarak CVE-2006-5051 zafiyetini düzeltti. - Ekim 2020’de yapılan bir loglama refactor çalışması sırasında, bu özel davranışı koruyan
DO_LOG_SAFE_IN_SIGHANDkoşulu kazara kaldırıldı. Bu regresyon Portable OpenSSH 8.5p1 sürümüne girdi. - Kimliği doğrulanmamış bir istemci
LoginGraceTimesüresini aştığında,grace_alarm_handler()yenidensigdie()fonksiyonuna ve etkilenen platformlarda async-signal-safe olmayan loglama çağrılarına ulaştı. - Qualys bu eski hata sınıfını yeniden ortaya çıkardı ve güncel bir 32-bit Debian Linux/glibc ortamında istismarı gerçekleştirdi. Laboratuvar ortamındaki saldırı yaklaşık 10.000 yarış denemesi gerektirdi ve ortalama 6 ila 8 saat sürdü.
- OpenSSH, 1 Temmuz 2024’te sürüm 9.8/9.8p1’i yayınladı. Yeni tasarım, alarm işleyicisi içinde yalnızca minimal bir sonlandırma yapar; loglama ve IP ceza işlemlerini ana listener sürecinin olağan akışına taşır.
Zafiyete regreSSHion adının verilmesi bu geçmişe dayanır: 2006 yılında düzeltilmiş bir güvenlik garantisi, yıllar sonra yapılan bir refactor ile sessizce kaybedilmiştir.
Derinlemesine teknik analiz: SIGALRM içinden loglama heap’i neden bozar?
Normal fonksiyon çağrıları sıralıdır. Bir fonksiyon durumunu günceller, diğerini çağırır ve veri yapıları tutarlı hale geldiğinde geri döner. Asenkron bir sinyal ise farklıdır: İşleyici, kesilen kod geçici bir lock tutarken veya bellek ayırıcı yapısını yarı yarıya güncellemişken çalışabilir.
Etkilenen glibc sistemlerinde syslog() bellek tahsis edebilir (malloc) ve serbest bırakabilir (free). Alarm, ana kimlik doğrulama akışını kendi allocator işlemi sırasında keserse, işleyici aynı allocator’a tutarsız bir bellek durumundayken yeniden girer.
Düzeltme: 9.8p1 iş yükünü işleyiciden çıkardı
9.8p1 yaması ile güvenli olmayan temizlik ve loglama işlemleri alarm işleyicisinin içinden çıkarıldı; işleyicinin yalnızca minimal ve sinyal için güvenli olan _exit(EXIT_LOGIN_GRACE) çağrısı yapması sağlandı. Loglama ve ceza işlemleri ana listener sürecine devredildi ve senkron olarak çalıştırıldı.
Evidence matrix
| Soru | Neyi kontrol ettim | Güven | Sınır |
|---|---|---|---|
| Hangi sürümler etkilendi? | Portable OpenSSH 8.5p1 ile 9.7p1 arasındaki sürümleri doğruladım. | Yüksek | Dağıtım backport paketleri ayrıca incelenmelidir. |
| Yolu ne tetikliyor? | LoginGraceTime süresinin kimlik doğrulama bitmeden dolması ve SIGALRM fırlatılması. | Yüksek | Pratik zamanlama konfigürasyona ve ağ koşullarına bağlıdır. |
| Loglama orada neden tehlikeli? | Eski işleyicinin async-signal-safe olmayan fonksiyonlara ulaştığını ve allocator’a yeniden girdiğini teyit ettim. | Yüksek | libc iç mekanizmaları platforma göre değişir. |
| Uzaktan root RCE kanıtlandı mı? | Qualys’in 32-bit Linux/glibc laboratuvar sonucunu inceledim. | Yüksek | 64-bit hedeflerde tam RCE yayını yapılmamıştır. |
| OpenBSD neden etkilenmedi? | OpenBSD’nin güvenli sinyal loglama mekanizmasına sahip olduğunu doğruladım. | Yüksek | glibc dışı sistemler bağımsız analiz gerektirir. |
Sonuç
OpenSSH sürümünüzü 9.8p1’e veya CVE-2024-6387 yamasını içeren dağıtım paketine yükseltin. LoginGraceTime süresini değiştirmek veya bağlantı sınırlamaları uygulamak riski azaltabilir; ancak bunlar kalıcı çözüm değil, telafi edici kontrollerdir.
Kalıcı teknik çözüm, daha dikkatli bir loglayıcı yazmak değil; sinyal işleyicisini küçültmek ve asenkron bağlamda yalnızca güvenli çıkış yapmaktır.
Bu analiz için kullanılan kanıtlar
Sürüm ve sömürü durumu değişebilir; üretici kayıtlarını takip edin.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.
