NGINX Rift - Eksploit NGINX Baru

• NGINX Rift adalah PoC eksekusi kode jarak jauh untuk CVE-2026-42945, sebuah heap buffer overflow kritis di ngx_http_rewrite_module milik NGINX
• Kerentanan ini memungkinkan eksekusi kode jarak jauh tanpa autentikasi pada server yang menggunakan direktif rewrite dan set
• Masalah ini berasal dari bug yang diperkenalkan pada 2008, terjadi karena length calculation pass dan copy pass pada mesin skrip NGINX menangani flag is_args secara berbeda
• Jika string substitusi rewrite berisi ?, is_args disetel pada mesin utama, tetapi perhitungan panjang dijalankan pada sub-engine yang baru diinisialisasi ke 0 sehingga hanya mengembalikan panjang capture asli
• Pada tahap penyalinan, ngx_escape_uri dan NGX_ESCAPE_ARGS dipanggil dengan status is_args = 1, sehingga setiap byte yang bisa di-escape diperluas menjadi 3 byte dan membuat heap buffer yang dialokasikan terlalu kecil meluap dengan data URI yang dikendalikan penyerang
• Eksploit ini menggunakan heap feng shui antar-request untuk merusak pointer cleanup pada ngx_pool_t yang bersebelahan, dan karena null byte tidak bisa dimasukkan ke dalam byte URI, spray dilakukan melalui body POST
• Pointer yang sudah dirusak diarahkan ulang ke ngx_pool_cleanup_s palsu dan dikonfigurasi untuk memanggil system() saat pool dihancurkan
• Bersama CVE-2026-42945, tiga isu korupsi memori lain yakni CVE-2026-42946, CVE-2026-40701, dan CVE-2026-42934 juga ditemukan secara otonom hanya dari satu kali onboarding source code NGINX oleh sistem analisis keamanan dari depthfirst
• Versi yang terdampak adalah NGINX Open Source 0.6.27–1.30.0 dan NGINX Plus R32–R36, sedangkan versi perbaikannya adalah Open Source 1.31.0/1.30.1 dan Plus R36 P4/R35 P2/R32 P6
• Peringatan vendor lengkap tersedia di https://my.f5.com/manage/s/article/K000160932, dan detail teknis dibahas dalam technical write-up
• PoC diuji di Ubuntu 24.04.3 LTS, dan menyediakan alur untuk menjalankan container NGINX yang rentan serta membuka shell dengan urutan ./setup.sh, docker compose -f env/docker-compose.yml up, lalu python3 poc.py --shell

[GN⁺]

Komentar Hacker News

• Sebagai orang keamanan, melelahkan melihat terlalu banyak reaksi yang menyimpulkan atau menyiratkan bahwa masalah ini jauh kurang menakutkan hanya karena eksploit yang dipublikasikan tidak melakukan bypass ASLR
  Teks aslinya mengklaim ada cara untuk membypass ASLR secara andal dengan serangan ini, dan menurut saya itu layak dipercaya sebagai asumsi dasar bahkan tanpa bukti
  ASLR hanyalah teknik defense in depth yang membuat eksploitasi lebih sulit, dan dalam kebanyakan kasus, dengan waktu dan kemampuan yang cukup, bypass ASLR pada akhirnya akan muncul
  Karena agen LLM, hambatan waktu dan kemampuan itu juga terus menurun tiap beberapa minggu, jadi eksploit yang benar-benar dipersenjatai sepenuhnya tinggal soal waktu, entah akan dipublikasikan atau tetap tertutup
  Pernyataan “kalau ASLR diaktifkan berarti tidak berbahaya” jelas salah, dan sangat merugikan bagi orang yang mempercayainya
  Keyakinan keliru bahwa kerentanan keamanan tidak perlu dipedulikan karena teknik mitigasi bisa membuat eksploitasi lebih sulit sudah banyak menimbulkan kerusakan di masa lalu
  Syukurlah mitigasi modern ada, tetapi patch tetap harus diterapkan secepat mungkin, dan jika Anda vendor, jangan perlakukan laporan kerentanan sebagai tidak valid hanya karena penelitinya tidak menunjukkan bypass ASLR; perbaiki akar masalahnya

  • Kerentanan yang bisa diakses dari jarak jauh tidak boleh dianggap enteng
    Hanya saja, untuk saat ini prasyaratnya memang tampak agak tidak biasa
    Selama 10 tahun memakai nginx dalam berbagai konfigurasi, saya belum pernah sekali pun menggunakan rewrite dan set secara bersamaan
  • Aman untuk menganggap orang-orang yang berkata “AI akan menyelesaikan cyber” dan orang-orang yang berkata “kalau ASLR aktif aman-aman saja” itu bertumpang tindih 1:1
    Dan mereka pasti bilang “cyber”
  • Saya tidak setuju dengan sudut pandang ini, atau setidaknya ingin mengungkapkannya secara berbeda
    ASLR itu seperti kata sandi tambahan yang harus ditebak, memiliki entropi tertentu, dan biasanya cukup stabil
    Jika kerentanannya tidak punya bagian kebocoran informasi, ASLR bisa sepenuhnya memitigasi kerentanan itu, atau kalau tidak berarti dibutuhkan kerentanan kedua
    Itu pembahasan yang berbeda
    ASLR bisa sepenuhnya memitigasi kerentanan individual, tetapi tidak bisa menghentikan rangkaian eksploit secara keseluruhan
    Meski begitu, untuk meyakinkan orang agar cepat melakukan patch, menurut saya lebih baik memakai kemungkinan adanya kerentanan kedua yang menciptakan kebocoran informasi sebagai argumen
    Rangkaian eksploit memang berbahaya untuk semua jenis kerentanan
  • Sulit mencegah misinformasi menyebar di internet, dan kebanyakan orang bahkan tidak sadar bahwa mereka salah
    Yang benar-benar berbahaya adalah mempercayai begitu saja komentar internet acak yang disampaikan dengan penuh keyakinan
    Jika bisa mengasah kemampuan untuk menembus itu, itu akan berguna bukan hanya di keamanan tetapi juga di bidang lain
  • Kalau saya membaca laporan remote code execution pada perangkat lunak yang terekspos ke internet publik, biasanya saya upgrade dalam hitungan menit
    Itulah alasan saya membaca laporan seperti ini, dan itu harus ditanggapi serius
    Kalau tidak, mesin Anda akan dibobol dalam waktu dekat
    Belakangan ini tampaknya banyak eksploit remote code execution yang dipublikasikan tanpa pemberitahuan sebelumnya, dan saya berharap setidaknya diberi beberapa menit untuk sempat meng-upgrade perangkat lunaknya
    Rasanya seperti akhir 1980-an hingga awal 1990-an ketika bug sendmail yang bisa dieksploitasi dari jarak jauh bermunculan dan belum ada pagar pengaman dalam publikasi
    Kalau Anda tidak membaca laporan seperti ini atau membacanya terlalu terlambat, jutaan mesin bisa terdampak kompromi
    Saat ini nginx menguasai sekitar 39~43% pasar web server publik, jadi ini cukup serius

• Kasus kali ini cukup buruk, tetapi memang ada prasyaratnya
  Dibutuhkan direktif rewrite dengan tanda tanya di string pengganti, lalu setelahnya harus ada direktif set yang mereferensikan grup tangkapan regex
  Contoh: set $var $1
  Selain itu, proof of concept ini mengasumsikan ASLR dinonaktifkan

  • Contoh: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • Apakah ada distro yang mematikan ASLR secara default?
    Bahkan kalau dimatikan manual pun, nginx bukan kandidat yang langsung terlintas untuk itu
  • Bukankah sekarang rewrite hampir tidak dipakai lagi?
    Rasanya itu dipakai pada era lama PHP dan Apache

• Halaman resmi F5 ada di sini: https://my.f5.com/manage/s/article/K000161019
  Seperti yang juga ditulis di tempat lain, ASLR memang memberi perlindungan
  Sebagai mitigasi sambil menunggu perbaikan untuk platform yang terdampak, mereka menyarankan untuk “menggunakan named capture alih-alih unnamed capture dalam definisi rewrite”
  Isinya adalah “untuk memitigasi kerentanan pada contoh ini, ubah $1 dan $2 menjadi named capture yang sesuai, yaitu $user_id dan $section”
  F5 telah mem-patch 1.31.0 dan 1.30.1
  OpenResty memiliki patch untuk 1.27 dan 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  Perkembangan OpenResty, server aplikasi Lua berbasis Nginx, bisa dilihat di sini: https://github.com/openresty/openresty/issues/1119

• Proof of concept ini menonaktifkan ASLR: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Proses worker di-fork dari master, jadi menerima tata letak memori yang sama
    Anda bisa membuat worker crash tanpa batas
    Sangat mungkin hal ini bisa dimanfaatkan untuk membuat oracle baca
    Setidaknya penolakan layanan yang stabil tampaknya memungkinkan
    Analisis lengkap dari Depth First: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• Apakah ada alternatif bagus untuk Apache dan Nginx yang ditulis dalam bahasa yang aman memori dan tidak punya banyak lubang keamanan?
  Saya sempat melihat Jetty yang ditulis dalam Java dan Caddy yang ditulis dalam Go, tetapi karena Jetty punya riwayat jenis kerentanan lain seperti shell injection, saya tidak yakin itu benar-benar lebih baik

  • Keamanan memori itu bagus, tetapi tidak menghentikan semua ancaman
    Operator infrastruktur saat ini juga perlu membiasakan diri dengan pertahanan aktif berupa MAC, yaitu SELinux dan AppArmor
    Dulu friksinya besar, tetapi sekarang ada lebih banyak alat yang mempermudah penggunaannya
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Sebagai catatan, kedua repositori itu saya buat sendiri
  • Untuk perangkat lunak yang dipakai pada skala seperti Apache dan nginx, riwayat kerentanan itu nyaris tak terhindarkan
    Fakta bahwa keduanya bisa mempertahankan pangsa pasar selama itu justru merupakan sinyal yang baik
  • Caddy benar-benar sangat mudah dipakai
    Hanya saja saya kurang suka model yang menghasilkan ribuan biner tergantung kombinasi plugin yang diinginkan, alih-alih sistem plugin yang layak
    Meski begitu, kalau dibangun dari source, itu cukup rapi dan sederhana
  • Apache dan mungkin Nginx juga punya sangat banyak fitur dan komponen
    Sebagian besar server HTTP alternatif memang memangkas cakupan cukup besar, jadi Anda perlu menentukan dulu fitur apa yang dibutuhkan
    Saya belum banyak melihat pembahasan tentang server HTTP dalam bahasa yang aman memori
    Tiga server besar berbasis C, yaitu Apache, Nginx, dan lighttpd, semuanya cukup kokoh, dan tampaknya tidak banyak orang yang ingin pindah ke proyek baru hanya karena bahasanya
    Selain itu, memilih kebanyakan bahasa aman memori biasanya juga berarti ikut menerima runtime atau mesin virtual bahasa tersebut yang kadang sangat besar, beserta komponen pelengkapnya
    Kalau itu web server Java, ada kemungkinan ia memakai log4j seperti proyek Java acak pada umumnya
  • Untuk keperluan load balancer, HAProxy bekerja sangat baik

• “Eksploit ini menggunakan heap feng shui lintas-permintaan (cross-request heap feng shui),” saya rasa ini pertama kalinya saya melihat feng shui dipakai dengan cara seperti ini

• Apakah ini sudah di-patch di Debian 12?
  Kalau begitu, apakah aman menganggap bahwa jika Anda tidak memakai rewrite atau set di mana pun, Anda tidak terdampak?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • Ubuntu sudah di-patch per pagi ini
    Debian tampaknya belum mem-patch trixie
  • Rasanya sangat jarang ada penggunaan nginx yang bahkan tidak memakai set sama sekali
    Sebagian besar use case nginx adalah terminasi TLS lalu meneruskan permintaan ke node/php/go dan sebagainya
    Jadi saya tadinya mengira pasti ada setidaknya satu set yang memasukkan data yang dikendalikan penyerang, misalnya pada baris seperti proxy_set_header X-Host $host;
    Koreksi: named capture tampaknya tidak terdampak
    Kalau tidak ada $1 di mana pun, seharusnya aman

• Tautan yang lebih baik:
  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)