Analisis 0day WebP

 (blog.isosceles.com)
2 poin oleh GN⁺ 2023-09-23 | 1 komentar | Bagikan ke WhatsApp
  • Satu-satunya perbaikan keamanan dalam pembaruan stabil Chrome, CVE-2023-4863, adalah heap buffer overflow di pustaka gambar WebP, dan Google menyatakan eksploitnya sudah ada di lingkungan nyata
  • Laporan Apple SEAR pada 6 September 2023, CVE-2023-41064 milik Apple, dan indikasi BLASTPASS dari Citizen Lab sangat mungkin mengarah ke bug yang sama
  • Kerentanan ini dianalisis sebagai masalah yang memungkinkan penulisan melampaui ukuran buffer yang telah dihitung sebelumnya saat proses penyusunan tabel Huffman untuk kompresi lossless VP8L di WebP
  • Alasan fuzzing umum mudah melewatkannya adalah karena ada kondisi pemicu yang rumit: beberapa tabel Huffman berukuran maksimum dan tabel tidak valid tertentu harus dibentuk secara berurutan
  • Patch upstream libwebp tampak memadai, tetapi karena libwebp digunakan luas di browser, sistem operasi, dan aplikasi, penyebaran patch serta sandboxing sangat penting

Mengapa patch Chrome terhubung ke BLASTPASS

  • Google memperbaiki CVE-2023-4863 yang dilaporkan oleh Apple Security Engineering and Architecture (SEAR) dalam pembaruan stabil Chrome pada awal September 2023
    • Kerentanannya adalah heap buffer overflow di pustaka gambar WebP
    • Google menyatakan mengetahui bahwa “eksploit untuk CVE-2023-4863 ada di lingkungan nyata”
  • Pada periode yang sama, Citizen Lab mendeteksi perilaku mencurigakan di iPhone milik seseorang yang tergabung dalam organisasi masyarakat sipil berbasis di Washington DC
    • BLASTPASS terkait dengan kasus eksploit zero-click zero-day iMessage yang menyebarkan spyware Pegasus milik NSO Group
    • Setelah Citizen Lab menyerahkan hasil analisis teknis ke Apple, Apple mengungkap dua CVE dalam pengumuman keamanan pada 7 September
  • CVE pertama Apple, CVE-2023-41061, selaras dengan indikasi bahwa eksploit gambar dibungkus dalam lampiran PassKit untuk melewati sandbox BlastDoor di iMessage
    • Gambar berbahaya itu tampaknya diproses di proses lain yang tidak memiliki sandbox
  • CVE kedua, CVE-2023-41064, adalah kerentanan buffer overflow di Apple ImageIO
    • ImageIO adalah framework parsing gambar Apple yang mengidentifikasi berbagai format gambar dan menghubungkannya ke decoder yang sesuai
    • Karena tidak ada detail teknis, tidak dapat dipastikan format gambar apa yang terdampak oleh CVE-2023-41064
  • Karena Apple baru-baru ini menambahkan dukungan WebP ke ImageIO, tim keamanan Apple melaporkan kerentanan WebP ke Chrome pada 6 September, dan Google merilis patch darurat dalam 5 hari serta menandainya sebagai dieksploitasi secara nyata, kemungkinan besar BLASTPASS dan CVE-2023-4863 adalah bug yang sama

Lokasi kerentanan yang ditunjukkan oleh patch libwebp

  • Dengan mencocokkan bug ID di pengumuman keamanan Chrome dan commit open-source libwebp, patch Fix OOB write in BuildHuffmanTable sesuai dengan CVE-2023-4863
    • Patch dibuat pada 7 September 2023, sehari setelah laporan Apple
  • Kerentanan ada di VP8L, dukungan kompresi lossless milik WebP
    • Kompresi lossless WebP menggunakan Huffman coding untuk menyimpan dan memulihkan piksel dengan akurasi 100%
    • Implementasi modern mengoptimalkan decoding dengan menggunakan tabel alih-alih struktur tree konseptual
  • Versi yang rentan mengalokasikan memori dengan ukuran buffer yang telah dihitung sebelumnya dari tabel tetap, lalu langsung membangun tabel Huffman di ruang itu
    • Versi baru menghitung total ukuran yang dibutuhkan untuk tabel output pada pass pertama tanpa benar-benar menulis
    • Jika total ukuran melebihi buffer yang telah dihitung sebelumnya, alokasi yang lebih besar akan dibuat
  • Alur inti ada pada huffman_tables yang dialokasikan oleh ReadHuffmanCodes di src/dec/vp8l_dec.c serta pemanggilan VP8LBuildHuffmanTable/BuildHuffmanTable di dalam ReadHuffmanCode
    • Tabel Huffman dibagi menjadi 5 segmen dengan ukuran alfabet yang berbeda
    • Untuk memicu overflow, kelima tabel ini harus disusun dengan sangat presisi

Proses membuat file pemicu

  • Kompresi lossless WebP menetapkan bitstring pendek ke nilai yang sering muncul dan bitstring panjang ke nilai yang jarang muncul berdasarkan analisis frekuensi piksel input
    • Kode disusun agar decoder selalu bisa membedakan panjang bitstring
    • Gambar terkompresi harus menyertakan informasi statistik dan penetapan kode untuk merekonstruksi pemetaan antara kode dan nilai
  • WebP juga mengompresi tabel Huffman itu sendiri dengan Huffman coding untuk mengurangi ukuran file
    • Struktur ini membuat proses analisis dan pemicuan kerentanan menjadi rumit
  • @mistymntncop menyediakan kode harness untuk membuat WebP dengan format valid yang memiliki data Huffman coding arbitrer, yaitu code lengths
    • Dengan harness ini, array code_lengths arbitrer dapat diberikan ke pemanggilan BuildHuffmanTable target
  • Dalam eksperimen manual, interaksi antara histogram di dalam BuildHuffmanTable, num_open, num_nodes, dan nilai key yang melacak posisi awal ReplicateValue sangat kompleks
    • Root table dari count[0] hingga count[8] tidak terlalu memengaruhi total_size secara langsung, tetapi dapat mengubah state internal berikutnya
    • Second level tables dari count[9] hingga count[15] langsung memengaruhi total_size akhir
  • enough.c milik Mark Adler menghasilkan histogram lookup table tree Huffman maksimum yang mungkin untuk ukuran alfabet, ukuran root table, dan panjang kode maksimum tertentu
    • Ada komentar yang menyatakan kTableSize di libwebp dihitung dengan alat ini
    • Dengan alat itu, ukuran buffer yang telah dihitung sebelumnya dapat direproduksi, dan dengan alat dari @mistymntncop juga dapat dipastikan bahwa code lengths buatan “enough” mengisi alokasi huffman_tables hingga 100%

Kondisi saat overflow benar-benar terjadi

  • Alat enough menghitung nilai maksimum untuk kode yang valid dan lengkap
    • Untuk salah satu tabel kecil, yaitu ukuran simbol 40, root table 8 bit, dan panjang kode maksimum 15, ukuran maksimumnya adalah 410
    • Tidak ditemukan kasus kode yang dianggap valid oleh BuildHuffmanTable tetapi menghasilkan ukuran lebih besar dari 410
  • Overflow terjadi bukan dengan hanya membuat tree Huffman yang valid, melainkan saat tree Huffman tidak valid dimasukkan pada tahap terakhir
    • Empat tree Huffman valid terlebih dahulu membentuk tabel output berukuran maksimum
    • Jika tree Huffman tidak valid dimasukkan ke tabel terakhir, ReplicateValue dapat menulis di luar batas sebelum pemeriksaan konsistensi akhir
  • Reproduksi dilakukan dengan checkout commit libwebp rentan 7ba44f80f3b94fc0138db159afea770ef06532a0, mengaktifkan AddressSanitizer, lalu membuat bad.webp dengan kode PoC dari @mistymntncop dan mendekodenya dengan dwebp
    • AddressSanitizer melaporkan heap-buffer-overflow di BuildHuffmanTable
    • Penulisan yang dilaporkan terjadi tepat setelah area berukuran 11816 byte
  • Ada beberapa input yang dapat menyebabkan overflow pada huffman_tables
    • Di antara code lengths yang ditemukan, ada kasus yang menulis hingga 400 byte melewati akhir alokasi huffman_tables
    • Meski kontrol terhadap nilai yang ditulis hanya parsial, eksploitasi tampak memungkinkan
  • Tree Huffman dari input tidak valid sebagian tidak seimbang, dan satu bagian dari cabang yang tidak seimbang itu berisi banyak node internal tanpa anak
    • Struktur ini menciptakan indeks key yang tidak dapat dicapai oleh tree valid

Cara patch mencegah overflow

  • Awalnya patch tampak seperti sekadar mencegah heap overflow dengan memperbesar buffer secara dinamis sesuai ukuran yang dibutuhkan
  • Kenyataannya, pass pertama pada versi yang telah dipatch menjalankan BuildHuffmanTable untuk menghitung total ukuran yang dibutuhkan tanpa menulis ke tabel
    • Input tidak valid yang menyebabkan overflow akan membuat BuildHuffmanTable gagal dan mengembalikan 0 pada pass pertama ini
    • Karena pass pertama tidak melakukan penulisan, pemrosesan parsial atas tree tidak valid tidak menyebabkan penulisan di luar batas
  • Karena tidak ditemukan kasus kode yang valid dan lengkap yang menyebabkan overflow yang sama, patch ini tampak memadai

Mengapa fuzzing mudah melewatkannya

  • libwebp telah lama difuzzing di Google OSS-Fuzz, dan dukungan lossless WebP juga telah difuzzing secara luas
  • Kesulitan utamanya adalah format dan kondisi pemicunya sama-sama kompleks
    • Dari miliaran kemungkinan, empat tabel Huffman berukuran maksimum untuk ukuran alfabet 280 dan 256 harus dibentuk lebih dulu
    • Lalu harus dibuat tabel Huffman tidak valid dengan bentuk yang sangat spesifik untuk ukuran alfabet 40
    • Jika di tahap mana pun ada 1 bit saja yang salah, decoder gambar akan memunculkan error dan berhenti dengan aman
  • Setelah memperbaiki WebP 0day, Google merilis fuzzer baru khusus untuk rutin Huffman WebP
    • Bahkan dengan menjalankan fuzzer itu, CVE-2023-4863 tetap tidak ditemukan
  • Mutasi bitflip standar, loop umpan balik code coverage, dan pendekatan berbasis input-state seperti CmpLog dari AFL++ juga sulit melewati tahapan antara menuju state ekstrem ini
    • Teknik dynamic symbolic execution seperti TritonDSE dari Quarkslab mungkin berpotensi, tetapi belum dipastikan
  • Sifatnya berbeda dengan kerentanan Load_SBit_Png di FreeType
    • Load_SBit_Png tidak ditemukan karena harness fuzzing tidak cukup mencerminkan cara penggunaan API
    • CVE-2023-4863 lebih dekat ke kasus yang sulit difuzzing karena kendala pada kerentanannya sendiri, bukan karena kekurangan harness

Cakupan dampak dan status mitigasi

  • Citizen Lab menangkap eksploit canggih yang digunakan di lingkungan nyata, dan Apple serta Chrome tampaknya mendistribusikan pembaruan ke miliaran pengguna dalam beberapa hari
  • Android saat itu masih mungkin terdampak
    • BitmapFactory di Android, seperti Apple ImageIO, menangani decoding gambar dan mendukung libwebp
    • Pada saat itu pengumuman keamanan Android belum mencakup perbaikan CVE-2023-4863, tetapi perbaikannya sudah digabungkan ke AOSP
    • Jika Android terdampak, ini dapat mengarah ke eksploit jarak jauh di aplikasi seperti Signal atau WhatsApp
    • Diperkirakan akan diperbaiki dalam pengumuman keamanan Oktober
  • Patch upstream libwebp tampaknya telah diterapkan dengan benar dan sedang disebarkan ke tempat yang memerlukannya
  • Karena libwebp digunakan di banyak tempat, mungkin butuh waktu sampai patch cukup tersebar luas
  • Kode parser kompleks yang dekat dengan permukaan serangan remote exploit zero-click seperti decoding gambar sulit diamankan hanya dengan fuzzing, dan perlu investasi pada review source code proaktif serta sandboxing yang memadai

Asimetri dalam pengungkapan informasi teknis

  • Jika vendor tidak cukup mengungkap detail teknis, pembela akan kesulitan memverifikasi dampak kerentanan
  • Penyerang memiliki motivasi kuat untuk melacak dan mengeksploitasi kerentanan N-day, dan tidak terlalu terhambat walau detail tidak diungkapkan
  • Pembela sering kali tidak memiliki sumber daya untuk melakukan analisis teknis sedalam ini
  • Jika bahkan informasi dasar tentang perilaku serangan disembunyikan, akan muncul asimetri di mana penyerang memiliki lebih banyak wawasan tentang kerentanan dan eksploit dibanding pembela

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-23
Pendapat di Hacker News

  • Bug ini tampaknya paling mirip dengan bug Timsort dari tahun 2015 [1]
    Timsort adalah algoritma pengurutan hibrida cerdas yang berasal dari CPython, dan berbagai implementasi, termasuk OpenJDK, mengadopsinya hampir sebagai terjemahan tingkat sumber. Algoritma ini mempertahankan stack run yang sudah terurut, dan ada pembuktian bahwa secara struktural terdapat batas atas hingga yang cukup kecil untuk ukuran stack maksimum yang mungkin. Namun implementasi asli CPython tidak persis sesuai dengan pembuktian itu, sehingga dalam kasus langka stack overflow bisa terjadi. Jadi di CPython ini merupakan bug keamanan serius, tetapi di Java kasus tersebut melempar exception, sehingga di OpenJDK tidak menjadi masalah keamanan dengan cara yang sama
    Demikian pula pada bug WebP kali ini, ukuran tabel maksimum telah dibuktikan secara formal, tetapi muncul karena tidak cocok dengan nilai yang masuk ke kode sumber aktual. Bug semacam ini sulit diverifikasi maupun direview. Karena ada pembuktian dan kode sumbernya juga tampak sesuai dengan pembuktian itu, mudah untuk menganggap semuanya baik-baik saja. Ini terlihat sebagai sinyal kuat bahwa kita membutuhkan verifikasi formal yang lebih mudah diakses daripada review manusia, serta penggunaan bahasa yang aman memori. Sistem tipe juga bisa dipandang sebagai bentuk verifikasi formal yang lemah
    [1] http://envisage-project.eu/wp-content/uploads/2015/02/sortin...

    • Pekerjaan seperti ini penting dari sisi performa, jadi seharusnya terutama ditulis dengan WUFFS. WUFFS tidak mengeluarkan pemeriksaan batas seperti Java, atau memeriksa saat runtime ketika Rust tidak jelas apakah indeks berada dalam rentang. Sebaliknya, jika tool tidak dapat memastikan bahwa indeks berada dalam rentang, program itu sendiri akan ditolak
      https://github.com/google/wuffs
      Kita juga bisa menulis pemeriksaan yang sama secara eksplisit untuk memenuhi persyaratan ini, tetapi jika sebelumnya percaya bahwa pemeriksaan tidak diperlukan karena ini software berperforma tinggi, kemungkinan besar kita akan menyadari bahwa keyakinan itu salah pada titik ketika tool WUFFS menolak kode. Ini lebih lemah daripada verifikasi formal penuh, tetapi merupakan peningkatan besar untuk tujuan keselamatan program, dan jauh lebih baik daripada manusia yang berkata “LGTM”
    • Pernyataan bahwa “sistem tipe bisa dipandang sebagai verifikasi formal yang lemah” bergantung pada jenis sistem tipe. Baru-baru ini saya melihat Idris, dan tampaknya itu adalah bahasa pemrograman serbaguna sekaligus bisa dipakai untuk pembuktian

  • Selain “apa yang harus dipatch sekarang”, ada beberapa bagian menarik dalam tulisan ini. Bahkan jika lokasi kerentanan dan perbaikannya diketahui, mereproduksi PoC exploit bisa membutuhkan cukup banyak pekerjaan, dan decompressor lossless di dalam decoder gambar bisa cukup tahan terhadap fuzzing. Bagi orang-orang keamanan mungkin ini sudah jelas, tetapi sebagai nonspesialis, ini menarik untuk dibaca

    • Solusi untuk masalah seperti ini bukan fuzzing, melainkan memotong keluar kode tersebut seperti tumor. Jika karena itu berbagai bagian OS atau browser rusak, tulislah satu konverter format yang sangat tersandbox dan aman memori untuk menangani format bermasalah itu. iPhone atau browser yang merepotkan dalam beberapa edge case lebih baik daripada kode seperti ini yang hampir pasti memiliki kerentanan, terlepas dari apakah sudah difuzzing atau belum. Ini memang terdengar optimistis, tetapi saya yakin cerita ini tidak akan berhenti di sini

  • Ada beberapa pertanyaan yang belum bisa saya temukan jawabannya secara jelas. 1) Apakah browser berbasis Chrome lain seperti Brave juga terdampak? 2) Apakah Chrome desktop juga terdampak, atau hanya masalah di mobile? 3) Mengapa saya belum pernah mendengar WebP? Saya penasaran apakah saya yang terputus dari dunia, atau ini teknologi yang berfokus pada mobile

    • Pertanyaan bagus. Browser berbasis Chromium lain kemungkinan besar juga terdampak bug ini. Banyak browser seperti Brave yang mengikuti update keamanan Chromium dengan baik, tetapi ada juga yang cukup tertinggal seperti Samsung SBrowser
      Chrome desktop juga terdampak di Linux maupun Windows. Chrome membundel libwebp sendiri, jadi sekalipun distro Linux belum mempatchnya, selama Chrome sudah terbaru, setidaknya dari sisi serangan terhadap browser seharusnya aman
      Browser dan sistem operasi utama mendukung banyak format gambar yang secara mengejutkan kurang dikenal. Misalnya, MacOS bisa memuat KTX2 (Khronos Texture Container), dan Android bisa memuat DNG (Adobe Digital Negative). Ada banyak attack surface menarik dan sangat terekspos yang bisa dijelajahi penyerang
    • Semua yang mendukung WebP terdampak. Bukan hanya Chrome atau Electron, melainkan semua browser, desktop dan mobile, serta software non-browser. Ini mencakup image viewer, program grafis, email client, hingga file manager yang menampilkan thumbnail
      Bugnya ada di library codec, dan WebP adalah ekosistem yang implementasinya pada praktiknya tersentralisasi, sehingga semua memakai library yang sama dan semuanya perlu dipatch
      Google mendorong WebP 10 tahun lalu, tetapi karena lama hanya untuk Chrome, format ini tidak banyak mendapat daya dorong. Format ini juga tidak benar-benar distandardisasi, meski bersifat open source. Untuk gambar berkualitas rendah, kompresinya lebih baik daripada JPEG, tetapi pada gambar berkualitas tinggi, warnanya cenderung melebar dan tampak buram. Ironisnya, saat WebP mulai didukung luas, secara teknis format ini sudah mulai ketinggalan zaman oleh AVIF dan JPEG XL
    • Hampir pasti Anda pernah mengunduh gambar WebP, tetapi mungkin tidak menyadarinya karena banyak situs web menyajikan beberapa format dari URL yang sama. Biasanya reverse proxy HTTP mengonversi format secara otomatis, sehingga browser dalam 10 tahun terakhir bisa saja menerima WebP walaupun ekstensi file unduhan terlihat seperti “.png”. Semua editor gambar modern mendukung WebP, jadi sulit menyadari perbedaannya
    • WebP sudah lama didukung di Chrome desktop. Puluhan format pengganti JPEG telah muncul dan menghilang, dan WebP menonjol terutama karena membawa pengaruh Google. Saat Google mengakuisisi Duck/On2, mereka memperoleh banyak teknologi kompresi video, dan sebagian di antaranya masuk ke WebP
    • Semua browser terdampak, dan Firefox juga merilis update keamanan. WebP makin populer sebagai pengganti JPEG, jadi mengingat gambar yang diunduh dari web semakin sering berupa WebP, cukup mengejutkan jika Anda belum pernah menjumpainya

  • Jika perangkat Android sudah berstatus akhir dukungan, apakah itu berarti saat ini perangkat tersebut benar-benar terekspos pada eksploit 0-klik yang beredar di dunia nyata? Atau apakah dengan memperbarui aplikasi SMS, Chrome, WhatsApp, Signal, dan sejenisnya saja jalur input utama sudah cukup tertutup?

    • Belum pasti apakah eksploit Android untuk bug ini sudah ada. Eksploit aslinya ditujukan untuk iOS lewat iMessage, tetapi kemungkinan besar sudah dikembangkan. Permintaan untuk eksploit semacam ini di Android belakangan sangat tinggi, dan saya dengar baru-baru ini ada harga yang disebutkan dengan angka yang tidak masuk akal.
      Pada perangkat yang sudah tidak didukung, memperbarui Chrome memang memperbaiki masalah di Chrome, tetapi untuk memperbaiki aplikasi seperti Signal atau WhatsApp diperlukan upgrade OS Android. Chrome membundel libwebp-nya sendiri, tetapi aplikasi dengan paparan tinggi seperti aplikasi pesan dan Gmail menggunakan antarmuka yang disediakan OS untuk menampilkan gambar. Untuk perangkat Android yang masih mendapat dukungan keamanan, diharapkan pembaruan mulai keluar pada awal Oktober.
    • Library decoding gambar milik platform semestinya menjadi salah satu modul sistem yang diperbarui melalui Play Store. Saya penasaran apakah ada yang bisa memastikan apakah kenyataannya memang begitu.
    • Sebagian aplikasi pesan punya opsi untuk tidak mengunduh otomatis atau tidak menampilkan pratinjau gambar yang diterima, jadi mengaktifkan pengaturan itu bisa menjadi langkah yang baik. Google Messages punya fitur ini.
    • Kalau Android sudah keluar dari cakupan pembaruan keamanan, bukan hanya hal ini yang perlu dikhawatirkan. Saya mungkin akan lebih dulu mengkhawatirkan hal-hal lain yang lebih mudah dieksploitasi.
    • Di iOS, ini menjadi masalah sangat besar khususnya karena iMessage memiliki hak istimewa tinggi. Di Android, semua aplikasi seperti itu berada di dalam sandbox.

  • Pernyataan bahwa “ada banyak input yang benar-benar membuat huffman_tables overflow” tampak seperti masalah yang lebih umum. Strukturnya adalah perangkat lunak A membuat tabel lookup B, lalu tabel itu dipakai untuk memproses stream data input.
    Sekarang, pengembang yang sedikit saja peduli pada keamanan atau akurasi harus menjamin salah satu dari dua hal. A) perangkat lunaknya ditulis sedemikian rupa sehingga data input apa pun tidak dapat menyalahgunakan atau membuat tabel lookup gagal, atau B) penggunaannya hanya dalam lingkungan terkendali, misalnya komunikasi titik-ke-titik ketika kedua pihak komunikasi sama-sama tepercaya, sehingga ada jaminan bahwa stream tidak akan pernah menyalahgunakan tabel lookup atau menyebabkan anomali.
    B hampir mustahil kecuali untuk kelompok kecil atau kantor, dan benar-benar mustahil pada skala internet, jadi pada akhirnya yang tersisa hanya A. Praktik terbaik yang lebih umum dalam rekayasa perangkat lunak ke depan adalah: jika memakai tabel lookup untuk alasan apa pun, pengembang harus menjamin bahwa tabel itu bekerja dengan benar untuk semua jenis data, atau mendeteksi data yang salah sebelum mencapai tabel dan menanganinya dengan semestinya.
    Kalau saya peneliti keamanan yang serius dan punya waktu, saya mungkin akan mengumpulkan daftar semua kerentanan keamanan di masa lalu yang dengan cara apa pun terkait tabel lookup, lalu membacanya satu per satu dan membandingkan kesamaannya. Kemungkinan besar ada polanya. Setelah itu saya akan menelusuri semua perangkat lunak yang menggunakan tabel lookup untuk stream data dan mengaudit kerentanannya, tetapi ini bukan pekerjaan yang bisa dilakukan satu orang seumur hidup; ini olahraga tim.

  • Seberapa besar publikasi kode sumber membantu NSO menemukan bug ini? Saya penasaran, kalau kodenya hanya berupa blob biner, apakah decompiler modern saja sudah cukup untuk memahami kode dan menemukan bug yang sedemikian pelik ini.

    • Blob tidak menghentikan penyerang. Untuk menulis eksploit yang berhasil, pada akhirnya tetap harus memahami biner terkompilasi.

  • Yang mengejutkan adalah ini bukan bagian “baru” dari format gambar. Kompresi Huffman sudah ada lebih dari 70 tahun, canonical Huffman juga hanya beberapa dekade lebih muda dari itu, dan JPEG pun memakai Huffman. Ini teknologi yang sudah berusia puluhan tahun dan ada tak terhitung banyaknya tulisan tentang cara mengimplementasikannya, jadi rasanya ini teknologi yang bug-nya seharusnya sudah dibereskan di berbagai implementasi.
    Dulu saya pernah membaca spesifikasi JPEG dan juga menulis decoder, jadi saya melihat spesifikasi WebP: https://developers.google.com/speed/webp/docs/webp_lossless_...
    Bagian pentingnya ada di bagian 6. Hal pertama yang mencolok adalah, tidak seperti spesifikasi JPEG, penjelasan tentang bagaimana kode disusun tidak jelas. JPEG punya banyak flowchart yang mudah dibaca tentang prosesnya. WebP tampak mirip LZH/deflate(zlib), dan lebih terasa seperti kumpulan beberapa potongan kode sumber yang diberi penjelasan daripada sebuah “spesifikasi”.
    Setelah GIF, JPEG, dan PNG, saya sempat berpikir untuk mencoba menulis decoder WebP juga, tetapi melihat “spesifikasi” di atas saja rasanya seperti hampir menyuruh orang untuk tidak menulisnya.

    • Saya setuju spesifikasinya sangat kekurangan contoh, tetapi di situ disebutkan bahwa karena menggunakan canonical Huffman tree, cukup mengirimkan panjang kode saja. Menurut saya itu cukup jelas untuk menentukan tree yang sebenarnya. Rasanya tidak ada implementasi canonical Huffman yang memakai urutan leksikografis terbalik.
      Implementasi Huffman tree memiliki banyak trade-off yang berbeda-beda, jadi sulit mengatakan bahwa karena teknologinya sudah lama maka semua bug-nya sudah beres. Charles Bloom pernah mengatakan bahwa makalah definitif tahun 1997 tentang optimasi Huffman [1] pun hingga 2010 masih belum dikenal luas, dan banyak optimasi ditemukan ulang lalu dilupakan. Jadi kemungkinan besar ada banyak implementasi yang tidak efisien.
      [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
    • Kalau butuh kode untuk referensi, ada decoder WebP-Lossless di https://github.com/golang/image/tree/master/vp8l dengan kurang dari 1200 baris.

  • Sekarang rasanya bahkan melihat gambar pun tidak bisa dilakukan tanpa kekhawatiran keamanan.

    • Jika vendor perangkat lunak memakai library yang sedikit lebih lambat saat merender gambar, kekhawatiran keamanan paling serius, yaitu eksekusi kode jarak jauh, bisa dihindari. Dengan menghindari library yang ditulis dalam C, eksekusi kode jarak jauh hampir bisa dihilangkan dan pengguna pun menjadi lebih aman.
    • Mungkin ingatan saya keliru, tetapi rasanya hal serupa pernah terjadi setidaknya sekali juga pada PNG dan JPG.
      Ini terdengar seperti growing pain klasik akibat penggunaan C, bahasa yang tidak aman. Saya paham mengapa C menarik karena kecepatan browser, tetapi saya berharap industri bisa berhenti dari pola yang mendorong kesalahan sama yang terus berulang sejak mulai menggunakan C.
      Rasanya seperti membangun jembatan dengan sekrup self-tapping alih-alih paku keling karena lebih cepat. Ketika jembatannya mulai melendut, solusinya tinggal memasang lebih banyak sekrup.

  • “Kabar baiknya, Apple dan Chrome merespons dengan sangat baik sesuai urgensi masalah ini” — sulit untuk menerimanya. Yang mengklasifikasikan masalah ini sebagai khusus Chrome adalah Google. Melihat 7 hari terakhir saja, semua distribusi Linux besar harus mendorong pembaruan, dan Red Hat memberi skor 9,6. Python Docker image yang sudah di-pull lebih dari 1 miliar kali, Puppeteer, WordPress, Node.js, dan lainnya juga terdampak, tetapi CRBug masih tertutup untuk publik
    Situs seperti BleepingComputer memberitakan apa yang terlihat tanpa investigasi, begitu pula banyak perusahaan keamanan yang memperlakukan isu ini seperti pihak ketiga. Kalau tahu pihak lawan tidak melakukan due diligence, sangat sulit membangun kepercayaan
    Adam Caudill menulis artikel bagus berjudul “Whose CVE is it anyway?”[0], disertai contoh 1Password yang melakukan patch sejak awal, dan tulisannya dengan tepat menyoroti masalah yang dibahas di sini. Citizen Lab menolak menjawab apakah kedua isu itu terkait, tetapi ada hal-hal yang terlihat tanpa perlu menjadi genius
    [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/

    • Alasan Apple dan Chrome sangat penting di sini adalah karena merekalah target eksploitasi yang benar-benar terjadi di alam liar, dan mereka memiliki permukaan serangan langsung dengan jumlah pengguna terbesar
      Penulis juga mengatakan banyak sistem lain harus di-patch. Namun, dari Python Docker image yang di-pull 1 miliar kali itu, berapa banyak yang merender gambar WebP yang tidak tepercaya? Hal yang sama berlaku untuk Node dan lainnya. Tentu saja harus segera di-patch, tetapi tingkatnya tidak sama dengan iOS/Android/Chrome

  • Ratusan juta orang di seluruh dunia terdampak oleh library ini, dan dampaknya berlipat-lipat untuk setiap perangkat dan aplikasi yang mereka gunakan
    Saya suka C, tetapi menurut saya library yang digunakan ratusan juta orang di seluruh dunia seharusnya tidak memakai C. Rasio risikonya terlalu tinggi untuk library inti seperti ini. Bahkan pakar C pun suatu saat akan melakukan kesalahan
    Sepertinya ini perbaikannya https://github.com/webmproject/libwebp/commit/dce8397fec159c...
    “malloc fail” — bikin frustrasi. Slack, Discord, Teams, sampai semua OS modern ikut terdampak

    • Perbaikan sebenarnya ada di sini: https://github.com/webmproject/libwebp/commit/902bc919033134...
    • Saya sependapat. Rust harus menjadi C yang baru. Hanya karena seseorang bisa menulis kode dalam C, bukan berarti boleh memproduksi kode kompleks secara massal dengan alasan seperti “performa”, “portabilitas”, dan “kompatibilitas legacy”
      C/C++ dan bahasa dinamis memperbesar permukaan perilaku tak terdefinisi dan bug halus, serta sulit dan membebani bahkan bagi developer paling cerdas untuk di-lint. Library dasar seharusnya diverifikasi secara formal dengan cara yang mirip seL4
      Masalah lain adalah kurangnya profesionalisme yang tersebar luas di seluruh FOSS, serta pengabaian terhadap ketelitian, kualitas, akurasi, dan keamanan. Cara seperti sekarang, membangun imperium di atas pasir, adalah tindakan bodoh
    • Baik di sini maupun di commit yang berdekatan, tidak ada satu pun pengujian. Tidak masuk akal