Banjir `CONTINUATION` HTTP/2: Detail teknis

Kerentanan Banjir CONTINUATION HTTP/2: Detail teknis

• Banjir CONTINUATION adalah kategori kerentanan yang ditemukan di beberapa implementasi protokol HTTP/2, dan menimbulkan ancaman yang lebih serius daripada serangan Rapid Reset.
• Dampak serangan ini beragam, mulai dari server crash hingga penurunan performa, dan permintaan serangan tidak muncul di log akses HTTP.

Pendahuluan

• Pada Oktober 2023, penulis mengetahui tentang serangan HTTP/2 Rapid Reset dan memutuskan untuk memulai riset dari sudut pandang analisis keamanan terhadap HTTP/2.

Pengenalan singkat tentang HTTP/2

• Perbedaan utama antara HTTP/1.1 dan HTTP/2 adalah yang terakhir merupakan protokol biner, dan klien serta server saling bertukar frame alih-alih baris teks.
• Diperlukan penjelasan tentang frame HEADERS dan frame CONTINUATION.

Frame HEADERS

• Frame HEADERS digunakan untuk mengirim header HTTP pada permintaan dan respons, serta mengompresi data header menggunakan algoritma encoding HPACK.
• Pada frame dapat diatur flag seperti END_HEADERS dan END_STREAM.

Frame CONTINUATION

• Frame CONTINUATION sangat mirip dengan frame HEADERS, tetapi hanya memiliki flag END_HEADERS; jika flag ini diatur, itu berarti aliran header telah berakhir.

Kerentanan Banjir CONTINUATION

• Jika klien memulai stream HTTP/2 baru lalu mengirim frame HEADERS dan CONTINUATION, tetapi flag END_HEADERS tidak pernah diatur, server harus terus menganalisis dan menyimpan aliran header yang tak terbatas di memori.
• Pada HTTP/1.1, perlindungan terhadap header tak terbatas diberikan melalui batas ukuran header serta timeout permintaan/header, tetapi pada banyak server HTTP/2 perlindungan ini tidak ada atau diimplementasikan dengan keliru.

Konsumsi CPU: kasus Golang

• Golang adalah contoh konsumsi CPU akibat Banjir CONTINUATION, karena menggunakan kelas abstrak http2MetaHeadersFrame untuk menangani frame HEADERS dan CONTINUATION.
• Decoder HPACK dikonfigurasi untuk berhenti memancarkan header saat mencapai batas ukuran header, tetapi tanpa flag END_HEADERS, fungsi tidak pernah mengembalikan hasil dan terus mendekode header.

Kehabisan memori

• Kehabisan memori adalah salah satu kasus paling serius, karena ada implementasi yang tidak membatasi ukuran daftar header yang dibangun menggunakan frame CONTINUATION.
• Pada implementasi tanpa timeout header, satu koneksi HTTP/2 saja sudah dapat membuat server crash.

Crash assertion yang dapat dicapai: Node.js (kasus khusus)

• Node.js menangani aliran tak terbatas frame CONTINUATION dengan semestinya, tetapi bug data race terjadi saat koneksi terputus di tengah aliran header.
• Node.js melacak alokasi memori di dalam destruktor Http2Session, dan saat koneksi terputus, nilai current_nghttp2_memory_ dapat diperbarui secara bersamaan sehingga memicu crash.

Perbandingan dengan kerentanan HTTP/2 sebelumnya

• Di masa lalu, berbagai kerentanan HTTP/2 telah dilaporkan, dan Banjir CONTINUATION bekerja dengan cara yang berbeda dari kerentanan-kerentanan sebelumnya.
• Banjir CONTINUATION tidak mengirim header kosong, melainkan mengirim banyak header arbitrer hingga batas ukuran frame yang ditetapkan oleh server.

Catatan akhir

• Trafik HTTP/2 mencakup sekitar 60% dari seluruh trafik HTTP manusia, dan mengingat pentingnya proyek-proyek yang terdampak, sebagian besar internet terdampak oleh kerentanan yang mudah dieksploitasi ini.
• Jika kerentanan ini benar-benar dieksploitasi di alam liar, akan sangat sulit bagi administrator server untuk melakukan debugging tanpa pengetahuan HTTP/2 yang memadai.

Opini GN⁺

• Kerentanan ini dapat sangat mengganggu ketersediaan server, dan terutama sulit dilacak serta ditangani karena tidak tercatat di log.
• Administrator server harus secara rutin menerapkan pembaruan keamanan dan menggunakan alat analisis trafik untuk mendeteksi pola yang tidak normal.
• Kerentanan seperti ini membangunkan kewaspadaan komunitas keamanan siber dan menekankan pentingnya desain serta implementasi protokol yang lebih aman.
• Jika dilihat secara kritis, kerentanan ini mengungkap cacat desain mendasar pada protokol yang digunakan secara luas, yang menimbulkan pertanyaan tentang keandalan infrastruktur dasar internet.
• Jika bukan ahli dengan pengetahuan di bidang terkait, memahami dan merespons kerentanan kompleks seperti ini bisa jadi sulit, sehingga pendidikan keamanan dan peningkatan kesadaran diperlukan.

[GN⁺]

Opini Hacker News

• Isu ini baru-baru ini diperbaiki di Bandit

  • Pengalaman pribadi bahwa masalah yang sama telah diperbaiki di Bandit sebulan lalu.
  • Menyediakan lokasi kode yang spesifik melalui tautan.
  • Dari sudut pandang implementator, masalah ini sangat jelas, dan ia mengira implementasi lain juga sudah menyiapkan perlindungan.
  • Namun setelah memeriksa puluhan implementasi, ternyata bahkan server HTTP/2 utama pun tidak memiliki perlindungan semacam ini atau menerapkannya dengan keliru.

• Kritik terhadap budaya pengembangan

  • Menunjukkan bahwa masalahnya adalah budaya para pengembang yang terlalu terbiasa dengan segala sesuatu yang otomatis meluas secara dinamis, sehingga tidak memikirkan seberapa besar sesuatu bisa membesar.
  • Masalah ini tidak terbatas pada HTTP/2 saja, tetapi kompleksitas HTTP/2 dapat memperburuknya.
  • Pada masa HTTP/1.x dulu, saat menggunakan bahasa seperti C, perhatian terus-menerus terhadap pengelolaan panjang buffer diperlukan, dan tidak pernah ada alokasi header permintaan yang diperluas tanpa batas.

• Daftar server/reverse proxy yang tidak terdampak

  • Daftar web server dan reverse proxy yang tidak terdampak yang disebutkan di artikel sebelumnya.
  • Nginx, Jetty, HAProxy, NetScaler, dan Varnish tidak terdampak.

• Pertimbangan tentang keamanan HTTP/1.1

  • Disebutkan bahwa situs kami mendapat sorotan sepanjang hari.
  • Mengajukan pertanyaan apakah lebih aman menggunakan HTTP/1.1 jika lalu lintas situs kami rendah.

• Pujian untuk penulis

  • Memuji penulis karena mendekati masalah ini dengan sudut pandang yang luas, melaporkan temuannya secara bertanggung jawab, dan membagikannya dengan cara yang mudah dibaca.

• Penyebutan Slowloris v2

  • Bercanda bahwa jika masalah ini dimunculkan secara perlahan, itu bisa disebut 'slowloris v2'.

• Penyebutan salah ketik

  • Menganggap salah ketik 'serveral retries' lucu.

• Pandangan kritis terhadap HTTP/2

  • Kritik terhadap bagaimana HTTP/2 bisa didorong sebagai lapisan transport untuk 'upgrade' ke protokol lapisan aplikasi.