NGINX Rift - Yeni bir NGINX exploit'i

• NGINX Rift, NGINX ngx_http_rewrite_module içindeki kritik heap buffer overflow açığı CVE-2026-42945 için bir uzaktan kod çalıştırma PoC'udur
• Bu zafiyet, rewrite ve set yönergelerini kullanan sunucularda kimlik doğrulaması olmadan uzaktan kod çalıştırmayı mümkün kılar
• Sorun, 2008'de eklenen bir bug'dan kaynaklanıyor; NGINX betik motorunun uzunluk hesaplama geçişi ile kopyalama geçişi is_args bayrağını farklı şekilde ele alıyor
• rewrite ikame dizgesinde ? bulunduğunda ana motorda is_args ayarlanır, ancak uzunluk hesabı yeniden 0'a sıfırlanmış alt motorda çalıştığı için yalnızca özgün capture uzunluğunu döndürür
• Kopyalama aşamasında is_args = 1 durumunda ngx_escape_uri ve NGX_ESCAPE_ARGS çağrılır; bu da escape edilebilir her baytın 3 bayta genişlemesine ve yetersiz ayrılmış heap buffer'ın saldırgan kontrollü URI verisiyle taşmasına yol açar
• Exploit, istekler arasında heap feng shui kullanarak bitişik ngx_pool_t içindeki cleanup işaretçisini bozar; URI baytlarına null byte eklenemediği için spray işlemi POST gövdesi üzerinden yapılır
• Bozulmuş işaretçi sahte bir ngx_pool_cleanup_s yapısına yeniden yönlendirilir ve pool yok edilirken system() çağıracak şekilde düzenlenir
• CVE-2026-42945'e ek olarak, CVE-2026-42946, CVE-2026-40701 ve CVE-2026-42934 numaralı 3 bellek bozulması sorunu da depthfirst'ün güvenlik analiz sistemi tarafından NGINX kaynak kodunun tek seferlik onboarding'iyle otonom biçimde keşfedildi
• Etkilenen sürümler NGINX Open Source 0.6.27–1.30.0 ve NGINX Plus R32–R36; düzeltilmiş sürümler ise Open Source 1.31.0/1.30.1 ve Plus R36 P4/R35 P2/R32 P6 olarak belirtiliyor
• Tam üretici uyarısı https://my.f5.com/manage/s/article/K000160932 adresinde, teknik ayrıntılar ise technical write-up içinde yer alıyor
• PoC, Ubuntu 24.04.3 LTS üzerinde test edildi; akış olarak ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell sırasıyla zafiyetli NGINX container'ını ayağa kaldırıp shell çalıştırmayı sunuyor

[GN⁺]

Hacker News görüşleri

• Bir güvenlik sorumlusu olarak, yayımlanan exploit’in ASLR bypass yapmıyor olması nedeniyle bu sorunun çok daha az korkutucu olduğuna kesin hükmeden ya da bunu ima eden tepkilerin fazlalığı gerçekten yorucu
  Orijinal metin, bu saldırıyla ASLR’ı güvenilir biçimde aşmanın bir yolu olduğunu öne sürüyor; ortada kanıt olmasa bile bunu varsayılan kabul olarak benimsemek makul
  ASLR, exploit’i zorlaştıran bir defense in depth tekniğinden ibaret; çoğu durumda yeterli zaman ve beceriyle ASLR bypass da ekleniyor
  LLM ajanları yüzünden bu zaman ve beceri eşiği de birkaç haftada bir düşüyor; tamamen silahlandırılmış bir exploit’in çıkması an meselesi, kamuya açık da olabilir kapalı da kalabilir
  “ASLR açıksa tehlikeli değildir” demek açıkça yanlış ve buna inananlar için oldukça zararlı
  Azaltım teknikleri exploit’i zorlaştırabilir diye güvenlik açıklarını önemsememek gerektiğine dair yanlış inanç geçmişte zaten çok zarar verdi
  Modern azaltım tekniklerinin varlığı sevindirici ama mümkün olan en kısa sürede yamalanmalı; satıcı tarafındaysanız da araştırmacı ASLR bypass göstermedi diye güvenlik açığı raporunu geçersiz saymayın, kök nedeni düzeltin

  • Uzaktan erişilebilen açıklar hafife alınmamalı
    Ama şu an için önkoşullar biraz sıra dışı görünüyor
    10 yıldır nginx’i farklı yapılandırmalarla kullanıyorum ama rewrite ile set komutlarını birlikte bir kez bile kullanmadım
  • “AI siber güvenliği çözecek” diyenlerle “ASLR açıksa sorun yok” diyenlerin 1:1 örtüştüğünü söylemek çok da yanlış olmaz
    Ve mutlaka “cyber” diyorlar
  • Bu bakış açısına katılmıyorum ya da en azından farklı ifade etmek isterim
    ASLR, tahmin edilmesi gereken ek bir parola gibi; belli bir entropi taşıyor ve genelde istikrarlı
    Açıkta bilgi sızıntısı kısmı yoksa ASLR bu açığı tamamen etkisiz hale getirebilir ya da ikinci bir açık gerektirir
    Bu da başka bir tartışma
    ASLR, tekil açıkları tamamen etkisiz hale getirebilir ama exploit chain’i engelleyemez
    Yine de hızlı yama ihtiyacını anlatmak için bilgi sızıntısı yaratan ikinci bir açığın olasılığını gerekçe göstermek daha iyi olabilir
    Exploit chain her tür güvenlik açığında tehlikelidir
  • İnternette yanlış bilginin yayılmasını engellemek zor; çoğu kişi de hatalı olduğunu bilmiyor
    Asıl zararlı olan şey, kendinden emin rastgele internet yorumlarını olduğu gibi doğru kabul etmek
    Bunu ayırt etme becerisi geliştirirse insan, sadece güvenlikte değil başka alanlarda da işine yarar
  • Açık internete maruz yazılımlarda bir remote code execution raporu okursam genelde birkaç dakika içinde yükseltme yaparım
    Zaten bu yüzden bu tür raporları okuyorum ve ciddiye almak gerekiyor
    Aksi halde makine yakında ele geçirilir
    Son dönemde kamuya açıklanan remote code execution exploit’lerinde önceden bildirim yapılmaması daha sık görülüyor; en azından yazılımı yükseltmek için birkaç dakika verilse iyi olurdu
    Bu durum, uzaktan exploit edilebilen sendmail hatalarının yağdığı 1980’lerin sonu ile 1990’ların başındaki, açıklama süreçlerinde güvenlik tedbiri olmayan dönemi hatırlatıyor
    Bu raporları okumazsanız ya da çok geç okursanız milyonlarca cihaz tehlikeye girebilir
    nginx şu anda halka açık web sunucusu pazarının yaklaşık %39–43’ünü oluşturuyor, yani oldukça ciddi

• Bu olay epey kötü ama bazı önkoşulları var
  Yerine koyma dizgesinde soru işareti bulunan bir rewrite yönergesi gerekiyor ve ardından regex capture group’a başvuran bir set yönergesi gelmeli
  Örnek: set $var $1
  Ayrıca PoC, ASLR’nin devre dışı olduğunu varsayıyor

  • Örnek: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • Varsayılan olarak ASLR’yi kapatan bir dağıtım var mı?
    Elle kapatılsa bile nginx bunu yapacak doğal adaylardan biri gibi gelmiyor
  • Artık rewrite pek kullanılmıyor değil mi?
    Sanki PHP ve Apache’nin eski zamanlarından kalma gibi

• Resmî F5 sayfası burada: https://my.f5.com/manage/s/article/K000161019
  Başka yerlerde de yazıldığı gibi ASLR koruma sağlıyor
  Etkilenen platformların düzeltilmiş sürümleri beklenirken, geçici azaltım olarak “rewrite tanımlarında isimsiz capture yerine isimli capture kullanın” deniyor
  “Bu örnekte açığı azaltmak için $1 ve $2 yerine uygun isimli capture’lar olan $user_id ve $section kullanın” deniyor
  F5, 1.31.0 ve 1.30.1 sürümlerini yamaladı
  OpenResty için 1.27 ve 1.29 yamaları burada: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  Nginx tabanlı Lua uygulama sunucusu OpenResty’nin durumu burada izlenebilir: https://github.com/openresty/openresty/issues/1119

• PoC, ASLR’yi devre dışı bırakıyor: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Worker process’ler master’dan fork edildiği için aynı memory layout’u alıyor
    Worker’lar üzerinde sınırsız sayıda crash üretilebilir
    Bununla bir read oracle oluşturmanın bir yolu olması muhtemel
    En azından güvenilir bir service denial mümkün
    Depth First’ün tam analizi: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• Apache ve Nginx’e iyi bir alternatif olarak, memory-safe language ile yazılmış ve çok fazla güvenlik açığı geçmişi olmayan bir şey var mı?
  Java ile yazılmış Jetty ve Go ile yazılmış Caddy’ye kısaca baktım ama Jetty’nin shell injection gibi başka tür açık geçmişi de olduğundan daha iyi olup olmadığından emin değilim

  • Bellek güvenliği güzel ama her tehdidi durdurmuyor
    Günümüzde altyapı yönetenlerin aktif savunma olan MAC’e, yani SELinux ve AppArmor’a alışması gerekiyor
    Eskiden sürtünmesi yüksekti ama artık kullanımı kolaylaştıran daha fazla araç var
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Not olarak, iki depo da bana ait
  • Apache ve nginx ölçeğinde kullanılan yazılımlarda açık geçmişi olmaması zaten beklenmez
    İkisinin de bu kadar uzun süre pazar payını korumuş olması aslında iyi bir işaret
  • Caddy’yi kullanmak gerçekten çok rahattı
    Ama düzgün bir eklenti sistemi yerine, istenen eklenti kombinasyonuna göre binlerce ikili dosya üreten model pek hoşuma gitmiyor
    Yine de kaynaktan derlenecekse oldukça temiz ve basit
  • Apache ve muhtemelen Nginx de inanılmaz derecede fazla özellik ve bileşene sahip
    Alternatif HTTP sunucularının çoğu kapsamı ciddi biçimde daraltıyor; bu yüzden önce hangi özelliklere ihtiyaç olduğunu belirlemek gerekiyor
    Memory-safe language ile yazılmış HTTP sunucularına dair çok tartışma görmedim
    C tabanlı üç büyük sunucu olan Apache, Nginx ve lighttpd’nin hepsi oldukça sağlam; sırf dil nedeniyle yeni bir projeye geçmek isteyen çok kişi de yok gibi
    Ayrıca çoğu memory-safe language seçildiğinde, o dilin bazen oldukça büyük runtime’ı, sanal makinesi ve yan bileşenleri de beraberinde geliyor
    Java web sunucusuysa, rastgele Java projelerinde sık görüldüğü gibi log4j kullanma ihtimali var
  • Load balancer amacıyla HAProxy gayet iyi iş çıkarıyor

• “Exploit, istekler arası heap feng shui kullanıyor” denmiş; feng shui ifadesinin böyle kullanıldığını ilk kez görüyorum

• Debian 12’de bu yamalandı mı?
  Yine de hiçbir yerde rewrite ya da set kullanmıyorsam etkilenmiyorum diye düşünebilir miyim?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • Ubuntu bugün sabah itibarıyla yamalanmıştı
    Debian ise henüz trixie için yama yayımlamış gibi görünmüyor
  • nginx kullanırken en azından set bile kullanmamak çok nadirdir diye düşünüyorum
    Çoğu nginx kullanımında TLS sonlandırılıp istek node/php/go gibi arka uçlara aktarılıyor
    Bu yüzden proxy_set_header X-Host $host; gibi satırlarda saldırgan kontrollü veri içeren bir set bir yerlerde mutlaka vardır diye düşünmüştüm
    Düzeltme: isimli capture’lar etkilenmiyor gibi görünüyor
    Herhangi bir yerde $1 yoksa muhtemelen sorun yoktur

• Daha iyi bağlantılar:
  https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
  https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)