OpenSSH 10.4: Önce İstemcileri Yamalayın, Sonra Post-Quantum Anahtarları Deneyin

OpenSSH 10.4 bugün yayınlandı ve güvenlik bölümündeki ilk iki madde sshd ile değil, istemcilerle ilgili. Kötü niyetli bir sunucu, sftp veya scp'nin dosyaları hiç istemediğiniz bir yere yazmasına yol açabiliyordu. Birçok ekipte scp ve sftp, terminal başındaki bir insandan çok deploy script'lerinden, CI artifact çekme adımlarından ve yedekleme job'larından çalışır. Bu sürümün asıl önemli olduğu yer de tam orası. Sürüm ayrıca post-quantum SSH imzaları için deneysel ve isteğe bağlı (opt-in) destek getiriyor.

Önce istemcileri yamalayın#

Duyuruda anlatıldığı haliyle iki düzeltme şöyle:

• sftp host:/path .: komut satırından indirme yaparken kötü niyetli bir sunucu, dosyanın beklenmedik bir konuma düşmesini sağlayabiliyordu.
• İki uzak hedef arasında scp: kötü niyetli bir sunucu, hedeflenen dizinin üst dizinine dosya yazabiliyordu.

İkisini de Swival Security Scanner tespit etti. Aynı sürüm, sunucu bir key re-exchange sırasında host key'ini değiştirirse istemci tarafında oluşabilecek bir use-after-free hatasını da düzeltiyor.

Burada önemli olan güvenin yönü. SSH sıkılaştırma denince genelde sunucuları istemcilere karşı korumak anlaşılır. Bu hatalarda ise açıkta kalan taraf istemci, çünkü sunucunun geri gönderdiğine güveniyor. Yani yamalamanız gereken makineler dışarıya bağlanan makineler: CI runner'lar, build agent'lar, yedekleme sunucuları, jump box'lar ve laptoplar. Filonuzdaki sshd'leri güncellemek bunların hiçbirini düzeltmez. En riskli olanlar da tam olarak kontrol etmediğiniz sunuculara bağlananlar; bir iş ortağının SFTP klasörü ya da zaten ele geçirilmiş olabilecek bir host gibi.

Duyuruda hiçbir CVE numarası yok. Araçlarınız CVE beslemeleriyle çalışıyorsa eski istemcileri işaretlemesine güvenmeyin. Runner ve deploy imajlarınızın içinde ssh -V'yi kendiniz çalıştırın.

Config'lerde grep'lemeye değer sunucu tarafı maddeler#

• internal-sftp kesilmesi. Varsayılan olmayan internal-sftp kullanıldığında sshd, uzun komut satırlarını 9. argümandan sonra sessizce kesiyordu. 10. veya daha sonraki pozisyondaki güvenlikle ilgili bir seçenek yok sayılıyordu. Subsystem ya da ForceCommand içinde uzun bir internal-sftp satırınız varsa flag'lerini sayın ve güvendiğiniz seçenekleri kontrol edin.
• DisableForwarding=yes, PermitTunnel=yes'i geçersiz kılmıyordu, dokümantasyon kıldığını söylese de. PermitTunnel varsayılan olarak kapalı.
• GSSAPI pre-auth DoS, yalnızca GSSAPIAuthentication açıksa geçerli; o da varsayılan olarak kapalı. MaxAuthTries bunu engellemiyordu, ama PerSourcePenalties cezalandırırdı. Ayrıca sunucu Windows Active Directory'ye katılmışsa GSSAPIStrictAcceptorCheck'in etkisiz olduğuna dair yeni bir dokümantasyon notu da eklendi.
• Minimum kimlik doğrulama gecikmesi. Bazı durumlarda uygulanmıyordu.

Bir şeyleri bozabilecek üç değişiklik#

• Daha sıkı re-keying. ssh ve sshd artık kimlik doğrulama sonrası bir key re-exchange sırasında KEX dışı mesaj gönderen karşı tarafın bağlantısını kesiyor. Önceden kötü niyetli bir karşı taraf bu mesajları cezasız şekilde göndermeye devam edebiliyor, mesajlar da buffer'lanıp boşuna bellek harcıyordu. RFC 4253 bölüm 7.1'in gerektirdiği gibi key exchange sırasında mesajları kısıtlamayan implementasyonların bağlantısı artık kesilebilir. OpenSSH olmayan her karşı tarafa karşı uzun tünelleri ve büyük transferleri test edin: appliance'lar, gömülü stack'ler, şirket içi istemciler.
• Linux'ta seccomp hataları artık ölümcül. seccomp sandbox açıkken sshd, SECCOMP veya NO_NEW_PRIVS'i etkinleştiremezse artık duruyor. Eskiden hatayı loglayıp çalışmaya devam ediyordu. Bunlara sahip olmayan sistemler sandbox'ı configure aşamasında kapatmalı.
• sshd -G artık karışık büyük/küçük harfli isimler basıyor, yalnızca küçük harf yerine PubkeyAuthentication gibi. Küçük harfli isimleri grep'leyen compliance script'leri sessizce eşleşmemeye başlayacak.

Sonuncusunun çözümü tek bir flag:

sshd -G | grep -i '^passwordauthentication'

Post-quantum imzalar, varsayılan olarak kapalı#

Yeni özellik, ML-DSA 44 ile Ed25519'u birleştiren bileşik (composite) bir post-quantum imza şeması için deneysel destek; şema draft-miller-sshm-mldsa44-ed25519-composite-sigs içinde tanımlanıyor. Bu bireysel bir Internet-Draft, tamamlanmış bir standart değil. Draft'ın belirtilen hedefi hem kuantum hem klasik saldırganlara karşı güvenlik: lattice tabanlı bir imza ekliyorsunuz, Ed25519'u da tutuyorsunuz; sahte imza üretmek isteyen birinin ikisini birden kırması gerekiyor.

Kullanmak için onu HostKeyAlgorithms, PubkeyAcceptedAlgorithms ve ilgili seçeneklere ekliyor, anahtarları ssh-keygen -t mldsa44-ed25519 ile üretiyorsunuz. Draft'taki algoritma adı [email protected].

Opt-in doğru varsayılan. Şema deneysel olarak etiketlenmiş, spesifikasyon hâlâ draft ve bağlantının iki ucunun da desteklemesi gerekiyor. Production host key'leri için hazır değil, ama lab ortamında öğrenmeye değer:

ssh -V                        # confirm the build is 10.4
ssh -Q key                    # key types this build reports
ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_pq_lab

Bu sürüm ayrıca wildcard pattern matcher'ı NFA tabanlı bir matcher ile değiştiriyor; böylece eski matcher'ın üstel en kötü durumundan kaçınılıyor.

Ben ne yapıyorum#

Bu hafta bir ekibe vereceğim sıralama şu:

• scp veya sftp'nin gözetimsiz çalıştığı her yeri listeleyin ve dağıtımınız düzeltmeyi yayınlar yayınlamaz bu istemcileri güncelleyin.
• sshd config'lerinde internal-sftp, PermitTunnel ve GSSAPIAuthentication için grep yapın.
• Tüm sshd -G kontrollerini büyük/küçük harfe duyarsız hale getirin.
• OpenSSH olmayan her karşı tarafa karşı uzun bir tünel ve büyük bir transfer çalıştırın.
• İki kullan-at VM arasında bir mldsa44-ed25519 anahtarı deneyin ve bundan öteye geçmeyin.

Benim tarafımda önceliği Next.js'i self-host ettiğim VPS ve ona bağlanan makineler alıyor. Post-quantum anahtarlar lab'da kalıyor. Şu sıralar CEH materyali üzerinde çalışıyorum ve bu sürüm, istemcinin otomatik olarak güvenli taraf olmadığını iyi bir şekilde hatırlatıyor.