PAM'suz SSH girişlerinde musl libc crypt'in sentinel çakışması kilitli Alpine hesaplarını açıyor

Ne oldu

musl libc'deki bir parola işleme hatası, birbiriyle ilgisiz iki geleneğin nasıl bir kimlik doğrulama atlatma sorununa dönüşebildiğini gösteriyor. Hacker News ana sayfasına çıkan sunshowers imzalı bir blog yazısına göre, kimlik doğrulaması yapılmamış bir kullanıcı PAM olmadan sshd çalıştıran musl tabanlı sistemlerde bir kabuk — muhtemelen root kabuğu — elde edebiliyordu. Yazı, resmi Alpine Linux AWS imajını bu tür bir yapılandırma olarak örnek gösteriyor ve okuyucuları düzeltme ayrıntıları için bir Alpine güvenlik bültenine yönlendiriyor.

Kök neden bellek bozulması değil. Kendi başına makul görünen iki sentinel değerin çakışmasıdır.

İki gelenek, tek çakışma

Unix'te tek karakterli * parola karması, platformun en eski günlerinden beri kilitli bir hesabı ifade etmiştir. Ayrı olarak, 2012'den beri musl'nin crypt uygulaması, işlemek için fazla uzun bir parolanın karması istendiğinde aynı dizgiyi döndürüyor.

Bu geleneklerin hiçbiri tek başına tehlikeli değil. Sorun, sshd'nin zamanlama davranışının hesap durumunu ele vermemesi için kilitli hesaplarda bile giriş denemelerini bilinçli olarak karma yolundan geçirmesinden doğuyor. PAM olmayan bir musl sistemi üzerinde, fazla uzun bir parola gönderen saldırgan crypt'ten * sonucunu alıyor — hesap için saklanan kilit işaretiyle birebir aynı — ve kimlik doğrulama karşılaştırması başarılı oluyor.

musl neden POSIX'ten saptı

POSIX, crypt()'in başarı durumunda karmalanmış parolaya bir işaretçi döndürmesini, aksi halde errno ayarlanmış null işaretçi döndürmesini belirtir. Yazıda açıklandığı gibi, C'nin tip sistemi çağırıcıyı null kontrolü yapmaya zorlayamıyor ve musl geliştiricileri bu kontrolü atlayan gerçek ikili dosyalar gözlemlemişti. Spesifikasyondan sapmayı seçtiler ve null işaretçi yerine * sentinel değerini döndürdüler.

Bu pragmatik sapma, sorunun başladığı yerdir. Spesifikasyona uygun bir null dönüş, kendi riskleri ne olursa olsun, asla kilitli hesap geleneğiyle çakışmazdı.

Tip sistemi hatası değil, kültür hatası

Yazar önemli bir nüansa işaret ediyor: bu bir bellek güvenliği açığı değil ve daha güçlü tip sistemlerine sahip diller bunu otomatik olarak engellemezdi. Bir Rust fonksiyonu da tıpkı böyle, fazla uzun bir parola için * döndürebilirdi. Yazının savunusuna göre fark, topluluk normlarında yatıyor. Rust gelenekleri çağırıcının mutlaka ele almak zorunda olduğu bir hata varyantı talep ederdi ve böyle bir varyant yoksa, API muhtemelen bir RustSec bülteniyle birlikte kırıcı bir değişikliğe uğrardı. C'de result tipleri ve cebirsel veri tipleri olmadığından, bant içi sinyalleme en az dirençli yol haline geliyor.

Yazı bunu, Rust bağımlılıklarına direnen Linux dağıtımı geliştiricilerine yönelik bir eleştiriye genişletiyor. Derleme sürelerinde ve niş mimarilere taşınabilirlikteki gerçek maliyetleri kabul ediyor, ancak bu direnci bir anapratik-vekil sorunu olarak çerçeveliyor: geliştiricilerin kullanıcılarının büyük çoğunluğunun güvenliği yerine kendi kolaylıklarını gözetmesi.

Agent'lar bir çıkış yolu değil

Yazı ayrıca daha yeni bir savı da çürütüyor: LLM tabanlı kodlama agent'ları bellek güvenliği ve hata işleme konusunda akıl yürütebildiğine göre, ekipler derleme hızı ve taşınabilirlik için C — hatta assembly — yazmaya devam edebilir. Yazarın karşı savı şu: agent'lar mevcut kod üzerinde örüntü eşleştirmesi yapar ve kütüphane ekosistemlerinden yararlanır; dolayısıyla Rust yazan bir agent, Rust tiplerine ve deyimlerine zaten kodlanmış değişmezleri devralır. Ayrıca result tipleri gibi deterministik araçların kanıtlanmış biçimde çalıştığı bir ortamda olasılıksal bir sürece güvenmeyi şüpheli bir bahis olarak nitelendiriyorlar.

Neden önemli

Birincisi, acil ve pratik bir maruziyet var: PAM olmadan sshd çalıştıran Alpine ve diğer musl tabanlı sistemler, yazının atıfta bulunduğu Alpine bültenine başvurmalı; çünkü bu açık, kilitli bir hesabı potansiyel olarak root düzeyinde açık bir kapıya dönüştürüyor.

İkincisi, hata, alışılmış bellek güvenliği söyleminin dışında kalan bir arıza sınıfını örnekliyor: temel C kütüphanelerinde sentinel çakışmaları ve bant içi sinyalleme. 2012'de anlaşılabilir nedenlerle yapılan bir spesifikasyon sapması, yıllar sonra kimlik doğrulama semantiğini sessizce değiştirdi.

Üçüncüsü, bu dil ekosistemlerinin kendilerinin de güvenlik altyapısı olduğu yönünde bir sav. Bir topluluğun hata işleme çevresinde dayattığı gelenekler, böyle bir hatanın derleme zamanı tartışması mı yoksa üretim olayı mı olacağını belirliyor.