regreSSHion Anatomisi: OpenSSH CVE-2024-6387’de SIGALRM Yarışı

Bir “SSH açığı”ndan daha fazlası

OpenSSH, Linux sunucularında uzaktan yönetimin varsayılan taşıyıcılarından biri. Bu nedenle sshd içindeki bir hata, tek bir uygulama hesabını değil; internete açık sunucuların kimlik doğrulama sınırını doğrudan etkileyebilir. CVE-2024-6387, Qualys tarafından “regreSSHion” adıyla duyurulan, OpenSSH sunucusunda sinyal işleyicisi ile ana işlem arasındaki zamanlama yarışına dayanan bir güvenlik açığıdır.

Başlıklar ilk günlerde “kimlik doğrulamasız root RCE” diye dolaştı. Bu ifade etkiyi anlatır, fakat mekanizmayı anlatmaz. OpenSSH’nin resmi 9.8 sürüm notları; Portable OpenSSH 8.5p1–9.7p1 aralığındaki sürümlerde, uygun koşullarda root yetkileriyle keyfi kod çalıştırmaya yol açabilecek kritik bir yarış bulunduğunu doğruluyor. Aynı notlar, 32-bit Linux/glibc üzerinde laboratuvar ortamında gösterilen saldırının uzun süreli bağlantılar ve yüksek tekrar gerektirdiğini, 64-bit sistemlerde olasılığın araştırıldığını belirtiyor. OpenSSH 9.8 sürüm notları

Bu ayrım önemli: “Uzaktan, kimlik doğrulamasız” ifadesi riskin yönünü gösterir; her ortamda aynı hızda veya aynı başarı oranıyla çalışacağı anlamına gelmez. Dağıtım yamaları, mimari, libc, ASLR, bağlantı sınırları, ağ filtreleri ve servis yapılandırması gerçek riski değiştirir. Yine de pre-authentication sınırında gerçekleşen bir bellek güvenliği hatası, internete açık SSH varlıklarında gecikmeden ele alınmalıdır.

Bu çalışma, exploit kodu veya üretim sistemlerine saldırı tarifi sunmuyor. Amaç, bug’ın neden oluştuğunu, hangi varlıkların etkilenebileceğini ve bir düzeltmenin gerçekten uygulandığının nasıl kanıtlanacağını açıklamak.

Kapsamı doğru okumak

Hangi sürümler etkileniyor?

Upstream Portable OpenSSH açısından OpenSSH 8.5p1’den 9.7p1’e kadar olan sürümler etkilenmiş kabul ediliyor. OpenSSH 9.8/9.8p1 ile düzeltme yayımlandı. NVD kaydı ve OpenSSH notları, sürüm aralığının dağıtım paketlerine doğrudan kopyalanamayacağını da gösteriyor: Debian, Ubuntu, Red Hat, SUSE ve benzeri dağıtımlar güvenlik düzeltmesini daha eski görünen paket sürümlerine backport edebilir.

Bu nedenle envanterde yalnızca ssh -V çıktısına bakmak yeterli değildir. Aşağıdaki dört veri birlikte kaydedilmelidir:

• çalışan sshd ikilisinin paket sürümü ve dağıtım revizyonu,
• paketin güvenlik değişiklik kaydı veya distro advisory’si,
• servis yöneticisinin gerçekten hangi ikiliyi çalıştırdığı,
• yeniden başlatma sonrası çalışan süreçlerin patch seviyesini taşıdığı.

Bir container imajındaki OpenSSH ile host üzerindeki SSH servisi aynı şey değildir. Bastion host, CI runner, jump host, VPN appliance, Kubernetes node, yönetim ağı ve yedekleme sunucuları ayrı varlıklar olarak taranmalıdır.

Kimler doğrudan etkilenmeyebilir?

OpenSSH’nin resmi notlarında OpenBSD’nin etkilenmediği belirtiliyor. Bunun sebebi “OpenBSD’de SSH güvenli, diğer her yerde güvensiz” gibi bir slogan değil; OpenBSD’nin sinyal işleme tasarımının bu hatanın koşullarını karşılamaması. Musl veya farklı libc kullanan sistemlerde de etki analizi ayrıca yapılmalı. OpenSSH notları, glibc dışındaki sistemlerin olası etkilenmesini tamamen dışlamıyor; yalnızca aynı koşulların incelenmediğini söylüyor.

Burada doğru ifade “vendor ve dağıtım advisory’siyle doğrulayın”. Bir sistemin işletim sistemi adına bakıp otomatik olarak güvenli ilan edilmesi doğru değildir.

sshd bağlantıyı nasıl yönetiyor?

Zafiyeti anlayabilmek için önce normal bağlantı akışını basitleştirelim:

TCP bağlantısı
      ↓
SSH banner / protokol müzakeresi
      ↓
LoginGraceTime için zamanlayıcı
      ↓
Kimlik doğrulama denemeleri
      ↓
Başarılı giriş veya bağlantı sonlandırma

LoginGraceTime, istemcinin kimlik doğrulamasını tamamlaması için verilen süredir. Süre dolduğunda sshd, bağlantıyı sonlandırma ve olay kaydı üretme yoluna girer. Bu süre mekanizması için SIGALRM sinyali kullanılır. Sinyal, ana akışın tam olarak ne yaptığını bilmeden, işletim sistemi tarafından asenkron biçimde teslim edilebilir.

Normal koşulda bu bir sorun değildir. Sorun, sinyal işleyicisinin çağırdığı fonksiyonların ana programla aynı global duruma veya dahili kilitlere dokunduğu anda başlar. Sinyal bir kritik bölümün ortasında gelirse handler, yarım kalmış bir işlemin üzerine yeniden girebilir.

Async-signal-safe ne demek?

POSIX dünyasında sinyal işleyicisi içinde çağrılmasına izin verilen fonksiyonların sınırlı bir kümesi vardır. Bir fonksiyonun “normal program akışında güvenli” olması, sinyal handler içinde de güvenli olduğu anlamına gelmez.

Linux signal-safety(7) dokümanı bu ayrımı açık biçimde anlatır: non-reentrant fonksiyonlar genellikle sinyal işleyicisi içinde güvenli değildir. Örneğin ana akış printf() benzeri buffered I/O işlemi yaparken sinyal handler aynı iç veri yapılarına tekrar girerse belirsiz sonuç doğabilir. Benzer riskler bellek ayırma, loglama ve kilit kullanan kütüphane yollarında görülür. Linux signal-safety(7)

Basitleştirilmiş bir zihinsel model:

Ana akış: malloc / stdio / syslog / global state
                     │
                     │ SIGALRM tam ortada gelir
                     ▼
Handler: aynı veya bağlı iç duruma yeniden girer
                     │
                     ▼
Race → bozulmuş heap/log state → çökme veya bellek bozulması

Bu şema “her SIGALRM RCE üretir” demek değildir. Yarış koşulu, önce tanımsız veya bozulmuş bir program durumuna yol açar. Saldırganın hedefi, sinyalin zamanlamasını ve bağlantı davranışını tekrar tekrar kontrol ederek bu koşulu güvenilir bir bellek bozulmasına dönüştürmektir. Modern heap düzeni, derleyici, ASLR ve mimari burada belirleyici olur.

Regresyon nasıl oluştu?

regreSSHion adındaki “regression” bölümü tesadüf değil. OpenSSH’de daha eski bir signal-handler hatası, CVE-2006-5051 ile ilişkilendirilen güvenli bir değişiklikle düzeltilmişti. Sonraki yıllarda kod tabanında yapılan bir değişiklik, sinyalin işlediği hata yolunu yeniden async-signal-unsafe çağrılara yaklaştırdı. Böylece geçmişte kapatılmış bir tasarım riski, farklı bir kod akışında tekrar ortaya çıktı.

Buradaki ders yalnızca OpenSSH’ye ait değil: güvenlik düzeltmesi, bir kez merge edildikten sonra sonsuza kadar doğru kalmaz. Refactor, portability değişikliği, loglama düzenlemesi veya hata işleme sadeleştirmesi, güvenlik açısından hassas bir kod yolunu yeniden açabilir. Signal handler, allocator ve pre-authentication kodları için regresyon testleri bu yüzden normal unit testlerden daha değerlidir.

Saldırı yüzeyi nerede başlıyor?

Bu sınıf bir bug için “SSH portu açık mı?” sorusu ilk adımdır, son adım değil. İnceleme şu sınırları kapsamalı:

1. Ağ erişimi: İnternetten 22/TCP veya alternatif SSH portuna ulaşılabiliyor mu?
2. Kimlik doğrulama öncesi akış: LoginGraceTime, bağlantı başına süreç ve rate limit politikası nasıl çalışıyor?
3. Platform: glibc, musl, OpenBSD veya üreticiye özel libc mi kullanılıyor?
4. Mimari ve bellek korumaları: ASLR, PIE, NX, heap hardening ve dağıtım derleme seçenekleri etkin mi?
5. Operasyonel görünürlük: çok sayıda başarısız pre-auth bağlantısı, bağlantı reset’leri ve sshd çökme izleri merkezi kayda gidiyor mu?
6. Yetki sınırı: sshd veya sonrasındaki yönetim oturumu hangi sistem yetkileriyle çalışıyor?

Ağ filtresi, zafiyeti düzeltmez; yalnızca erişebilen saldırgan sayısını azaltır. AllowUsers, AllowGroups, MFA, bastion ve VPN de patch’in yerine geçmez. Bunlar savunma derinliğidir.

Patch doğrulama: “paket güncel” demek yetmez

Düzeltme sonrası yapılması gereken kontrol listesi:

• Üreticinin advisory’sindeki düzeltilmiş paket sürümüyle çalışan sürümü karşılaştırın.
• Paket yöneticisinde güvenlik backport kaydını saklayın.
• sshd -T ile etkin yapılandırmayı, servis dosyasıyla birlikte inceleyin.
• systemctl status ssh veya dağıtım eşdeğeriyle çalışan sürecin yeniden başlatıldığını doğrulayın.
• İmaj tabanlı sistemlerde eski katmanların ve kullanılmayan SSH binary’lerinin silindiğini kontrol edin.
• Kümelerde node, bastion ve yönetim pod’larının tamamını ayrı ayrı tarayın.
• Patch uygulandıktan sonra dış yüzey taraması ve yetkili bir sürüm kontrolü yapın; üretimde exploit denemesi göndermeyin.

Bir sunucu güncellenmiş görünürken eski sshd süreci bellekte çalışıyor olabilir. Kernel canlı patch veya paket güncellemesi sonrası yeniden başlatma gerektiren durumlar için envanterde “patch uygulandı” ve “servis yeniden başlatıldı” alanlarını ayırmak gerekir.

Tespit mühendisliği

regreSSHion gibi pre-auth bir açığın doğrudan “exploit oldu” logu çoğu zaman bulunmaz. Aşağıdaki davranışlar birlikte anlam kazanır:

• Aynı kaynaktan kısa aralıklarla çok sayıda tamamlanmamış SSH bağlantısı,
• LoginGraceTime sınırına yakın tekrar eden bağlantı döngüleri,
• olağan dışı sshd child-process artışı veya servis restart’ları,
• beklenmeyen SIGSEGV, malloc veya heap corruption izleri,
• patch öncesi dönemde yönetim hesabı, authorized_keys veya sudo yapılandırması değişiklikleri,
• aynı hostta SSH erişiminden hemen sonra yeni servis, cron, systemd unit veya outbound bağlantı oluşması.

Bu sinyallerin hiçbiri tek başına CVE-2024-6387 kanıtı değildir. Ancak zafiyetli sürüm, dışa açık SSH ve anormal pre-auth davranışı aynı varlıkta birleşiyorsa olay müdahalesi başlatılmalıdır. Olası istismar şüphesinde yalnızca paketi güncellemek yerine hostu izole edin, süreç ve disk kanıtını koruyun, yönetim anahtarlarını ve sırları döndürün.

LoginGraceTime değerini düşürmek çözüm mü?

Değeri düşürmek saldırganın zaman penceresini daraltabilir; bağlantı başına rate limit ve ağ ACL’leri de yükü azaltabilir. Fakat bunlar vendor patch’inin alternatifi değildir. Yanlış bir değer meşru yavaş istemcileri veya uzak bakım akışlarını bozabilir. Değişiklik, bağlantı kapasitesi ve operasyon ihtiyacıyla birlikte test edilmelidir.

Aynı şekilde MaxStartups ayarı, pre-auth bağlantı sayısını kontrol eder; fakat bellekteki hatalı signal handler’ı ortadan kaldırmaz. Savunma amacı, saldırı maliyetini artırmak ve tespit süresini kısaltmaktır.

Kaynak kodu seviyesinde çıkarım

Bu olay, güvenlik incelemesinde üç kod kokusunu görünür kılıyor:

1. Asenkron callback içinde zengin loglama: Handler, log seviyeleri ve formatlama zinciri içinde allocator veya kilit kullanan fonksiyonlara ulaşmamalı.
2. Global state paylaşımı: Sinyal handler ile normal akış arasında paylaşılan mutable state, açık bir senkronizasyon veya güvenli tasarım olmadan kullanılmamalı.
3. Zamanlama testinin eksikliği: “Normalde çalışıyor” testleri yarış koşullarını yakalamaz. Signal delivery, timeout ve bağlantı kapanışları stres altında test edilmelidir.

Güvenlik kod incelemesinde yalnızca buffer sınırlarına veya parser’lara bakmak eksiktir. Event loop, timer, signal, allocator ve loglama arasındaki kontrol akışı da tehdit modeline dahil edilmelidir.

Sonuç

CVE-2024-6387’nin öğretici tarafı, saldırının tek bir hatalı if satırına indirgenememesi. LoginGraceTime ile çalışan zamanlayıcı, asenkron sinyal teslimi, OpenSSH’nin hata işleme yolu, glibc allocator davranışı ve hedef mimarinin bellek düzeni aynı zincirin parçaları.

Bir SSH varlığını güvenli kabul etmek için üç kanıt gerekir: hangi sürümün çalıştığı biliniyor, vendor düzeltmesi uygulanmış ve dışarıdan erişim ile olay kayıtları kontrol altında. Sürüm numarası tek başına kanıt değildir; ağ filtresi de patch’in yerine geçmez. regreSSHion, açık kaynak bir bileşende geçmişte düzeltilmiş bir güvenlik varsayımının yıllar sonra geri dönebileceğini hatırlatan bir regresyon vakasıdır.

Teknik zaman çizelgesi: bağlantıdan yarışa

Bir SSH bağlantısını tek bir süreç gibi düşünmek, regreSSHion’ın neden zor anlaşılır olduğunu gizler. Portable OpenSSH’nin klasik mimarisinde bağlantı kabul eden ve ayrıcalıklı işlemleri yöneten bir listener ile pre-authentication oturumunu işleyen süreçler arasında ayrım vardır. Sürüm 9.8’de bu mimari daha da ayrıştırıldı; release notes, listener ile sshd-session ayrımını ve tekrar eden pre-auth davranışına karşı PerSourcePenalties gibi yeni kontrolleri ayrıca belgeliyor. Bu, 9.8’in yalnızca CVE yaması değil, saldırı yüzeyini küçültmeye yönelik mimari bir değişiklik de taşıdığını gösterir. OpenSSH 9.8 değişiklikleri

Bir istemcinin bağlantısı için zihinsel akış şu şekilde kurulabilir:

1. Listener TCP accept() yapar
2. Yeni bağlantı için pre-auth çalışma alanı hazırlanır
3. SSH protokol banner ve algoritma görüşmesi başlar
4. LoginGraceTime süresi için SIGALRM kurulur
5. İstemci kullanıcı kimliği ve kimlik doğrulama yöntemini sunar
6. Süre dolarsa alarm handler çalışır
7. Handler bağlantıyı sonlandırır ve olay kaydı üretir
8. Başarılı auth veya timeout sonrası süreç temizlenir

Yarışın kritik noktası 6. adımdır. SIGALRM, ana akışın “uygun” bir satırda olduğunu beklemez. Alarm; heap ayrıştırma, log formatlama, bağlantı temizleme veya başka bir global state güncellemesi sırasında gelebilir. Handler’ın bu durumlarda kullandığı yol yalnızca async-signal-safe işlevlerle sınırlı değilse, ana akışın yarım bıraktığı iç veri yapısına yeniden giriş olasılığı doğar.

Bu yüzden hata “timeout değeri yanlış” değildir. Asıl kusur, timeout sinyalinin hangi kod yoluna, hangi süreç durumunda ve hangi kütüphane çağrılarının ortasında teslim edilebildiğidir.

Heap ve glibc tarafı: neden teorik bir çökme ile bitmiyor?

Sinyal handler’ın malloc, free, syslog veya stdio ailesine dolaylı olarak girmesi iki ayrı risk üretir. Birincisi, programın çökmesi veya bağlantının kapanmasıdır. İkincisi, allocator’ın global durumunun beklenmeyen bir ara görünümde ele alınmasıdır.

glibc allocator, performans için thread ve arena durumlarını, serbest blok listelerini ve metadata’yı yönetir. Ana akış bir allocation veya free işlemi sırasında kesildiğinde, handler aynı duruma yeniden girerse iki akış aynı invariants’ı aynı anda korumaya çalışır. Bu, “handler her zaman heap bozar” demek değildir; yalnızca güvenli olmayan bir çağrının neden tanımsız davranış riski taşıdığını açıklar.

Qualys’in analizinde zafiyetin teknik zorluğu; zamanlama yarışını yeterli sayıda tekrarla tetiklemek, belleğin beklenen düzenini elde etmek ve ASLR gibi korumaları aşacak koşulları bir arada tutmakla ilişkilendiriliyor. OpenSSH’nin resmi notları, 32-bit Linux/glibc üzerinde laboratuvar koşullarında ortalama 6–8 saatlik sürekli bağlantı gerektiren bir gösterimden söz ediyor; 64-bit istismar olasılığı o tarihte kanıtlanmış değildi. Bu nedenle uzaktan RCE mümkün ile her açık SSH sunucusu birkaç dakikada ele geçirilebilir cümleleri aynı şey değildir. Qualys teknik değerlendirmesi

Bu teknik zorluk savunma önceliğini düşürmez. Aksine, düşük frekanslı ve uzun süreli denemeler klasik “yüksek trafik” alarmının altında kalabilir. Tespit mantığı bağlantı sayısından çok bağlantı sürekliliğini, timeout’a yakın tekrarları ve servis davranışını izlemelidir.

Exposure matrix: varlıkları aynı kefeye koymamak

Her SSH sunucusuna aynı risk puanını vermek, patch sırasını bozar. Aşağıdaki katmanlar varlık envanterinde ayrı tutulmalı:

• İnternete açık bastion: Pre-auth erişim herkes için mümkün olabilir; en yüksek öncelik.
• VPN arkasındaki yönetim hostu: VPN hesabı ele geçirilirse veya iç ağdan erişim mümkünse risk devam eder.
• Kubernetes node ve CI runner: SSH doğrudan dışa açık olmasa bile yüksek yetkili iş yüklerinin yan kapısı olabilir.
• Yedekleme ve depolama sunucusu: Root seviyesinde erişim, yedeklerin silinmesi veya şifrelenmesiyle birleşebilir.
• OT/ICS jump host: Zafiyet, doğrudan PLC’ye değil önce yönetim segmentine giriş sağlar; fakat yatay hareket etkisi daha yüksektir.
• Geliştirici laptop’ı: Üretim anahtarları, source repository erişimi ve cloud credential’ları nedeniyle kritik olabilir.

Varlık kaydında şu alanları tutun: dış IP, SSH portu, servis sahibi, paket yöneticisi, upstream sürüm, distro revision, libc, mimari, son patch tarihi, son servis restart zamanı, MFA/bastion durumu ve erişim ACL’si.

LoginGraceTime 0: son çare, tam çözüm değil

Qualys, patch uygulanamayan sistemler için LoginGraceTime 0 ayarını geçici bir RCE azaltımı olarak açıklıyor. Zamanlayıcı yolu devre dışı kaldığı için sinyal yarışının tetiklenme koşulu azalır; ancak bu ayar MaxStartups bağlantı kapasitesini doldurarak denial-of-service riskini artırabilir. Qualys mitigasyon notu

Bu nedenle değişiklik şu koşullarla uygulanmalı:

1. Yalnızca bakım penceresi bekleyemeyen, geçici olarak izole edilmiş sistemlerde kullan.
2. MaxStartups, firewall connection limit ve bastion ACL’lerini birlikte gözden geçir.
3. Meşru yavaş istemciler, otomasyon ve dosya aktarımı için işlev testi yap.
4. Değişikliğe bir son tarih koy; “geçici” config kalıcı unutulmasın.
5. Vendor patch’i geldiğinde ayarı eski haline getirip normal login grace davranışını doğrula.

LoginGraceTime değerini düşürmek veya portu değiştirmek de benzer şekilde yalnızca saldırı maliyetini etkiler. Hiçbiri vulnerable binary’nin yerine geçen bir düzeltme değildir.

Güvenli doğrulama komutları

Üretim sisteminde exploit denemek yerine, paket ve çalışan süreç doğrulanabilir. Dağıtıma göre komutlar değişir; aşağıdaki örnekler yalnızca envanter içindir:

# Debian/Ubuntu: paket ve aday sürümü karşılaştır
apt-cache policy openssh-server
dpkg-query -W -f='${Package} ${Version}\n' openssh-server

# RHEL/Fedora: paket ve changelog içinde CVE kaydı ara
rpm -q openssh-server
rpm -q --changelog openssh-server | grep -i 'CVE-2024-6387\|regreSSHion'

# Etkin daemon ayarlarını ve çalışan binary'yi kontrol et
sshd -T | grep -E 'logingracetime|maxstartups'
systemctl show sshd -p MainPID,ExecMainStartTimestamp
readlink -f /proc/$(pgrep -xo sshd)/exe

Bu komutların çıktısı tek başına “güvenli” kararı vermez. Distro advisory’si, backport commit’i ve çalışan süreç başlangıç zamanı birlikte saklanmalıdır. Özellikle sshd -V veya istemci tarafında ssh -V sunucu paketinin patch seviyesini göstermeyebilir.

Detection engineering: hangi olayı yakalamalı?

Qualys’in yayımladığı pratik sinyallerden biri, loglarda tekrar eden “Timeout before authentication” satırlarının görülmesi. Bu kayıt tek başına exploit kanıtı değildir; bot taraması, yanlış yapılandırılmış bir sağlık kontrolü veya yavaş istemci de aynı satırı üretebilir. Fakat pencere, kaynak ve servis durumu ile birleştirildiğinde güçlü bir önceliklendirme girdisidir.

Örnek bir korelasyon mantığı:

IF host.version IN affected_range
AND host.ssh_exposed == true
AND count(preauth_timeout, same_source, 15m) > baseline
AND (sshd_restart OR segfault OR unexpected_child_exit)
THEN create HIGH incident

İkinci sinyal kümesi, patch sonrası geriye dönük incelemedir:

• authorized_keys dosyasında beklenmeyen ekleme,
• sudoers veya systemd unit değişikliği,
• yeni outbound bağlantı ve indirme,
• root shell açılışının ardından credential veya config okuma,
• sshd log seviyesinin veya audit kurallarının değiştirilmesi.

Bu olaylar CVE’ye özel değildir. Ancak zafiyetli sürüm, dışa açık SSH ve patch öncesi zaman aralığıyla kesişiyorsa “normal yönetim” varsayımı kaldırılmalıdır.

Patch sonrası doğrulama testi

Patch’in uygulandığını kanıtlayan bir test planı dört aşamalı olmalı:

1. Statik doğrulama

Vulnerable upstream range dışında bir paket veya vendor backport’u olduğunu gösteren kayıt alın. Container image, golden image ve çalışan host ayrı raporlansın.

2. Servis doğrulama

Daemon yeniden başlatıldı mı? Eski listener veya socket activation süreci hâlâ çalışıyor mu? MainPID, binary path ve başlangıç zamanı değişiklik kaydına yazılmalı.

3. Dış yüzey doğrulama

Yetkili dış tarama, SSH banner ve erişim ACL’lerinin beklenen durumda olduğunu kontrol eder. Banner tek başına kesin kanıt değildir; authenticated asset inventory ile eşleştirilmelidir.

4. Davranış doğrulama

Normal kullanıcı girişi, MFA, port forwarding politikası, SFTP ve otomasyon job’ları test edilir. Amaç exploit’i tekrar üretmek değil, güvenlik düzeltmesinin işletimi bozmadığını ve olay kaydının çalıştığını göstermektir.

Bulguyu nasıl raporlamalı?

Finding: CVE-2024-6387 exposure on internet-facing sshd
Asset: bastion-03 / Ubuntu package revision …
Evidence: affected package + external reachability + service start time
Impact: pre-authentication RCE risk; privilege boundary is root
Confidence: confirmed by vendor advisory and authenticated package check
Immediate action: restrict SSH, apply vendor fix, review pre-patch logs
Validation: package revision, running PID, external scan, auth regression test

Bu format “sürüm eski” bulgusunu gerçek işletme bağlamına taşır. Etki, varlık rolü ve kanıt seviyesi yazılmadan CVE listesi operasyon ekibine yol göstermez.

Sık sorulan sorular

CVE-2024-6387 yalnızca internete açık sunucular için mi önemli?

Hayır. İnternete açık servisler en yüksek önceliktedir; ancak aynı SSH bileşeni iç ağda, VPN arkasında, CI/CD runner’da veya yönetim segmentinde de çalışıyor olabilir. İç ağ güvenilir kabul edilmemelidir.

OpenSSH sürümüm 8.x, kesin olarak savunmasız mıyım?

Upstream sürüm ile dağıtım paketini ayırın. Güvenlik backport’u uygulanmış olabilir. Dağıtım advisory’si ve paket revizyonu ile doğrulayın.

Exploit kodu yayınlanmadıysa patch bekleyebilir mi?

Hayır. Açıklanmış bir pre-auth yarış, tersine mühendislik ve farklı araştırma ekiplerinin yeniden üretimi için yeterli malzeme bırakır. Açık yüzeyi azaltın, patch’i uygulayın ve logları geriye dönük inceleyin.

Kaynaklar

• OpenSSH 9.8 Release Notes
• Qualys: regreSSHion – Remote Unauthenticated Code Execution in OpenSSH
• NVD: CVE-2024-6387
• Linux man-pages: signal-safety(7)