OpenSSH 10.6p2, PAM olmadan çalışan musl sistemlerindeki parola kimlik doğrulama atlamasını düzeltiyor

Ne oldu

OpenSSH 10.6p2, parola denetimini PAM'ın yapmadığı durumlarda musl libc ile derlenmiş sunucuları etkileyen bir parola kimlik doğrulama atlamasını düzeltiyor. CVE-2026-123158 olarak takip edilen ve açıklamada *sshole olarak adlandırılan bu hata, saldırganın geçerli bir parola bilmeden belirli hesaplara kimlik doğrulaması yapmasına olanak tanıyor. Wakefield'den Özgün Kültekin'in araştırmasını özetleyen bir dev.to yazısına göre sorun yüksek önem derecesine sahip ve musl tabanlı sistemlerde — Alpine Linux, OpenWrt, Buildroot ve Yocto dağıtımları örnek olarak veriliyor — PAM'ın devre dışı bırakıldığı veya derlemeye dahil edilmediği yamalanmamış OpenSSH sürümlerini etkiliyor.

Atlama nasıl çalışıyor

Hata, bir hata değeri ile bir kilit işareti arasındaki çakışmadan kaynaklanıyor. Belirli parola özetleme algoritmalarında, musl'nin crypt() fonksiyonu verilen parola 256 baytı aştığında harfi harfine * dizgesini döndürüyor. Ayrıca saklanan parola alanı * olan hesaplar geleneksel olarak kilitli kabul edilir ve parola ile oturum açmamaları gerekir. Savunmasız OpenSSH kodu crypt() çıktısını hedef hesabın saklanan alanıyla karşılaştırdığından, musl * döndürdüğünde karşılaştırma saklanan * ile eşleşiyor ve oturum açma başarılı oluyor.

Bir bileşen daha gerekiyor. Zamanlama ile ilgili parola denetimi davranışının bir parçası olarak OpenSSH, sistemdeki başka bir hesaptan alınan bir salt kullanıyor ve atlama yalnızca ödünç alınan bu salt $5$ (SHA-256) veya $6$ (SHA-512) biçiminde olduğunda çalışıyor.

dev.to analizine göre sonucu girdinin uzunluğu belirliyor. 1 ila 256 bayt arasındaki parolalar normal şekilde özetlenir ve hiçbir zaman * olmaz, dolayısıyla başarısız olurlar. 1024 bayttan uzun parolalar OpenSSH tarafından crypt() çağrılmadan önce reddedilir. Yalnızca 257 ile 1024 bayt aralığı hata dizgisini üretir — ve gerçek bir parola özeti tutan hesaplar etkilenmez, çünkü * gerçek özetleriyle eşleşmez.

Sömürünün koşulları

dev.to analizi aynı anda hepsinin geçerli olması gereken altı koşul listeliyor:

• Sunucu musl libc üzerinde yamalanmamış OpenSSH çalıştırıyor.
• PAM devre dışı veya mevcut değil, dolayısıyla denetimi OpenSSH kendisi yapıyor.
• Etkin yapılandırmada PasswordAuthentication açılmış.
• Hedef hesabın parola alanı * ve hesabın oturum açmasına izin veriliyor.
• Sistemdeki başka bir hesap, ödünç alınan saltı sağlayacak bir $5$ veya $6$ özeti taşıyor.
• Saldırgan 257 ile 1024 bayt arasında bir parola gönderiyor.

Diğer oturum açma kısıtlamaları geçerliliğini koruyor. Örneğin PermitRootLogin prohibit-password, bu yolla doğrudan root parolasıyla oturum açmayı engelliyor. Root'a yükselme, ele geçirilen hesabın parolasız doas veya sudo erişimine bağlı ayrı bir aşama. Yazı ayrıca Alpine'ın tiny-cloud imajlarının ilk açılışta istisnasız sömürülebilir olarak tanımlanmaması konusunda uyarıyor — özet koşulu da karşılanmalı — ancak bir kez karşılandığında parolasız doas'a sahip varsayılan kullanıcı root'a giden bir yol sunabilir.

Yamalama ve tespit

OpenSSH 10.6p2 ve satıcı geri portları düzeltmeyi içeriyor, ancak güncellenmiş paketi kurmak tek başına yeterli değil: yamalanmış kodun yüklenmesi için çalışan sshd'nin yeniden başlatılması gerekiyor.

Geçmiş maruziyeti denetleyen ekipler için karakteristik iz, saklanan alanı * olan ve parola ile oturum açması hiçbir zaman amaçlanmamış bir hesaba ait bir Accepted password kaydı. Alpine'ın güvenlik duyurusu araştırma kaynağı olarak /var/log/messages'a işaret ediyor, ancak saklama süresi sisteme bağlı olarak değişiyor. dev.to analizi iki uyarı ekliyor: başarılı bir kimlik doğrulama kaydı tek başına root'a yükselmeyi kanıtlamaz ve şifrelenmiş paket boyutları bu atlamanın kullanılıp kullanılmadığını belirleyemez, çünkü parola uzunluğu analizi kimlik doğrulama ucundaki görünürlük gerektirir.

Neden önemli

* parola alanı bir kilit işaretidir ve bu hata kilidin kendisini anahtara dönüştürdü: hiçbir parolanın asla çalışamayacağını göstermek için kullanılan dizge, saldırganın üretmesi gereken değere dönüştü. musl tabanlı sistemler tam da başsız SSH yönetiminin standart olduğu yerlerde yaygındır — container'lar, yönlendiriciler ve diğer gömülü dağıtımlar — dolayısıyla ön koşullar daraltsa da savunmasız profile uyan sunucu kitlesi önemli. İki operasyonel ders öne çıkıyor. Bir hesabı SSH anahtarlarına geçirmek, sunucu genelinde parola kimlik doğrulaması açık kaldığı sürece * bir hesabı güvenli kılmaz. Ayrıca düzeltme yalnızca sshd yeniden başlatıldıktan sonra etkili olur — yama otomasyonunun sıklıkla atladığı ve yöneticilerin sunucu sunucu doğrulaması gereken bir adım.