OpenSSH'de Kritik Açık: Alpine Linux'ta Uzun Parolalarla SSH Kimlik Doğrulaması Atlatılabiliyor

OpenSSH projesi, Alpine Linux üzerinde standart openssh-server paketi çalıştıran sunucularda parola girişi kapalı olsa bile hesaplara yetkisiz erişim sağlanabilen kritik bir güvenlik açığını gidermek amacıyla 10.6p2 sürümünü acil olarak yayımladı. Açık, saldırganların 257 ile 1.024 bayt arasında bir parola, sunucuya ağ erişimi ve geçerli bir hesap adıyla birlikte parola atanmamış hesaplara —SSH anahtarıyla korunan hesaplar dahil— oturum açmasına imkân tanıyor. Alpine Linux da 3.16 sürümüne kadar uzanan tüm dallar için düzeltilmiş paketleri yayımladı.

Açık Nasıl Çalışıyor?​

Sorunun teknik kökü, Alpine Linux'un dayandığı C kütüphanesi olan musl ile OpenSSH'nin parola doğrulama mekanizması arasındaki etkileşimde yatıyor. OpenSSH sunucusu (sshd), PAM (Pluggable Authentication Module) arayüzü kullanılmadan parola denetimi yaptığında, girilen parolayı crypt() fonksiyonuyla hash'leyerek saklanan değerle karşılaştırıyor. Parola atanmamış hesaplarda bu saklanan alan yalnızca * karakterinden oluşuyor; bu değer bir hash için gereken rastgele ön ek (salt) barındırmaya yetecek uzunlukta olmadığından sshd, başka bir hesabın salt değerini ödünç alıyor.
İşte bu noktada musl devreye giriyor: musl'un crypt() uygulaması, $5$ ve $6$ hash türleri için 256 baytı aşan parolaları reddediyor ve hata sinyali olarak * döndürüyor. Bu * değeri, hesabın saklanan * alanıyla birebir örtüştüğünden sshd girişi kabul ediyor. Saldırganın yapması gereken tek şey, 257 ile 1.024 bayt arasında herhangi bir parola göndermek.
OpenSSH projesinden Damien Miller, bu davranışın musl'da Ağustos 2012'de yapılan iki ayrı değişiklikten ve OpenSSH'de Temmuz 2016'da CVE-2016-6210'u gidermek amacıyla eklenen salt ödünç alma mekanizmasından kaynaklandığını açıkladı. Açığı keşfeden Özgün Kültekin ise sorunun o tarihten bu yana var olduğunu belirtiyor.

Hangi Sistemler Etkileniyor?​

Alpine'ın güvenlik danışma belgesi, bir sunucunun risk altında sayılabilmesi için dört koşulun aynı anda sağlanması gerektiğini açıklıyor. Bunlar sırasıyla şunlar: PAM desteği olmadan derlenmiş openssh-server paketinin ya da UsePAM no ayarıyla openssh-server-pam paketinin kullanılması; PasswordAuthentication değerinin varsayılan olan yes olarak kalması; en az bir hesabın parola alanında * bulunması ve sistemdeki başka bir yerel hesabın $5$ veya $6$ ile başlayan bir parola hash'ine sahip olması.
Alpine üzerinde parola atanmamış hesap kategorisine girenler arasında adduser komutuyla parola belirlenmeden oluşturulan anahtar tabanlı kullanıcılar, musl-nscd aracılığıyla dizin servisinden gelen kullanıcılar, yaklaşık Alpine 3.16'dan bu yana temel imajda root:* biçiminde gönderilen root hesabı ve resmi bulut imajlarındaki alpine kullanıcısı yer alıyor. Root hesabı, varsayılan PermitRootLogin prohibit-password ayarı sayesinde doğrudan hedef alınamıyor; ancak açığa maruz kalan bir hesap doas gibi araçlarla root ayrıcalığı kazanabiliyorsa bu koruma işe yaramıyor.
Tiny-cloud imajlarının 3.18.11 ile 3.24.3 sürümleri arasında alpine kullanıcısına parolasız doas yetkisi tanındığı belirtiliyor. Bu imajlar ilk açılışta güvende olsa da sistemde herhangi bir $6$ hash oluştuğu anda —örneğin bir yönetici konsol parolası belirlediğinde— saldırıya açık hale geliyor. Saldırgan alpine hesabına giriş yapıp doas ile root olabiliyor.
Öte yandan glibc tabanlı Linux sistemleri, PAM üzerinden parola denetimi yapan sistemler ve Linux dışı işletim sistemleri bu açıktan etkilenmiyor. sshd çalıştırmayan konteynerler, PasswordAuthentication no ayarlı sistemler ve cloud-init aracılığıyla yapılandırılan bulut imajları da güvende. Ayrıca Kültekin, OpenWrt ve Buildroot gibi musl tabanlı diğer sistemlerin de kontrol edilmesi gerektiğini vurguluyor; ancak OpenWrt'nin varsayılan SSH çözümü olan Dropbear'ın bu açıktan etkilenmediğini de ekliyor.

Düzeltme ve Geçici Önlemler​

Alpine üzerinde düzeltme, paket güncellemesi ve ardından sshd'nin yeniden başlatılmasından oluşuyor; çünkü paket yükseltmesi çalışan sshd sürecini otomatik olarak yeniden başlatmıyor. Bunun için sırasıyla apk upgrade -U -a ve rc-service sshd restart komutlarının çalıştırılması gerekiyor. 3.21.10, 3.22.8, 3.23.8 ve 3.24.4 nokta sürümleri düzeltilmiş paketi zaten içeriyor; destek süresi dolmuş olan 3.16 ile 3.21 arası dallar için de düzeltme paketi yayımlandı. OpenSSH'yi kaynaktan derleyenler için ise 10.6p2 sürümü ilgili değişikliği içeriyor.
Güncelleme hemen yapılamıyorsa parola girişini devre dışı bırakmak saldırıyı durduruyor. Bunun için önce SSH anahtarıyla girişin çalıştığından emin olunması, mevcut oturum açık tutularak PasswordAuthentication no ayarının yapılması, sshd -t komutuyla yapılandırmanın doğrulanması ve ardından sshd'nin yeniden başlatılması öneriliyor. Damien Miller, etkilenen sistem yöneticilerine bu ayarı derhal uygulamalarını ya da bu sistemler için SSH'yi kapatmalarını tavsiye etti.
Danışma belgesi ayrıca /var/log/messages dosyasında parola atanmamış hesaplar için Accepted password içeren sshd satırlarının aranmasını öneriyor. Şüpheli giriş ihtimali göz ardı edilemiyorsa makine ele geçirilmiş kabul edilmeli; doas kullanımı, yakın zamanda oluşturulan kullanıcılar, dosyalar ve yetkili anahtarlar gözden geçirilmeli.

Düzeltmenin Teknik Özü ve Yayımlanma Hızı​

10.6p2'deki kod değişikliği, saklanan parola alanı dört karakterden kısaysa sshd'nin eşleşmeyi reddetmesini sağlıyor. OpenSSH ekibi bunu bir geçici çözüm olarak nitelendiriyor ve asıl sorunun sshd dışında yattığını belirtiyor. Açığa bugüne kadar herhangi bir CVE tanımlayıcısı atanmadı.
Miller, ekibinin açığı bu hafta öğrendiğini ve düzeltmeyi olabildiğince hızlı yayımladığını açıkladı. Yayın duyurusunda uzun süreli gizlilik dönemlerini artık tehlikeli bulduklarını ve esas olarak saldırganlara yarar sağladığını ifade etti; bunun nedenini de yapay zeka ajanlarının aynı hataları bazen saatler içinde yeniden keşfettiğini son dönemde gözlemlemelerine bağladı.

Sıkça Sorulan Sorular​

Bu açık hangi Alpine Linux sürümlerini etkiliyor?​

Açık, PAM desteği olmadan derlenmiş openssh-server paketini çalıştıran Alpine Linux sunucularını etkiliyor. Alpine, 3.16'dan 3.24'e kadar uzanan tüm sürümler için düzeltilmiş paketler yayımladı; destek süresi dolmuş olan 3.16-3.21 arası dallar da bu güncellemeden yararlandı.

Saldırı başarılı olmak için ne gerektiriyor?​

Saldırganın sunucuya ağ erişimine, geçerli bir hesap adına ve 257 ile 1.024 bayt arasında herhangi bir parolaya ihtiyacı var. Bunların yanı sıra hedef sistemde en az bir hesabın $5$ veya $6$ ile başlayan bir parola hash'ine sahip olması ve saldırıya hedef hesabın parola alanında yalnızca * bulunması gerekiyor. Danışma belgesine göre saldırı tek bağlantıyla her denemede başarıya ulaşıyor.

glibc tabanlı Linux sistemleri bu açıktan etkileniyor mu?​

Hayır. OpenSSH projesinden Damien Miller, glibc tabanlı Linux sistemlerinin, PAM aracılığıyla parola denetimi yapan sistemlerin ve Linux dışı işletim sistemlerinin bu açıktan etkilenmediğini açıkladı. Açık yalnızca musl C kütüphanesiyle derlenen sistemlerde ortaya çıkıyor.

Güncelleme yapılamıyorsa ne yapılmalı?​

Güncelleme hemen uygulanamıyorsa PasswordAuthentication değerini no olarak ayarlamak saldırıyı durduruyor. Bunun için önce SSH anahtar girişinin çalıştığından emin olunması, ardından ayarın yapılıp sshd -t ile doğrulanması ve sshd'nin yeniden başlatılması gerekiyor. Damien Miller, etkilenen yöneticilere bu adımı derhal atmalarını ya da söz konusu sistemler için SSH'yi tamamen kapatmalarını tavsiye etti.

Açık yalnızca Alpine Linux ile mi sınırlı?​

Hayır. Açığı keşfeden Özgün Kültekin, teknik yazısında OpenWrt, Buildroot ve Yocto gibi musl tabanlı diğer sistemlerin de kontrol edilmesi gerektiğini belirtiyor. Ancak OpenWrt'nin varsayılan SSH çözümü olan Dropbear'ın bu açıktan etkilenmediğini de ekliyor; OpenWrt'de sorun yalnızca bir yöneticinin OpenSSH sunucusunu ayrıca kurduğu durumlarda geçerli olabiliyor.