WorstFit: Pengungkapan Transformer Tersembunyi di Windows ANSI

 (blog.orange.tw)
2 poin oleh GN⁺ 2025-01-10 | 1 komentar | Bagikan ke WhatsApp

WorstFit: Pengungkapan Transformer Tersembunyi di Windows ANSI

TL;DR

  • Menemukan permukaan serangan baru dengan mengeksploitasi Best-Fit, fitur transformasi set karakter internal Windows.
  • Mengubah fitur ini menjadi eksploitasi praktis seperti path traversal, penyuntikan argumen, dan eksekusi kode jarak jauh (RCE).
  • Akar masalahnya terletak pada perilaku compiler, runtime C/C++, dan kesalahan pengembang.
  • Juga dibahas tantangan dalam menerapkan patch di ekosistem open-source.

Menjelaskan Encoding Windows

Masa Awal: ANSI dan Code Page

  • Windows awalnya menggunakan encoding ANSI, yang efektif untuk bahasa tertentu tetapi tidak dapat menangani kumpulan karakter campuran.
  • Terdapat berbagai code page, dan tiap code page mendukung bahasa tertentu.

Era Unicode: UTF-16

  • Pada pertengahan 1990-an, Windows beralih ke Unicode agar hampir semua karakter semua bahasa dapat diwakili dalam satu standar.
  • Awalnya menggunakan UCS-2, tetapi kemudian langsung ditingkatkan ke UTF-16.

Era Enkode Ganda

  • Untuk mempertahankan dukungan code page ANSI lama, Windows mengimplementasikan dua versi API.
  • Terdapat ANSI API dan Unicode API, sehingga pengembang bisa dengan mudah memperoleh format data yang diinginkan.

Kelebihan Best-Fit

  • Konversi karakter Best-Fit di Windows adalah cara menangani karakter yang tidak ada di code page target saat mengonversi dari UTF-16 ke ANSI.
  • Misalnya, simbol ∞ tidak ada di code page Windows-1252, sehingga Microsoft memetakannya ke 8.

WorstFit: Permukaan Serangan Baru di Windows

🔥 Mimpi Buruk Dunia Timur Jauh - CVE-2024-4577

  • CVE-2024-4577 adalah kerentanan yang memungkinkan eksploitasi pada server PHP-CGI yang menggunakan code page Cina atau Jepang dengan permintaan sederhana ?%ADs.
  • Karena perilaku Best-Fit, U+00AD (soft hyphen) dipetakan ke dash (-), memungkinkan bypass.

🔥 Pengambilalihan Nama File

  • Melalui pemrosesan nama file, WorstFit dapat dieksploitasi menjadi payload path traversal.
  • Misalnya, Developer Shell Chrome V8 (d8.exe) mengambil direktori kerja saat ini menggunakan ANSI API.

🔥 Pemisahan Argumen

  • Memanipulasi output GetCommandLineA memungkinkan perilaku WorstFit dimanfaatkan pada parsing command line.
  • Sebagai contoh, masukan ＂ --use-askpass=calc ＂ dapat mengeksekusi calc.exe pada sistem.

Kesimpulan

  • Perilaku Best-Fit menyediakan permukaan serangan pada proses transformasi di level sistem, yang dapat menyebabkan kerentanan pada berbagai alat.
  • Fungsi dari library standar atau bahasa pemrograman tidak dapat mencegah serangan ini secara menyeluruh.

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-10
Hacker News Komentar

  • Microsoft sudah mengetahui masalah ini setidaknya sejak lebih dari satu tahun lalu. Melalui aturan analisis kode khusus bernama CA2101, Microsoft tidak merekomendasikan penggunaan pemetaan best-fit. Mereka menyebut adanya kerentanan keamanan, tetapi rinciannya tidak jelas

  • Ini adalah masalah sistemik. Microsoft menyediakan pemetaan kode "best fit" yang mengonversi Unicode menjadi ASCII. Pemetaan ini digunakan di banyak tempat, dan karena Microsoft sangat mementingkan kompatibilitas mundur, pemetaan ini perlu tetap disertakan. Pada dasarnya ini terhubung ke mana-mana

    • Sering dieksploitasi untuk mengonversi titik kode tidak valid menjadi slash, tanda hubung, tanda kutip, dan sebagainya. Di bahasa pemrograman modern biasanya dievaluasi dengan benar, tetapi bermasalah saat dikirim ke perintah shell atau Win32 API

    • Pemelihara curl mengatakan bahwa "curl adalah korban", tetapi penyebab masalahnya ada di tempat lain. Masalah terjadi ketika validasi input pengguna di server dan saat diterapkan ke pustaka sistem diperlakukan secara berbeda

    • Menonaktifkan konversi "best fit" secara selektif di ruang lingkup Win32 bisa menjadi solusi. Penyedia open source dapat menambahkan ini sebagai praktik terbaik

  • Windows seperti game kartu Munchkin di mana berbagai fitur yang kebetulan saling terhubung dapat menghasilkan kerentanan yang kuat. Mengonversi subsystem ANSI ke UTF-8 dapat meringankan masalah ini

  • Microsoft secara bertahap meninggalkan ANSI sejak NT 3.5 dan mendorong penggunaan Wide Character API. Namun, implementasi pustaka runtime C/C++ Microsoft adalah hambatan utama

    • Fungsi standar menggunakan fungsi A dan tidak melaporkan kegagalan konversi Unicode, melainkan menggunakan pendekatan best-fit

  • Kemungkinan Microsoft mengaktifkan UTF-8 secara default di semua edisi Windows kemungkinan kecil. Karena aplikasi lama bergantung pada code page tertentu atau karakter 1-byte

    • Menghapus logika Best-Fit dari API win32 xxxA kemungkinan akan menimbulkan lebih sedikit masalah

  • Ada dua cara untuk memaksa halaman kode "Ansi" menjadi UTF-8 pada aplikasi. Salah satunya memakai berkas Manifest, dan yang lain menggunakan alat "App Locale"

  • Di komputer pribadi Windows saya, mengatur mode UTF-8 membuat saya aman dari bug ini. Saya mengaktifkannya karena game asing lama menampilkan teks yang rusak

  • Masalah ini tidak akan terselesaikan hanya dengan mengganti main() ke versi wide-character. Semua variabel harus diubah menjadi wchar_t *, yang sangat merepotkan dan mudah menimbulkan bug

    • Sebagai gantinya, Anda bisa mengonversi wide characters yang diterima ke UTF-8 dan tetap memakai "char". Pastikan tidak mencampur string ANSI atau OEMCP dengan string UTF-8

  • Saya tahu bahwa Windows API menyediakan konversi best-fit, tetapi tidak tahu bahwa ini adalah perilaku default. Fitur ini seharusnya dilarang

  • Saya penasaran apakah kotak centang beta ini sama dengan mengatur ActiveCodePage ke UTF-8. GDI mengikuti code page global, bukan code page per-proses. Sayang sekali tidak bisa sepenuhnya memilih UTF-8