Ing. Calogero Bono
5 Kasım 2026'da, «*sshole» olarak adlandırılan bir hatayı düzelten OpenSSH 10.6p2 yayımlandı. Hata, musl kütüphanesini kullanan ve PAM'i devre dışı bırakılmış Alpine Linux gibi Linux sunucularındaki SSH servislerini ilgilendiriyor. SSH kapısına ulaşabilen biri, çok uzun bir parola göndererek bir hesaba parolasız girebiliyor. Bu önemli, çünkü tek bir bağlantı yeterli ve Alpine'in resmi bulut imajları root erişimi verebiliyor.
Olaylara girmeden önce birkaç terim. musl, Alpine, OpenWrt, Buildroot ve Yocto tarafından kullanılan, glibc'ye alternatif bir C kütüphanesidir. crypt(), bir parolayı karmasına dönüştüren işlevdir. PAM, Linux'un modüler kimlik doğrulama sistemidir. /etc/shadow, parola karmalarını tutan dosyadır. doas, sudo'ya benzer, root yetkisi almaya yarayan bir araçtır.
*sshole hatası nasıl çalışıyor?
Linux'ta parolası olmayan bir hesabın /etc/shadow dosyasında karma yerine bir yıldız işareti bulunur. Hiçbir parola bu hesabı açmamalı. BleepingComputer'a göre, 2016'da CVE-2016-6210 kullanıcı numaralandırma sorununu düzeltmek için OpenSSH'ye yapılan bir değişiklik, bu hesaplar için de karma hesaplanmasına yol açmış.
Burada musl devreye giriyor. Alpine'in uyarısında açıklandığı gibi, musl'ün crypt() işlevi anahtar 256 bayttan uzunsa hata sinyali olarak * döndürüyor. Bu yıldız, hesapta kayıtlı olanla eşleşiyor ve karşılaştırma başarılı oluyor. Araştırmacı Özgün Kültekin, kusurun 2016'dan beri var olduğunu söylüyor.
Gerçekten risk altında olanlar kimler?
Birden fazla koşulun aynı anda sağlanması gerekiyor. Alpine'e göre openssh-server paketi PAM olmadan derlenmiş olmalı ya da openssh-server-pam ile UsePAM no kullanılıyor olmalı. PasswordAuthentication, varsayılan ayar gibi açık olmalı. * içeren bir hesabın yanında $5$ ya da $6$ karması olan en az bir hesap bulunmalı. Parolası olan tek bir kullanıcı, diğer tüm hesapların erişilebilir olmasına yetiyor.
Alpine, 3.21'den 3.24'e ve edge sürümlerine ek olarak eski 3.16-3.20 sürümlerini doğruladı. sshd çalıştırmayan konteynerler, PasswordAuthentication no kullanan sistemler ve PAM'i etkin olan sistemler etkilenmiyor. BleepingComputer'a göre glibc kullanan Debian, Ubuntu ve Fedora savunmasız değil.
Alpine'in bulut imajları neden endişe yaratıyor?
3.18.11'den 3.24.3'e kadar olan resmi tiny-cloud imajlarında, parolası * olan ve parolasız doas yetkisi bulunan bir alpine kullanıcısı var. Alpine, bu imajların ilk açılışta güvenli olduğunu belirtiyor. Bir $6$ karması ortaya çıktığında sömürülebilir hale geliyorlar; örneğin bir yönetici konsol parolası belirlediğinde ya da user-data hashed_passwd ile bir kullanıcı eklediğinde.
Bu noktada saldırgan alpine olarak bir kabuk alıyor ve doas ile root oluyor. PasswordAuthentication no yazan cloud-init ile yapılandırılmış imajlar etkilenmiyor. Root için varsayılan PermitRootLogin prohibit-password ayarı yalnızca doğrudan erişimi engelliyor.
Nasıl düzeltilir ve bir saldırı nasıl kontrol edilir?
Düzeltme OpenSSH 10.6p2 içinde. Alpine'de apk upgrade -U -a komutunu çalıştırıp ardından sshd'yi yeniden başlat, çünkü güncelleme çalışan servisi değiştirmiyor. Alpine, desteklenmeyen sürümler dahil 3.16'ya kadar düzeltilmiş paketler yayımladı.
Güncelleyemiyorsan PasswordAuthentication no ayarını yap ve sshd'yi yeniden başlat; önce anahtarla girişin çalıştığını doğrula. İz aramak için /var/log/messages dosyasında parolasız hesaplar için «Accepted password» satırlarına bak. Alpine, erişimi dışlayamıyorsan makinenin ele geçirilmiş sayılması gerektiğini ekliyor. Hesap izinleri için Linux izinleri rehberine de göz atabilirsin.
Bilmen gereken sınırlar
Alpine, yayım sırasında hiçbir CVE numarası atanmadığını belirtiyor. OpenSSH, kökenin sshd dışında aranması gerektiğini yazıyor, ancak sömürü sshd üzerinden mümkün ve orada önlenmiş durumda. Devam eden gerçek saldırılara dair bir veri yok. Araştırmacının 17.600 yapay zekâ ajanı testine ilişkin iddiaları BleepingComputer'dan aktarılıyor ve bağımsız olarak doğrulanmış değil.
Dijitalle çalışanlar için ne değişiyor
Alpine sunucuları, OpenWrt yönlendiricileri veya Yocto ve Buildroot ile gömülü sistemler kullanıyorsan, sshd'nin parolaya izin verip vermediğini ve * içeren hesapların bulunup bulunmadığını kontrol et. Birçok kişi Alpine'i sshd olmadan konteynerlerde kullanıyor ve bunlar etkilenmiyor. tiny-cloud imajlarıyla bulut makinesi işletenler, çalışan her örneği doğrulamalı. Düzenli güncellemeler alan yönetilen bir sunucu bu tür riski azaltır, bunu barındırma ve yönetilen sunucular sayfamızda anlatıyoruz. Bağlantılı olarak yapay zekâ tarafından üretilen istismar kodlarını da bu yazımızda ele aldık, takip etmekte fayda var.
Bizim görüşümüz
Bu vaka, birbirine güvenen bileşenler arasındaki sınırın ne kadar kırılgan olduğunu gösteriyor. OpenSSH 2016'da meşru bir savunma ekledi, musl yaygın bir hata değeri seçti ve birlikte on yıl boyunca bir kapı açık kaldı. Hatanın yapay zekâ ajanlarıyla bulunmuş olması da dikkat çekici. OpenSSH'nin kendisi, yapay zekâyla bulunan hataların sık sık başkaları tarafından yeniden keşfedildiğini uyarıyor, bu yüzden beklemek risk. Yine de en sağlam çözüm hâlâ aynı – parola yerine anahtar kullanmak.
Sık sorulan sorular
Debian ve Ubuntu *sshole'a karşı savunmasız mı?
Hayır. Bunlar glibc kullanıyor, musl değil. BleepingComputer, PAM kimlik doğrulaması olan sistemlerin etkilenmediğini doğruluyor, ancak Alpine, openssh-server-pam ile UsePAM no kullanıldığında açık olduğunu, UsePAM yes ile olmadığını belirtiyor.
Sadece openssh paketini güncellemek yeterli mi?
Hayır, sshd'yi de yeniden başlatman gerekiyor. Alpine, güncellemenin çalışan servisi değiştirmediğini, bu yüzden savunmasız sürümün aktif kalacağını belirtiyor.
Güncelleme yapmadan kendimi koruyabilir miyim?
Evet, geçici olarak. sshd yapılandırmasında PasswordAuthentication no ayarını yap ve servisi yeniden başlat. Önce anahtarla girişin çalıştığını doğrula.
Root hesabı da açık mı?
Sadece belirli durumlarda. Varsayılan olan PermitRootLogin prohibit-password ayarıyla root doğrudan erişilemez. PermitRootLogin yes etkinse ya da başka bir kullanıcı doas gibi araçlarla root olabiliyorsa risk oluşur.
Bu hata için bir CVE var mı?
Alpine'e göre henüz yok. Uyarıda, yazım sırasında hiçbir tanımlayıcının atanmadığı belirtiliyor. Referans olarak OpenSSH 10.6p2 sürüm notlarına bakılabilir.
OpenSSH 10.6p2 sonrasında neleri takip etmelisin
OpenSSH, düzeltmeleri kullanıcılara daha hızlı ulaştırmak için daha sık sürüm yayımlayacağını duyurdu. Hata, takip edilmesi gereken birkaç soruyu açık bırakıyor.
- Bir CVE atanıp atanmayacağını ve tarama araçlarının bunu tanıyıp tanımayacağını kontrol et.
- OpenWrt, Buildroot ve Yocto tabanlı firmware üreticilerinin güncellemeleri ne zaman yayımlayacağını takip et.
- Planlanmış sürümleri beklemeden OpenSSH'nin küçük sürümlerini kurabileceğin bir rutin hazırla.
