Fig. 1. Memar, tetapi tidak pecah. Kalkulator Windows, yang kodenya baru-baru ini diterbitkan di Github , ternyata merupakan salah satu dari dua aplikasi teruji yang tidak hang dan tidak jatuh bertentangan dengan fuzzer pesan jendela yang dikembangkan pada tahun 2000. Ukuran jendela diperbesar khusus untuk menampilkan artefak yang tidak jelas

Sudah saatnya untuk bagian kedua dari upaya kami untuk menguji teknik fuzzing kuno pada sistem modern. Jika Anda melewatkan, inilah bagian pertama . Kali ini kami akan menguji Windows 10 menggunakan teknik fuzzing dari artikel "Investigasi Empiris terhadap Keandalan Aplikasi Windows NT Menggunakan Pengujian Acak" (alias "Laporan Fuzzing NT") oleh Justin Forrester dan Barton Miller, yang diterbitkan pada tahun 2000.

Para peneliti menguji 33 aplikasi Windows NT dan versi Windows 2000 yang lebih lama untuk kerentanan terhadap pesan jendela yang terdistorsi dan kejadian mouse dan keyboard acak. Karena Dr. Miller menerbitkan kode fuzzer, kami menggunakan alat yang persis sama dengan penulis asli untuk mencari bug di aplikasi Windows modern.

Hasilnya hampir identik: 19 tahun yang lalu, 100% dari aplikasi yang diuji macet atau lumpuh ketika mereka menemukan pesan jendela yang terdistorsi. Hari ini, fuzzer yang sama menjatuhkan atau menggantung 93% aplikasi yang diuji. Hanya dua yang berdiri, termasuk Kalkulator teman lama kami (Gbr. 1). Kami juga menemukan bug (tetapi bukan masalah keamanan) di Windows.

Pengantar singkat untuk Windows

Jadi apa itu pesan jendela dan mengapa mereka menyebabkan suatu program macet?

Aplikasi Windows GUI adalah event-driven: gerakan mouse, penekanan tombol, penekanan tombol, dll. Aplikasi event-driven tidak akan melakukan apa-apa sampai menerima suatu peristiwa. Setelah suatu peristiwa diterima, aplikasi melakukan tindakan berdasarkan pada peristiwa tersebut, dan kemudian mengharapkan peristiwa lain. Terdengar akrab? Arsitektur ini telah menerima kehidupan kedua pada platform seperti node.js.

Pesan jendela adalah metode pemberitahuan acara Windows . Masing-masing dari mereka memiliki kode numerik yang terkait dengan peristiwa tertentu . Setiap pesan memiliki satu atau lebih parameter, yang oleh konvensi disebut lParam dan wParam . Mereka mendefinisikan informasi lebih rinci tentang acara tersebut. Contoh dari informasi tersebut adalah koordinat pergerakan mouse, tombol mana yang ditekan atau teks mana yang akan ditampilkan di jendela. Pesan-pesan ini dapat dikirim oleh program itu sendiri, sistem operasi, atau program lain. Mereka dapat tiba kapan saja dan dalam urutan apa pun dan harus diproses oleh aplikasi pada sisi penerima.

Implikasi keselamatan

Sebelum ke Windows Vista, proses privilege rendah dapat mengirim pesan ke proses privilege tinggi. Menggunakan kombinasi pesan yang tepat, Anda dapat mengeksekusi kode dalam proses itu. Di Vista, "serangan subversif" ini sebagian besar dilindungi oleh UIPI dan dengan mengisolasi layanan sistem dalam sesi terpisah.

Pemrosesan pesan jendela yang salah sepertinya tidak akan memengaruhi keamanan sistem Windows modern karena dua alasan. Pertama, pesan jendela tidak dapat dikirim melalui jaringan. Kedua, menghentikan aplikasi atau mengeksekusi kode pada level privilege yang sama tidak terlalu berguna bagi penyerang. Mungkin, jelas bagi penulis laporan fuzzing NT. Mereka tidak membuat pernyataan keselamatan, tetapi dengan tepat menunjukkan bahwa kegagalan dalam pemrosesan pesan jendela menyiratkan kurangnya pengujian yang ketat.

Ada beberapa area di mana mengeksekusi kode dengan hak yang sama dapat membahayakan keamanan. Beberapa aplikasi menggabungkan berbagai primitif keamanan untuk membuat tingkat hak istimewa buatan yang awalnya tidak ditemukan dalam sistem operasi. Contoh khas adalah kotak pasir untuk rendering di browser. Pembuat browser sangat menyadari masalah ini dan telah mengambil langkah untuk mengatasinya . Contoh lain adalah produk antivirus. Di sana, panel kontrol berfungsi dengan keistimewaan normal, tetapi terisolasi dari modul anti-virus lainnya.

Metodologi pengujian

Untuk fuzz semua aplikasi dalam test suite, kami menggunakan kode inti dan teknik fuzzing yang sama seperti yang dijelaskan dalam laporan NT awal. Secara khusus, dalam mode SendMessage dan PostMessage , fazzer menggunakan tiga iterasi 500.000 pesan dengan 42 biji dan tiga iterasi 500.000 pesan dengan 1.337 biji. Hasilnya muncul setelah melakukan hanya satu iterasi dari setiap metode.

Kami melewatkan input mouse dan keyboard acak karena keterbatasan waktu dan keinginan untuk fokus hanya pada pesan jendela. Kami juga mendorong mereka yang ingin mengulang pengujian dan mengkonfirmasi hasilnya.

Perangkap

Untuk fuzzer di Windows 10 harus membuat dua perubahan kecil. Pertama, sesuaikan untuk platform 64-bit. Perubahan kedua memungkinkan fuzzer untuk memilih pegangan jendela tertentu menggunakan argumen baris perintah. Menghapus descriptor tertentu adalah perbaikan cepat untuk menghilangkan aplikasi Universal Windows Platform (UWP) . Program asli difokuskan pada fuzzing windows yang termasuk dalam proses tertentu, tetapi semua aplikasi UWP menampilkan antarmuka penggunanya melalui proses yang sama (Gbr. 2). Ini berarti bahwa fuzzer tidak dapat diarahkan ke jendela aplikasi UWP utama.


Fig. 2. Pada platform UWP, semua aplikasi milik satu proses ( ApplicationFrameHost.exe ). Untuk menghapus aplikasi ini, saya harus mengubah fuzzer NT asli dan mengarahkannya ke pegangan jendela tertentu

Ada kesalahan serius dalam modifikasi fuzzer: nilai-nilai yang dipilih untuk dua sumber utama input acak, argumen lParam dan wParam untuk SendMessage dan PostMessage , terbatas pada bilangan bulat 16-bit. Kedua argumen tersebut adalah 32-bit pada Windows 32-bit dan 64-bit pada Windows 64-bit. Masalahnya terjadi pada Fuzz.cpp , di mana lParam dan wParam :

  wParam = (UINT) rand(); lParam = (LONG) rand(); 

Fungsi rand () mengembalikan angka dalam kisaran [0, 2 ¹⁶ ], yang sangat membatasi rangkaian nilai yang diuji. Kami sengaja menyimpan kesalahan ini selama pengujian sehingga hasilnya cocok secara akurat dengan karya asli.

Aplikasi yang Diuji

Dalam laporan NT asli, 33 program diuji. Kami hanya memiliki 28, karena hanya satu versi dari setiap program yang digunakan untuk pengujian. Ekosistem perangkat lunak Windows telah berubah secara signifikan sejak tahun 2000, meskipun secara mengejutkan banyak yang tidak berubah. Suite Microsoft Office berisi program yang sama seperti dalam tes asli. Netscape Communicator telah berevolusi menjadi Firefox. Adobe Acrobat telah diubah namanya menjadi Adobe Reader, tetapi masih valid. Bahkan Winamp merilis rilis baru pada tahun 2018, yang memungkinkan perbandingan yang adil dengan laporan aslinya. Namun, beberapa program usang harus diganti. Lihat di bawah untuk daftar perubahan dan alasannya:

• CD Player ⇨ Windows Media Player: Fungsi CD Player termasuk dalam program baru.
  
• Eudora ⇨ Windows Mail: Qualcomm sekarang menangani chip daripada klien email. Karena Eudora tidak ada lagi, klien email Windows default telah diuji sebagai gantinya.
  
• Command AntiVirus ⇨ Avast Free Edition: Command AntiVirus tidak lagi tersedia. Itu telah digantikan oleh Avast sebagai antivirus pihak ketiga yang paling populer.
  
• GSView ⇨ Foto: GSView tidak lagi didukung. Itu diganti dengan penampil foto Windows default.
  
• JavaWorkshop Net NetBeans IDE: JavaWorkshop IDE tidak lagi didukung. NetBeans sepertinya merupakan alternatif gratis yang bagus yang cocok dengan semangat apa yang perlu diperiksa.
  
• Secure CRT ⇨ BitVise SSH: Secure CRT masih ada, tetapi formulir web yang sangat panjang diperlukan untuk mengunduh versi uji coba. BitVise SSH menawarkan booting cepat.
  
• Telnet ⇨ Putty: Aplikasi telnet masih ada di Windows, tetapi sekarang aplikasi konsol. Untuk menghilangkan GUI, kami menggantinya dengan Putty, emulator terminal open source yang populer untuk Windows.
  
• Kami menemukan Freecell dan Solitaire di Microsoft Solitaire Collection dari katalog aplikasi Windows App Store.

Versi spesifik aplikasi ditampilkan di tabel hasil. Semua fuzzing dilakukan pada sistem 64-bit Windows 10 Pro versi 1809 (build 17763.253).

Hasil

Seperti disebutkan dalam laporan asli, hasilnya tidak boleh dilihat sebagai kerentanan keamanan, tetapi sebagai indikator keandalan dan kualitas perangkat lunak.

"Akhirnya, hasil kami membentuk titik awal kuantitatif untuk menilai peningkatan relatif dalam keandalan perangkat lunak."

- Dari "Studi Empiris Keandalan Aplikasi Windows NT Menggunakan Pengujian Acak" oleh Justin Forrester dan Barton Miller

Jumlahnya tidak terlalu menggembirakan, meskipun situasinya membaik. Dalam laporan NT awal, semua aplikasi macet atau tergantung pada fuzzing. Sekarang dua program: kalkulator dan Avast Antivirus, selamat dari pentahapan pesan jendela tanpa konsekuensi negatif. Kami memuji tim Avast dan Windows Calculator atas pendekatan mereka terhadap pesan jendela yang salah. Tim Kalkulator telah mendapatkan rasa hormat tambahan untuk membuka kode sumber dan menunjukkan cara membuat aplikasi UWP berkualitas tinggi. Lihat tabel 1 untuk semua hasil fuzzing, bersama dengan versi spesifik dari perangkat lunak yang digunakan.

Tabel 1. Hasil memainkan fuzzing asli pada Windows 10. Setelah 19 tahun, hampir semua aplikasi masih tidak benar menangani pesan jendela terdistorsi

Bug Windows?

Sayangnya, rasa ingin tahu menang, dan kami harus membuat satu pengecualian. Tampaknya beberapa aplikasi yang tidak terkait dihantam oleh satu masalah umum. Debugging menunjukkan bahwa masalahnya terkait dengan pesan WM_DEVICECHANGE . Ketika fuzzer mengirim pesan ini, bahkan aplikasi paling sederhana pun mengalami crash - HelloWorld, contoh resmi Windows API (Gbr. 3).


Fig. 3. HelloWorld.exe 32-bit macet saat menerima pesan jendela dari fuzzer. Ini seharusnya tidak terjadi, karena program ini sepenuhnya sederhana. Dipahami bahwa masalahnya ada di suatu tempat di Windows

Setelah jatuhnya HelloWorld, kami segera menyadari bahwa masalahnya hanya mempengaruhi aplikasi 32-bit, tetapi tidak pada yang 64-bit. Beberapa debugging cepat menunjukkan bahwa kerusakan terjadi di wow64win.dll, lapisan kompatibilitas aplikasi 32-bit untuk 64-bit . Analisis superfisial saya (dan mungkin salah) mengarah pada kesimpulan bahwa fungsi wow64win.dll!whcbfnINDEVICECHANGE menganggap wParam sebagai penunjuk ke struktur DEV_BROADCAST_HANDLE64 dalam program target. Fungsi mengubah struktur ini menjadi struktur DEV_BROADCAST_HANDLE32 untuk kompatibilitas dengan aplikasi 32-bit. Kegagalan terjadi karena nilai wParam dihasilkan oleh fuzzer menunjukkan memori tidak valid.

Memperlakukan wParam sebagai pointer lokal adalah ide yang buruk, meskipun itu mungkin keputusan desain yang disengaja untuk notifikasi perangkat yang dapat dilepas untuk bekerja dengan aplikasi Windows 32-bit lama. Tetapi masih salah bahwa Anda dapat merusak aplikasi lain tanpa masalah. Kami melaporkan masalah ini ke MSRC, meskipun batas keamanan tidak melewati. Mereka mengkonfirmasi bahwa kesalahan itu bukan masalah keamanan. Kami berharap dapat melihat perbaikan untuk masalah aneh yang diterima secara umum ini di versi Windows yang akan datang.

Kesimpulan

Pesan jendela diremehkan dan sering diabaikan sebagai input yang tidak dapat diandalkan untuk program Windows. Bahkan 19 tahun setelah fuzzer pertama dari pesan sumber terbuka muncul, 93% dari aplikasi yang diuji masih membeku atau lumpuh ketika program yang sama dimulai. Tetapi ini mendorong bahwa beberapa aplikasi dengan anggun mengatasi masukan yang menyimpang ini: ini berarti bahwa beberapa organisasi memiliki kerangka kerja dan pengetahuan kelembagaan untuk menghindari kesalahan tersebut.

Tentu saja, fuzzer dapat ditingkatkan dalam banyak hal, tetapi bahkan metode paling sederhana pun membuat 93% aplikasi gagal. Mungkin dalam beberapa kasus pesan jendela bahkan melewati batas keamanan nyata. Jika Anda menjelajahi area ini, kami harap Anda membagikan temuan ini.