Breaking

Sunday, November 22, 2020

Fuzzilli - Sebuah Fuzzer Mesin JavaScript

 Kang IT

Fuzzilli - Sebuah Fuzzer Mesin JavaScript


Fuzzer terpandu (cakupan-) untuk penerjemah bahasa dinamis berdasarkan bahasa perantara kustom ("FuzzIL") yang dapat dimutasi dan diterjemahkan ke JavaScript.




Pemakaian

Langkah-langkah dasar untuk menggunakan fuzzer ini adalah:

  1. Unduh kode sumber untuk salah satu mesin JavaScript yang didukung. Lihat direktori Target / untuk daftar mesin JavaScript yang didukung.
  2. Terapkan patch yang sesuai dari direktori target. Juga lihat README.md di direktori itu.
  3. Kompilasi mesin dengan instrumentasi cakupan (membutuhkan clang> = 4.0) seperti yang dijelaskan dalam README.
  4. Kompilasi fuzzer: swift build [-c release].
  5. Jalankan fuzzer: swift run [-c release] FuzzilliCli --profile=<profile> [other cli options] /path/to/jsshellLihat juga swift run FuzzilliCli --help.

Membangun dan menjalankan Fuzzilli dan mesin JavaScript yang didukung di dalam Docker dan di Google Compute Engine juga didukung .


Peretasan

Lihat main.swift untuk melihat contoh penggunaan pustaka Fuzzilli dan bermainlah dengan berbagai opsi konfigurasi. Selanjutnya, lihat Fuzzer.swift untuk logika fuzzing tingkat tinggi. Dari sana selami bagian mana saja yang tampaknya menarik.

Tambalan, tambahan, kontribusi lain, dll. Ke proyek ini sangat disambut baik! Namun, segera periksa catatan kontributornya . Fuzzilli secara kasar mengikuti panduan gaya kode Google untuk cepat .

Ini akan lebih dihargai jika Anda bisa mengirim catatan singkat (mungkin termasuk sejumlah CVE) ke saelo@google.com atau membuka permintaan tarik untuk setiap kerentanan yang ditemukan dengan bantuan proyek ini sehingga dapat dimasukkan dalam bug showcase bagian . Selain itu tentu saja Anda dapat mengklaim bug bounty, kredit CVE, dll. Untuk kerentanan :)


Konsep

Saat melakukan fuzzing untuk bug interpreter inti, misalnya di kompiler JIT, ketepatan semantik program yang dihasilkan menjadi perhatian. Hal ini berbeda dengan kebanyakan skenario lainnya, misalnya fuzzing API runtime, di mana kebenaran semantik dapat dengan mudah diatasi dengan menggabungkan kode yang dihasilkan dalam konstruksi coba-tangkap. Ada kemungkinan yang berbeda untuk mencapai tingkat yang dapat diterima dari sampel yang benar secara semantik, salah satunya adalah pendekatan mutasi di mana semua sampel dalam korpus juga valid secara semantik. Dalam hal ini, setiap mutasi hanya memiliki peluang kecil untuk mengubah sampel yang valid menjadi sampel yang tidak valid.

Untuk menerapkan fuzzer JavaScript berbasis mutasi, mutasi pada kode JavaScript harus ditentukan. Alih-alih memutasi AST, atau elemen sintaksis lain dari sebuah program, bahasa perantara kustom (IL) didefinisikan di mana mutasi ke kontrol dan aliran data program dapat lebih langsung dilakukan. IL ini kemudian diterjemahkan ke JavaScript untuk dieksekusi. Bahasa perantara terlihat secara kasar sebagai berikut:

v0 <− LoadInteger '0'
v1 <− LoadInteger '10'
v2 <− LoadInteger '1'
v3 <− LoadInteger '0'
BeginFor v0, '<', v1, '+', v2 −> v4
v6 <− BinaryOperation v3, '+', v4
Reassign v3, v6
EndFor
v7 <− LoadString 'Result: '
v8 <− BinaryOperation v7, '+', v3
v9 <− LoadGlobal 'console'
v10 <− CallMethod v9, 'log', [v8]

Yang dapat diterjemahkan dengan mudah ke kode JavaScript berikut:

const v0 = 0;
const v1 = 10;
const v2 = 1;
let v3 = 0;
for (let v4 = v0; v4 < v1; v4 = v4 + v2) {
const v6 = v3 + v4;
v3 = v6;
}
const v7 = "Result: ";
const v8 = v7 + v3;
const v9 = console;
const v10 = v9.log(v8);

Atau ke kode JavaScript berikut dengan menyebariskan ekspresi perantara:

let v3 = 0;
for (let v4 = 0; v4 < 10; v4++) {
v3 = v3 + v4;
}
console.log("Result: " + v3);

FuzzIL memiliki sejumlah properti:

  • Program FuzzIL hanyalah daftar instruksi.
  • Instruksi FuzzIL adalah sebuah operasi bersama dengan variabel input dan output dan kemungkinan satu atau lebih parameter (diapit tanda kutip tunggal pada notasi di atas).
  • Masukan ke instruksi selalu berupa variabel, tidak ada nilai langsung.
  • Setiap keluaran dari sebuah instruksi adalah sebuah variabel baru, dan variabel yang sudah ada hanya dapat ditetapkan kembali melalui operasi khusus seperti Reassigninstruksi.
  • Setiap variabel ditentukan sebelum digunakan.

Sejumlah mutasi kemudian dapat dilakukan pada program-program ini:

  • InputMutator : mengganti variabel input instruksi dengan yang berbeda untuk memutasi aliran data program.
  • CodeGenMutator : menghasilkan kode dan memasukkannya ke suatu tempat di program yang dimutasi. Kode dihasilkan baik dengan menjalankan generator kode atau dengan menyalin beberapa instruksi dari program lain di korpus (penyambungan).
  • CombineMutator : menyisipkan program dari korpus ke posisi acak dalam program yang bermutasi.
  • OperationMutator : mengubah parameter operasi, misalnya mengganti konstanta integer dengan yang berbeda.
  • dan banyak lagi ...


Penerapan

Fuzzer diimplementasikan di Swift , dengan beberapa bagian (misalnya pengukuran cakupan, interaksi soket, dll.) Diimplementasikan di C.


Arsitektur

Instance fuzzer (diimplementasikan di Fuzzer.swift ) terdiri dari komponen utama berikut:

  • MutationFuzzer : menghasilkan program baru dari yang sudah ada dengan menerapkan mutasi . Setelah itu mengeksekusi sampel yang dihasilkan dan mengevaluasinya.
  • ScriptRunner : menjalankan program dari bahasa target.
  • Corpus : menyimpan sampel yang menarik dan memasoknya ke fuzzer inti.
  • Lingkungan : memiliki pengetahuan tentang lingkungan runtime, misalnya bawaan yang tersedia, nama properti, dan metode.
  • Minimizer : meminimalkan program yang mogok dan menarik.
  • Evaluator : mengevaluasi apakah sampel menarik menurut beberapa metrik, misalnya cakupan kode.
  • Lifter : menerjemahkan program FuzzIL ke bahasa target (JavaScript).

Selain itu, sejumlah modul tersedia secara opsional:

Fuzzer digerakkan oleh peristiwa, dengan sebagian besar interaksi antara kelas yang berbeda terjadi melalui peristiwa. Peristiwa dikirim misalnya sebagai akibat dari crash atau ditemukannya program yang menarik, program baru sedang dijalankan, pesan log yang dihasilkan, dan sebagainya. Lihat Events.swift untuk daftar lengkap acara. Mekanisme peristiwa secara efektif memisahkan berbagai komponen fuzzer dan memudahkan penerapan modul tambahan.

Program FuzzIL dapat dibuat menggunakan instance ProgramBuilder . ProgramBuilder menyediakan metode untuk membuat dan menambahkan instruksi baru, menambahkan instruksi dari program lain, mengambil variabel yang ada, menanyakan konteks eksekusi pada posisi saat ini (misalnya apakah itu di dalam loop), dan banyak lagi.


Eksekusi

Fuzzilli menggunakan mode eksekusi kustom yang disebut REPRL (read-eval-print-reset-loop) . Untuk itu, mesin target dimodifikasi untuk menerima input skrip melalui pipa dan / atau memori bersama, mengeksekusinya, lalu menyetel ulang status internalnya dan menunggu skrip berikutnya. Ini menghilangkan overhead dari pembuatan proses dan sebagian besar dari mesin ininisialisasi.


Skalabilitas

Ada satu instance Fuzzer per proses target. Hal ini memungkinkan eksekusi program yang sinkron dan dengan demikian menyederhanakan implementasi berbagai algoritma seperti mutasi dan minimisasi yang berurutan. Selain itu, ini menghindari kebutuhan untuk mengimplementasikan akses aman-thread ke status internal, misalnya korpus. Setiap instance fuzzer memiliki DispatchQueue -nya sendiri , yang secara konseptual sesuai dengan satu utas. Sebagai aturan praktis, setiap interaksi dengan instance Fuzzer harus terjadi di antrean pengiriman instance tersebut. Ini menjamin keamanan thread karena antriannya serial. Untuk lebih jelasnya lihat dokumen .

Untuk menskalakan, instance fuzzer dapat menjadi pekerja, dalam hal ini mereka melaporkan sampel menarik yang baru ditemukan dan error ke instance master. Pada gilirannya, instance master juga menyinkronkan korpusnya dengan pekerja. Komunikasi antara master dan pekerja dapat terjadi dengan cara yang berbeda, masing-masing diimplementasikan sebagai modul:

  • Komunikasi antar utas : menyinkronkan contoh dalam proses yang sama dengan mengantrekan tugas ke DispatchQueue fuzzer lain.
  • Komunikasi antar proses (TODO): menyinkronkan contoh melalui saluran IPC.
  • Komunikasi antar mesin : menyinkronkan contoh melalui protokol berbasis TCP sederhana.

Desain ini memungkinkan fuzzer untuk menskalakan banyak inti pada satu mesin dan juga ke banyak mesin yang berbeda. Karena satu instans master dapat dengan cepat kelebihan beban jika terlalu banyak pekerja yang mengirim program ke sana, maka dimungkinkan juga untuk mengonfigurasi beberapa tingkatan instans master, misalnya satu instans master, 16 master perantara yang terhubung ke master, dan 256 pekerja yang terhubung ke master perantara .


Sumber daya

Sumber daya lebih lanjut tentang fuzzer ini:

  • Sebuah presentasi tentang Fuzzilli diberikan pada Serangan Con 2019.
  • The tesis master yang pelaksanaan awal dilakukan.
  • Sebuah posting blog oleh Sensepost tentang menggunakan Fuzzilli untuk menemukan bug di v8
  • Sebuah posting blog oleh Doyensec tentang fuzzing mesin JerryScript dengan Fuzzilli


Etalase Bug

Berikut ini adalah daftar dari beberapa bug yang ditemukan dengan bantuan Fuzzilli. Hanya bug dengan dampak keamanan yang disertakan dalam daftar. Terima kasih khusus kepada semua pengguna Fuzzilli yang telah melaporkan bug yang ditemukan olehnya!


WebKit / JavaScriptCore

  • Masalah 185328 : Penyusun DFG menggunakan daftar keluaran yang salah untuk operasi NumberIsInteger
  • CVE-2018-4299 : performProxyCall membocorkan objek internal ke skrip
  • CVE-2018-4359 : compileMathIC menghasilkan kode mesin yang salah
  • CVE-2019-8518 : Akses OOB di FTL JIT karena akses array bergerak LICM sebelum pemeriksaan batas
  • CVE-2019-8558 : CodeBlock UaF karena Watchpoints yang menggantung
  • CVE-2019-8611 : Pengoptimalan AIR salah menghapus tugas untuk mendaftar
  • CVE-2019-8623 : Gerakan kode invarian-loop (LICM) di DFG JIT membuat variabel tumpukan tidak diinisialisasi
  • CVE-2019-8622 : DFG's doesGC () salah tentang perilaku operasi HasIndexedProperty di StringObjects
  • CVE-2019-8671 : DFG: Gerakan kode invarian-loop (LICM) membuat akses properti objek tidak dijaga
  • CVE-2019-8672 : JSValue digunakan setelah bebas di ValueProfiles
  • CVE-2019-8678 : JSC gagal menjalankan hasABadTime () ketika beberapa prototipe dimodifikasi, menyebabkan kebingungan jenis
  • CVE-2019-8685 : JSPropertyNameEnumerator menggunakan ID struktur yang salah
  • CVE-2019-8765 : Kebingungan jenis GetterSetter selama kompilasi DFG
  • CVE-2019-8820 : Ketik kebingungan selama bailout saat merekonstruksi objek argumen
  • CVE-2020-3901 : Kebingungan jenis GetterSetter dalam kode JIT FTL (karena LICM tidak selalu aman)


Tokek / Spidermonkey

  • CVE-2018-12386 : Bug alokasi register IonMonkey menyebabkan kebingungan jenis
  • CVE-2019-9791 : Inferensi jenis IonMonkey salah untuk konstruktor yang dimasukkan melalui OSR
  • CVE-2019-9792 : IonMonkey membocorkan nilai ajaib JS_OPTIMIZED_OUT ke skrip
  • CVE-2019-9816 : ObjectGroup tak terduga dalam operasi ObjectGroupDispatch
  • CVE-2019-9813 : Kode yang dikompilasi IonMonkey gagal memperbarui tipe properti yang disimpulkan, menyebabkan kebingungan tipe
  • CVE-2019-11707 : IonMonkey salah memprediksi jenis kembalian Array.prototype.pop, yang menyebabkan kebingungan jenis
  • CVE-2020-15656 : Ketik kebingungan untuk argumen khusus di IonMonkey


Chromium / v8


Lakban


JerryScript

  • CVE-2020-13991 : Rilis argumen sebaran yang salah
  • Masalah 3784 : Memori rusak karena pencacahan properti salah
  • CVE-2020-13623 : Stack overflow melalui kunci properti untuk objek Proxy
  • CVE-2020-13649 (1) : Memori rusak karena penanganan kesalahan dalam kasus OOM
  • CVE-2020-13649 (2) : Memori rusak karena penanganan kesalahan dalam kasus OOM
  • CVE-2020-13622 : Memori rusak karena penanganan kunci properti yang salah untuk objek Proxy
  • CVE-2020-14163 : Memori rusak karena kondisi balapan yang dipicu oleh pengumpulan sampah saat menambahkan pasangan kunci / nilai
  • Masalah 3813 : Penanganan kesalahan yang salah dalam fungsi SerializeJSONProperty
  • Masalah 3814 : Objek proxy tak terduga dalam pernyataan ecma_op_function_has_instance
  • Masalah 3836 : Memori rusak karena inisialisasi TypedArray salah
  • Masalah 3837 : Memori rusak karena penanganan memori yang salah di getOwnPropertyDescriptor


Penolakan

Ini bukan produk Google yang didukung secara resmi.




Regards

Kang IT

No comments:

Post a Comment