ssh-keysign-pwn - Linux 0-day ile ayrıcalıksız kullanıcının root sahipli dosyaları okumasını gösteren PoC

• ssh-keysign-pwn, ayrıcalıksız bir kullanıcının root sahipli dosyaları okuyabilmesini sağlayan bir Linux zafiyeti PoC’si; hedefin 31e62c2ebbfd öncesi çekirdekler olduğu belirtiliyor
• Temel hata, __ptrace_may_access() fonksiyonunun task->mm == NULL olduğunda dumpable kontrolünü atlaması ve do_exit() içinde exit_mm()’in exit_files()’dan önce çalışması nedeniyle dosya tanımlayıcıları açık kalırken bir pencere oluşması
• Bu pencerede çağıranın uid’si hedef süreçle eşleşirse pidfd_getfd(2) başarılı oluyor ve kapanmakta olan sürecin açık dosya tanımlayıcıları alınabiliyor
• sshkeysign_pwn, /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key dosyalarını alıyor; bunun için ssh-keysign.c’nin 0600 izinli anahtarları açtıktan sonra permanently_set_uid() çağrısından önce EnableSSHKeysign=no nedeniyle çıkıp açık fd bırakması akışından yararlanıyor
• chage_pwn, /etc/shadow dosyasını alıyor; chage -l <user> akışında spw_open(O_RDONLY) sonrasında setreuid(ruid, ruid) ile yetkilerin tamamen bırakıldığı noktadaki çıkış yarışını hedefliyor
• Çalıştırma şekli, make sonrasında ana makine anahtarları için ./sshkeysign_pwn, /etc/shadow içeriğini standart çıktıya yazdırmak için ./chage_pwn root; bunun 100 ila 2000 süreç oluşturma denemesi içinde isabet ettiği belirtiliyor
• Doğrulanan ortamlar Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch ve CentOS 9
• Kontrollü hedef PoC olarak vuln_target.c, /etc/shadow dosyasını açtıktan sonra yetkileri bırakıyor; exploit_vuln_target.c ise süreç hayattayken EPERM alındığını ve SIGKILL sonrasında fd ele geçirmenin mümkün olduğunu gösteriyor
• Zafiyetin Qualys tarafından bildirildiği, Linus’un 2026-05-14 tarihinde düzeltmeyi yaptığı ve Jann Horn’un 2020 Ekim’de FD ele geçirme biçimine dikkat çektiği belirtiliyor
• README, NVD girdisi olarak https://nvd.nist.gov/vuln/detail/CVE-2026-46333 bağlantısını veriyor

[GN⁺]

Lobste.rs görüşleri

• Yalnızca ptrace’i devre dışı bırakmak yeterli değil. Commit mesajı ve fonksiyon adı yüzünden yanlış anlamak kolay, ancak ptrace_may_access birçok yoldan çağrılıyor ve bu kavram kanıtı (PoC) da aslında ptrace kullanmıyor
  Uygun bir hafifletme pek yok; şimdilik ya 1) yalnızca bu belirli PoC’ye zayıf bir karşılık vermek için /usr/lib64/misc/ssh-keysign dosyasından tüm çalıştırma bitlerini kaldırmak, ya da 2) eBPF veya systemtap gibi bir şeyle pidfd_getfd engellemesi yapmak mümkün görünüyor. İlki, kernel patch’leyemiyor ya da sistemi kapatamıyor ve hemen uyumanız gerekiyorsa ancak o seviyede düşünülebilir
  PoC’yi incelemedim; internette bulunan rastgele PoC’leri çalıştırırken her zamanki gibi dikkatli olmak gerekiyor
  Qualys danışma metni henüz yayımlanmadı ve Linux kernel güvenlik politikası nedeniyle linux-distros dağıtımını büyük bir üzüntüyle durduracağını söylemişti. LLM’lerin şüpheli görünen düzeltme commit’lerinden hızla PoC üretebilmesiyle durum sertleşti; eskiden olsa birkaç gün beklemek mümkün olabilirdi
  Qualys gerçekten harika bir ekip, ama bu olayı bizzat duyurmak için uygun bir an yakalayamamış olmaları üzücü. Yayımlandığında kesinlikle harika bir danışma metni olacaktır
  openssh bu saldırı için sadece elverişli bir hedef; suç onda değil ve başka setuid binary’ler de hedef olarak seçilebilirdi

  • Qualys güncellemesine göre /proc/sys/kernel/yama/ptrace_scope değerini 2 (yalnızca admin attach) ya da 3 (attach yok) yapmak bilinen tüm exploit’leri engelliyor. Yine de teorik olarak başka istismar yolları olabilir
  • Hızlı bir hafifletme olarak LLM Opus’a pidfd_getfd engelleyen bir systemtap betiği yazdırdım; sonuç burada. stap -g block_pidfd_getfd.stp ile çalıştırılmalı ve internette bulunan her şeyde olduğu gibi çalıştırmadan önce betiği mutlaka gözden geçirmek gerekir
  • linux-distros duyurusunun bağlantısı var mı? Bulamıyorum

• Kernel’in ana dala düzeltmeleri herkese açık commit’lerle gönderip fiilen kendi kendine 0-day yayımlaması sona ermeli. Commit’te hatta “Reported-by: Qualys” yazıyor; yani bunun bir güvenlik düzeltmesi olduğu açık

  • Geçen hafta bu konuda büyük bir tartışma vardı
    Greg K-H, kernel güvenlik ekibinin güvenlik düzeltmelerinin önceden açıklanacağı tarafları seçemediğini, dolayısıyla sonuçta hiç kimsenin önceden bilgilendirilmediğini yazmıştı
  • Peki onun yerine ne yapılmalı?

• Bu bir ssh sorunu değil, Linux sorunu. Başlık da bunu yansıtmalı

  • Başlığın yanlış izlenim verdiğine katılıyorum, ama nasıl adlandırılması gerektiğine dair başka bir fikrim yoktu. Hâlâ düzenlenebiliyor, bu yüzden öneri olursa iyi olur
  • Doğru, ama aynı zamanda ssh-keysign, özel host anahtarını açmadan önce önce EnableSSHKeysign=yes durumunu kontrol etmiş olsaydı, varsayılan olarak bu seçenek kapalı olan sistemler host anahtarı sızdırılmasına karşı savunmasız olmazdı. ssh-keysign’ın ilk iş olarak bu seçeneği kontrol etmemesi şaşırtıcı

• Kavram kanıtı memnun edici derecede kısa ve benim makinelerim de gerçekten savunmasızdı
  Belirli koşullarda setuid ile çalışan bir yürütülebilirin açtığı dosya tanımlayıcısına erişim sağlıyor gibi görünüyor. Bunun yalnızca okumayla sınırlı olması için bir neden göremiyorum; hash kırmaya gerek bırakmayan bir yerel ayrıcalık yükseltme (LPE) yoluna çevrilebilecek gibi duruyor
  En azından bu PoC, chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage ile bozulabiliyor. ssh-keysign yolunu değiştirmeniz gerekebilir; man sayfasına da bakabilirsiniz. Ama bu asıl sorunu çözmüyor ve muhtemelen etrafından dolaşılabilir. Bildiğim kadarıyla başka hafifletme yok
  Bu sorun ptrace: slightly saner 'get_dumpable()' logic içinde düzeltildi ve bu yüzden de açığa çıkmış oldu. Daha yalnızca 10 saat önce
  Qualys’in oss-security’ye gönderdiği kamusal duyuru da var. Dağıtımlara ve kullanıcılara patch uygulamak için zaman tanımak amacıyla danışma metnini henüz yayımlamadıklarını söylüyorlar. Oldukça ilginç bir metin olacak gibi; o zamana kadar grsecurity’den Brad Spengler’ın açıklamasına bakılabilir. Görünüşe göre bu tweet bu PoC’nin geliştirilmesini tetikledi

  • PoC’yi çalıştırmayı denedim ama yarış durumunu kazanamadım. Bunun yerine exploit_vuln_target/vuln_target çifti iyi çalıştı. Pek iç açıcı değil

• Gerçekçi olarak bu, zaten ayrıcalıksız bir hesaba sahip kullanıcıların bulunduğu sistemleri etkiliyor gibi görünüyor. Yani geçerli bir oturum açma yoksa, SSH internete açık bir sunucuda bununla doğrudan uzaktan kod çalıştırmaya yol açamıyor, doğru mu?

  • Doğru. Ancak birkaç gün önce paylaşılan nginx uzaktan kod çalıştırma örneğinde olduğu gibi başka bir servis üzerinden RCE elde edilebiliyorsa durum farklıdır