Alpine Linux, 5 Kasım'da OpenSSH'da parola girişini açıkça reddedecek şekilde yapılandırılmış hesaplara saldırganların giriş yapmasını sağlayan bir kimlik doğrulama atlatma açığı için güvenlik duyurusu yayımladı. CVE-2026-123158 olarak izlenen ve *sshole takma adı verilen açık 8.1 yüksek olarak derecelendirildi ve arkasındaki hata 2016'ya uzanıyor. Düzeltilmiş OpenSSH 10.6p2 aynı gün yayımlandı; Alpine ise düzeltmeyi 3.16'ya kadar tüm dallara, artık desteklemediği sürümler dahil geri taşıdı.

Mekanizma, tek başına makul davranan üç bileşenin tartışması. Alpine'ın glibc yerine kullandığı musl libc'de crypt() işlevi 256 bayttan uzun parolaları reddeder ve * dizesini döndürür. Linux ise /etc/shadow dosyasında * işaretini "bu hesabın kullanılabilir parola özeti yok" anlamında kullanır. OpenSSH 2016'da hangi kullanıcı adlarının var olduğunu sızdırmamak için bir davranış ekledi; bu davranış PAM'siz musl sistemlerinde, hedef hesabın geçerli özeti olmasa bile başka bir hesabın ayarlarıyla özet hesaplayabiliyor. Shadow kaydı olan bir hesaba 257 ile 1.024 bayt arasında parola gönderin: karşılaştırma tutar, çünkü eşittir *. Kimlik doğrulama geçer.

Ön koşullar belirli ama egzotik değil. Sunucu, Alpine'ın openssh-server paketinin varsayılan olarak yaptığı gibi PAM olmadan musl üzerinde çalışmalı; parola ile giriş etkin olmalı; hedef hesabın shadow kaydında ! değil * bulunmalı; ve makinede en az bir başka hesabın gerçek parolası olmalı. Bunların hepsi sağlandığında — yalnızca anahtarla giriş yapan kullanıcılar, 3.16'dan itibaren Alpine'da root ve Alpine'ın AWS ile Azure imajlarındaki, parolasız doas çalıştırabilen varsayılan alpine kullanıcısı — tek bir giriş denemesi yeterli; o bulut imajlarında bu doğrudan root anlamına geliyor. Açığı Wakefield'dan Özgün Kültekin buldu; yayımlanan araştırmaya göre sshd'yi glibc, musl, PAM ve PAM'siz tüm kombinasyonlarda derleyip her birine yaklaşık 17.600 sıra dışı giriş denemesi gönderdi. Tüm derlemeler beklendiği gibi davrandı; yalnızca PAM'siz musl "evet" dedi.

Debian, Ubuntu ve Fedora bu yoldan etkilenmiyor; PAM kullanan sunucular, PasswordAuthentication no ayarlı makineler, ! kullanan hesaplar, sshd çalıştırmayan konteynerler ve Dropbear da etkilenmiyor. Bu liste önemli: "makinem risk altında mı" sorusunun büyük kısmı aslında CI'ın aylar önce derlediği Alpine konteyner imajının içinde sshd çalışıp çalışmadığına bakıyor.

Düzeltme, gerçek olamayacak kadar kısa kayıtlı özetleri reddediyor; böylece başarısız bir özet artık eşleşme gibi geçemiyor. Paketi yamamak, çalışan süreci yamamakla aynı şey değil — sshd yeniden başlatılmalı — ve imajları yeniden derlemek bir ana makineyi güncellemekten daha önemli: hatanın bir sonraki dağıtımla geri gelmesini yalnızca düzeltilmiş bir temel imaj engeller. Hemen güncelleyemiyorsanız, PasswordAuthentication no ile yalnızca anahtar doğrulaması açığı kapatır. Geçmişi kontrol etmek için günlüklerde parolası olmaması gereken hesaplar için "Accepted password" arayın; bulursanız makineyi ele geçirilmiş sayın.

Kaynaklar