Chrome Memperbaiki Kerentanan Heap Buffer Overflow WebP

 (chromereleases.googleblog.com)
1 poin oleh GN⁺ 2023-09-13 | 1 komentar | Bagikan ke WhatsApp
  • Pembaruan kanal Chrome Stable dan Extended Stable untuk desktop telah dirilis, termasuk perbaikan kerentanan heap buffer overflow WebP
  • Build baru adalah 116.0.5845.187 untuk Mac dan Linux, serta 116.0.5845.187/.188 untuk Windows, dan akan diterapkan bertahap selama beberapa hari hingga beberapa minggu
  • Rilis ini memuat 1 perbaikan keamanan, dan CVE-2023-4863 diklasifikasikan sebagai tingkat Critical
  • Apple SEAR dan The Citizen Lab dari University of Toronto Munk School melaporkan kerentanan tersebut pada 6 September 2023
  • Google menyatakan ada kasus eksploitasi nyata, dan akses ke detail bug dapat dibatasi hingga versi perbaikan diterapkan

Pembaruan Kanal Chrome Desktop

  • Kanal Stable dan Extended Stable telah diperbarui ke build baru untuk desktop
  • Versi kanal Stable per platform adalah sebagai berikut
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • Kanal Extended Stable juga dirilis dengan versi tersendiri
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • Pembaruan didistribusikan bertahap selama beberapa hari hingga beberapa minggu
  • Daftar lengkap perubahan pada build ini dapat dilihat di log

Perbaikan Keamanan: CVE-2023-4863

  • Rilis ini mencakup 1 perbaikan keamanan
  • Perbaikan utama yang dikontribusikan oleh peneliti eksternal adalah kerentanan berikut
    • Critical CVE-2023-4863: heap buffer overflow di WebP
    • Nomor bug: 1479274
    • Pelapor: Apple Security Engineering and Architecture(SEAR), The Citizen Lab dari University of Toronto Munk School
    • Tanggal laporan: 6 September 2023
    • Jumlah imbalan: $NA

Eksploitasi Nyata dan Pembatasan Pengungkapan Informasi

  • Google menyatakan eksploit CVE-2023-4863 ada di lingkungan nyata
  • Akses ke detail bug dan tautan dapat dibatasi sampai mayoritas pengguna memperbarui ke versi yang telah diperbaiki
  • Pembatasan juga dapat dipertahankan jika bug yang sama berada di library pihak ketiga yang juga diandalkan proyek lain dan belum diperbaiki

Deteksi Bug Keamanan dan Jalur Pelaporan

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-13
Komentar Hacker News

  • Di Google Chrome, gambar WebP didekodekan di proses renderer, jadi meskipun eksploit berhasil, yang bisa dilakukan hanya eksekusi kode renderer di dalam sandbox.
    Renderer sangat kompleks sehingga banyak eksploit ditemukan setiap tahun, tetapi bahkan jika berhasil mendapatkan eksekusi kode di renderer, haknya tidak jauh melampaui hak yang dimiliki halaman web biasa.
    Secara khusus, ia tidak bisa melihat atau meninggalkan file di filesystem lokal, dan juga tidak bisa membaca cookie dari domain lain.

    • Tentu saja ceritanya berbeda jika ada eksploit sandbox escape untuk digabungkan dengan ini.
      Ini bukan prioritas tertinggi seketika, tetapi jika eksploit seperti itu belum beredar di alam liar, sebaiknya dipatch secepat mungkin pada waktu yang tidak terlalu merepotkan.
    • Di internet modern ada sangat banyak gambar yang diunggah pengguna, jadi mendapatkan hak konteks pengguna pada satu situs web saja sudah cukup besar.
      Ini lebih mirip XSS versi lebih kuat karena tidak terikat pada satu situs atau frontend.
    • Saya memakai WebP lossless, dan jauh lebih efisien daripada PNG.
      Ah, saya menulis di thread yang salah; saya bermaksud membalas “jpeg is good enough” di https://news.ycombinator.com/item?id=37479576.
    • Apakah itu berarti renderer tidak bisa mengirim informasi kembali ke situs web?
      Selain itu, meskipun JavaScript dimatikan, bukankah ini tiba-tiba membuat situs web tetap bisa menjalankan kode?

  • Jadi saya jadi lebih memahami mengapa para pengembang browser lambat dalam mengadopsi format baru.
    WebP tidak punya keunggulan besar dibanding JPEG, terutama hanya soal transparansi, dan keberhasilannya pun terbatas.
    Namun sekarang ini berujung pada beberapa celah keamanan prioritas tinggi, dan setiap tempat yang menautkan libwebp harus mendistribusikan patch selama sebulan ke depan.
    Bukan berarti jangan melakukan hal baru, tetapi menurut saya pengembang cenderung cukup besar meremehkan biayanya.

    • Firefox memiliki lapisan sandbox tambahan yang bisa diterapkan ke library individual, bukan seluruh proses: https://hacks.mozilla.org/2021/12/webassembly-and-back-again....
    • Agar adil, dulu masalah pada library decoding JPEG juga pernah digunakan sebagai jalur pengiriman malware.
      Memang benar ekosistem WebP jauh kurang matang, tetapi saya yakin kode pemrosesan format yang lebih tua pun punya cukup banyak masalah keamanan.
      Meski begitu, logikanya valid. Baru beberapa minggu lalu suasananya adalah netizen berargumen bahwa JPEG XL harus diadopsi secepat mungkin, dan untuk itu pengembang browser “cukup memasukkan kode reference decoder ke codebase” dengan “biaya nyaris nol”.
    • Apakah bug seperti ini akan ditemukan jika browser tidak mengadopsi format baru?
      Format dan library gambar lain kemungkinan besar juga penuh bug, tetapi karena tidak dipakai di software utama, tidak ada yang peduli.
      Terutama bagi orang yang punya kemampuan menemukan dan mengeksploitasi bug semacam ini, imbalannya buruk dibanding waktu yang dihabiskan.
      Tidak dipakai lama bukan berarti bug-nya berkurang.
    • Penyebab celah keamanan ini bukan format gambar baru, melainkan kurangnya memory safety di C/C++.
      Jika encoder dan decoder gambar, serta encoder/decoder lain, tidak memakai bahasa yang tidak aman, kemungkinan terciptanya bug seperti ini akan lebih rendah.
    • WebP adalah format yang jauh lebih kompleks daripada JPEG, dan kompleksitas hampir berkorelasi langsung dengan kepadatan cacat.
      Terlepas dari itu, saya juga melihat masalah pada budaya yang membuat kode lebih rumit dari yang diperlukan dan pada pengembang yang tidak benar-benar memahami detailnya.

  • Perbaikan ini masuk ke Firefox 117.0.1 dan Fenix 117.1.0 hari ini: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • Sebagai referensi, crate image memiliki implementasi decoder WebP yang ditulis dalam Rust yang aman: https://github.com/image-rs/image
    Sudah lama cukup belum lengkap, tetapi tahun lalu banyak fitur WebP diimplementasikan.
    Chromium sekarang punya kebijakan yang mengizinkan penggunaan dependensi Rust, jadi mungkinkah Chromium juga mulai mengadopsinya?

    • Jika Chrome punya flag “gunakan versi aman dari library XYZ meskipun mungkin lebih lambat”, saya akan langsung menyalakannya meski harus menerima penurunan performa.
    • Rasanya tidak masuk akal bahwa pada 2023 masih terus menulis kode C/C++ baru untuk target dengan permukaan serangan sebesar browser web.

  • Commit asli yang bermasalah: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    Commit yang memperbaiki bug ini: https://github.com/webmproject/libwebp/commit/902bc919033134...
    Commit asli mengoptimalkan decoder Huffman. Decoder ini memakai optimisasi yang sudah dikenal: membaca N bit terlebih dahulu, lalu menentukan berapa bit yang sebenarnya harus dikonsumsi dan simbol apa yang harus didekode. Atau, jika itu adalah prefiks N bit dari beberapa simbol, menentukan tabel mana yang harus dirujuk untuk bit yang tersisa.
    Versi lama memakai tabel lookup untuk simbol pendek, tetapi simbol panjang memerlukan traversal graf. Versi baru memperbaikinya dengan memakai array tabel lookup. Tiap entri berisi (nbits, value), dengan nbits adalah jumlah bit yang dikonsumsi dan value biasanya berupa simbol. Namun jika nbits melebihi N, value ditafsirkan sebagai indeks tabel, dan nbits ditafsirkan ulang sebagai panjang kode terpanjang di subpohon tersebut. Jadi tiap tabel berikutnya harus memiliki 2^(nbits - N) entri. Tabel root selalu tetap berukuran 2^N entri.
    Versi baru menghitung jumlah entri maksimum (kTableSize) berdasarkan jumlah simbol. Tentu saja pohon Huffman berasal dari input yang tidak tepercaya, dan mudah dibayangkan kasus ketika nbits menjadi sangat besar. VP8 Lossless secara spesifik mengizinkan hingga maksimum 15 bit, jadi jika semua LUT masing-masing dipetakan ke tabel bantu terpisah, tabel maksimum yang mungkin menjadi 2^N + 2^15 entri. Untuk membuat ini pun tidak perlu terlalu banyak simbol; cukup 16-N simbol untuk tiap tabel.
    Menariknya, kode itu sendiri memiliki mode yang hanya menghitung ukuran tabel (memanggil VP8LBuildHuffmanTable dengan root_table == NULL), tetapi entah kenapa tidak digunakan dan malah mengasumsikan ukuran maksimum tetap. Jadi jika pohon Huffman dibuat untuk memaksimalkan jumlah entri, penulisan akan meluap melewati area yang dialokasikan.
    Bisa dimengerti mengapa hal seperti ini terjadi. Tahap decoding Huffman adalah salah satu bagian dengan beban komputasi terbesar dalam banyak format kompresi, sehingga peningkatan kecil pun penting. Optimisasi di atas memang sudah dikenal, tetapi jalur kode panjang umumnya dianggap jarang, sehingga prioritas optimisasinya rendah. Pesan commit asli membantah asumsi ini dan bisa digabungkan. Sulit juga memastikan apakah bahasa yang aman memori akan mencegah masalah ini. Karena, jarang terjadi, tetapi dalam kasus ini orang justru ingin secara aktif menghindari pemeriksaan overflow.
    [1] Namun kerusakan memori terjadi saat penyusunan tabel, bukan di loop yang ketat, jadi pemeriksaan overflow parsial akan sangat membantu. Perbaikan sebenarnya sama sekali tidak mengubah fungsi ReadSymbol. Meski begitu, keamanan loop yang ketat harus dibenarkan, dan pembenaran yang keliru bisa merusak semuanya.

    • Komponen ini seharusnya ditulis dengan WUFFS.
      Jika benar tidak perlu pemeriksaan batas, itu tidak masalah. WUFFS tidak mengeluarkan pemeriksaan batas runtime.
      Namun jika software keliru hingga keluar dari batas seperti kali ini, di WUFFS ia tidak akan bisa dikompilasi.
      Orang mungkin berpikir “itu mustahil”, dan jika WUFFS adalah bahasa pemrograman serbaguna, itu benar. Menurut teorema Rice, properti semantik nontrivial tidak dapat diputuskan.
      Untungnya WUFFS bukan bahasa serbaguna. Sebagian besar software tidak bisa ditulis dengan WUFFS, tetapi codec gambar bisa.
    • Sudah lebih dari 10 tahun sejak saya bekerja sebagai programmer C, dan dari dulu pun saya tidak terlalu jago, tetapi dari penjelasannya saya setuju bahwa pemeriksaan batas akan menangkap masalah ini.
      Namun saya juga penasaran apakah mungkin membuat pengujian otomatis yang menangkap masalah semacam ini.
      Pada kode yang saya tangani sendiri, sebagian perhitungan bisa dipisahkan ke fungsi tersendiri agar bisa diuji secara independen. Di sini mungkin sulit karena alasan performa, tetapi saya tidak yakin.

  • Perbaikan penulisan di luar rentang pada BuildHuffmanTable
    https://github.com/webmproject/libwebp/commit/902bc919033134...

  • Tampaknya dilaporkan oleh Apple, dan terlihat sangat mirip dengan pembaruan keamanan ini: https://support.apple.com/en-us/HT213906

    • Dilaporkan oleh Apple dan “Citizen Lab dari UoT Munk School”, dan halaman yang ditautkan menuliskannya persis seperti itu.
      Jadi kemungkinannya cukup tinggi. Apple mungkin memakai libwebp secara internal di ImageIO, atau bisa saja membuat kesalahan serupa.
    • Menarik melihat betapa berbedanya respons minggu lalu dan sekarang.

  • Codec gambar memiliki sejarah panjang kerentanan.
    Pemrosesan gambar yang sebenarnya bisa berupa kode linear yang rapi sampai-sampai dapat ditulis dengan FORTRAN IV yang aman memori, tetapi begitu kompresi masuk, ada banyak struktur data panjang variabel, penelusuran pointer, dan sebagainya.
    Di atas itu masih ada tekanan agar berjalan cepat.

  • Apakah ini juga berdampak pada Electron? Kalau ya, versi yang mana?

  • Apakah ada jalur realistis untuk mengeksploitasi ini?
    Dari yang saya dengar, di 64-bit heap spray sudah tidak praktis lagi
    Apakah ada objek yang dapat diprediksi di dalam memori yang bisa ditimpa?

    • Karena sudah dieksploitasi di alam liar, jawabannya adalah ya
      Bahkan di 64-bit, heap spray jelas masih digunakan dalam eksploit kernel. Saya kurang tahu primitive apa yang dipakai orang dalam eksploit V8