OpenSSH, Alpine Linux’ta Uzun Parolalarla SSH Kimlik Doğrulamasını Atlayan Güvenlik Açığına Acil Yama Yayınladı

OpenSSH, Alpine Linux’ta Uzun Parolalarla SSH Kimlik Doğrulamasını Atlayan Güvenlik Açığına Acil Yama Yayınladı

OpenSSH, bazı Alpine Linux sunucularında standart openssh-server paketi çalıştıran ve SSH anahtarı tabanlı hesaplar gibi parola içermeyen hesaplara saldırganların giriş yapmasına olanak tanıyan kritik bir güvenlik açığı için acil bir düzeltme yayınladı. Bu saldırı için sunucuya ağ erişimi, bir hesap adı ve 257 ila 1.024 bayt uzunluğunda bir parola gerekmektedir.

OpenSSH, bu kritik güvenlik açığını kapatmak amacıyla 5 Kasım 2026 tarihinde 10.6p2 sürümünü yayımladı. Alpine ise 3.16 sürümünden itibaren tüm sürümler için düzeltilmiş paketleri kullanıma sundu.

Güvenlik Açığının İşleyişi

Saldırı, OpenSSH sunucusunun (sshd) Parola Kimlik Doğrulama Modülü (PAM) arayüzünü kullanmadan parolaları kontrol ettiği, parola girişlerinin etkin olduğu ve makinede en az bir başka hesabın parolası bulunduğu durumlarda işler. Alpine’ın openssh-server paketi PAM olmadan derlenmiştir ve parola girişleri varsayılan olarak açıktır.

Bu güvenlik açığı, sshd‘nin Alpine’ın temelini oluşturan C kütüphanesi musl ile çalışma şeklinden kaynaklanmaktadır. OpenSSH projesinden Damien Miller’ın belirttiğine göre, Linux dışı sistemler, glibc üzerine kurulu Linux sistemleri ve parolaları PAM aracılığıyla kontrol eden sistemler bu durumdan etkilenmemektedir.

Miller, etkilenen bir sistem çalıştıran herkese “PasswordAuthentication=no olarak ayarlamalarını veya bu sistemler için SSH’yi DERHAL devre dışı bırakmalarını” tavsiye etti. Şu ana kadar bu güvenlik açığını kullanan herhangi bir saldırı bildirilmemiştir.

Kimler Risk Altında?

Alpine’ın güvenlik danışmanlığına göre, bir sunucu aşağıdaki dört koşulun hepsi doğru olduğunda risk altındadır:

• PAM olmadan derlenmiş openssh-server paketi çalıştırıyor veya UsePAM no ile openssh-server-pam çalıştırıyor.
• PasswordAuthentication yes olarak ayarlanmış, ki bu OpenSSH’nin varsayılanıdır.
• Bir hesabın parola alanı * olarak ayarlanmış, yani parola belirlenmemiş.
• En az bir başka yerel hesabın parola karması $5$ veya $6$ ile başlıyor.

Saldırganın ayrıca parola içermeyen bir hesabın adını bilmesi gerekmektedir. Bir parolalı hesap, parola içermeyen her hesabı riske atmak için yeterlidir. Danışmanlığa göre, saldırı tek bir bağlantıyla her denemede başarılı olmaktadır.

Alpine’da parola ayarlanmamış hesaplar şunları içerir:

• adduser ile parola olmadan veya usermod -p '*' ile oluşturulan yalnızca anahtar kullanıcıları.
• musl-nscd aracılığıyla dizin hizmetinden gelen kullanıcılar, çünkü bunların bir gölge girişi yoktur.
• Yaklaşık Alpine 3.16’dan beri temel görüntüde root:* olarak gönderilen root.
• tiny-cloud ile oluşturulan resmi bulut görüntülerindeki alpine kullanıcısı.

Root kullanıcısı, varsayılan PermitRootLogin prohibit-password ayarı ile korunmaktadır ve yalnızca PermitRootLogin yes ayarlanmışsa doğrudan erişilebilir. Bu koruma, risk altındaki bir hesabın örneğin doas aracılığıyla root olabilmesi durumunda yardımcı olmaz.

3.18.11’den 3.24.3’e kadar olan tiny-cloud görüntüleri, alpine kullanıcısına parolasız doas yetkisi verir. İlk önyüklemede güvenli olsalar da, makinede herhangi bir $6$ karması oluştuğunda (örneğin bir yönetici konsol parolası ayarladıktan sonra) saldırıya açık hale gelirler. Bir saldırgan daha sonra alpine olarak giriş yapabilir ve doas kullanarak root olabilir.

sshd çalıştırmayan konteynerler, PasswordAuthentication no ayarlı sistemler ve bu ayarı yazan cloud-init aracılığıyla kurulan bulut görüntüleri etkilenmez. /etc/shadow içinde ! ile kilitlenmiş hesaplar da etkilenmez, ayrıca hiçbir hesabın $- tarzı parola karması bulunmayan makineler de etkilenmez.

Güvenlik açığı sadece Alpine ile sınırlı değildir. Bu durumu bildiren Wakefield’dan Özgün Kültekin, teknik açıklamasında OpenWrt, Buildroot ve Yocto gibi diğer musl tabanlı sistemlerin de kontrol edilmesi gerektiğini belirtmiştir.

OpenWrt, varsayılan olarak SSH’yi Dropbear ile yönetir ve Kültekin, Dropbear’ın etkilenmediğini belirtmiştir. OpenWrt’de bu güvenlik açığı, yalnızca bir yöneticinin OpenSSH sunucusunu kurduğu yerlerde önemli olabilir.

Nasıl Düzeltilir?

Alpine’da düzeltme, bir paket güncellemesi ve ardından yeniden başlatma ile yapılır, çünkü paketi yükseltmek çalışan sshd‘yi yeniden başlatmaz:

1. Paketleri güncelleyin: apk upgrade -U -a
2. Sunucuyu yeniden başlatın: rc-service sshd restart

3.21.10, 3.22.8, 3.23.8 ve 3.24.4 nokta sürümleri zaten düzeltilmiş paketi içermektedir. 3.16’dan 3.21’e kadar olan dallar destek sonu geçmiş olsa da düzeltilmiş paketler almıştır.

Bu nokta sürümlerinden daha eski tiny-cloud görüntülerinden başlatılan bulut örnekleri hala güncellemeye veya aşağıdaki ayara ihtiyaç duymaktadır.

OpenSSH’yi kendiniz derliyorsanız, 10.6p2 sürümü değişikliği içermektedir. Sürüm notlarında bu durum açıklanmıştır.

Henüz güncelleme yapamıyorsanız, parola girişlerini kapatmak da saldırıyı durdurur. Öncelikle SSH anahtar girişinizin çalıştığından emin olun ve yeni bir giriş başarılı olana kadar mevcut oturumunuzu açık tutun. Ardından PasswordAuthentication no olarak ayarlayın, yapılandırmayı sshd -t ile kontrol edin ve sshd‘yi yeniden başlatın.

Danışmanlık, Alpine’ın varsayılan yapılandırmasının 3.19’dan itibaren okuduğu /etc/ssh/sshd_config.d içinde bir bırakma dosyasına ayarı ekleyen komutları vermektedir. Ayrıca /etc/ssh/sshd_config içindeki her PasswordAuthentication satırını, bir Match bloğunun içindeki satırlar da dahil olmak üzere yes‘ten no‘ya değiştirir. Sonrasında, sshd -T | grep -i passwordauthentication komutu passwordauthentication no çıktısını vermelidir.

Danışmanlık, /var/log/messages içinde parola içermeyen bir hesap (örneğin alpine, root veya yalnızca anahtar kullanıcısı) için “Accepted password for” okuyan sshd satırlarını kontrol etmeyi önermektedir. Risk altındaki makinelerde ayrıca doas kullanımını, yakın zamanda oluşturulan kullanıcıları, dosyaları ve yetkilendirilmiş anahtarları gözden geçirin.

“Bir girişi dışlayamıyorsanız, makineyi tehlikeye girmiş olarak kabul edin,” denilmektedir.

Uzun Parolalar Neden İşe Yarıyor?

PAM olmadan, sshd parolayı kendisi kontrol eder. Giriş denemesini, parolayı depolanmış biçimine dönüştüren C kütüphanesi işlevi crypt() ile hash’ler ve sonucu depolanmış alanla karşılaştırır.

Parola içermeyen bir hesabın bu alanda yalnızca * bulunur. Bu, bir tuz (hash’in rastgele öneki) tutmak için çok kısadır, bu nedenle sshd, gerçek bir hash’e sahip başka bir hesabın tuzunu ödünç alır.

$5$ ve $6$ hash türleri için, musl’un crypt() işlevi 256 bayttan uzun parolaları reddeder ve hatayı belirtmek için * döndürür. Bu *, depolanmış * ile eşleşir, bu nedenle sshd girişi kabul eder. Aralığın üst sınırı, sshd‘nin kendi parola başına 1.024 baytlık limitidir.

Bu davranış, 9 Ağustos 2012’deki bir musl değişikliğinden kaynaklanmaktadır. Bu değişiklik, başarısız bir crypt() çağrısının “birçok programın hatayı kontrol etmemesi nedeniyle NULL yerine eşleşmeyen bir hash” döndürmesini sağlamıştır. 256 baytlık limit, hizmet reddi saldırılarından sunucuları korumak için 29 Ağustos 2012’de takip etmiştir.

Tuz ödünç alma, 15 Temmuz 2016’daki bir OpenSSH değişikliğinden kaynaklanmaktadır. Bu değişiklik, saldırganların hangi kullanıcı adlarının var olduğunu öğrenmesine olanak tanıyan CVE-2016-6210 güvenlik açığını ele almıştır. Kültekin, sorunun o zamandan beri var olduğunu belirtmektedir.

10.6p2 kod değişikliği, depolanmış alan dört karakterden kısaysa sshd‘nin eşleşmeyi reddetmesini sağlar. OpenSSH bunu bir geçici çözüm olarak adlandırmakta ve temel nedenin sshd dışında yattığını belirtmektedir. Kararlı Alpine paketleri aynı sorun için bir yama içermektedir.

Düzeltme Neden Ertesi Gün Geldi?

Miller’ın ekibi, güvenlik açığını bu haftanın başlarında öğrendi ve düzeltmeyi mümkün olan en kısa sürede yayınladı. Yayın duyurusunda, ekibin artık uzun ambargoları tehlikeli ve esas olarak saldırganlara yardımcı olduğunu düşündüğünü belirtti, çünkü son zamanlarda yapay zeka ajanlarının aynı hataları bazen saatler içinde tekrar bulduğunu gözlemlemişlerdir.

Bu güvenlik açığına 5 Kasım 2026 tarihi itibarıyla henüz bir CVE tanımlayıcısı atanmamıştır.