Google telah menerbitkan beberapa prototipe eksploitasi yang menunjukkan kemungkinan mengeksploitasi kerentanan kelas Spectre saat mengeksekusi kode JavaScript di browser, melewati metode perlindungan yang ditambahkan sebelumnya. Eksploitasi dapat digunakan untuk mendapatkan akses ke memori proses yang memproses konten web di tab saat ini. Untuk menguji pengoperasian eksploitasi, situs leaky.page diluncurkan, dan kode yang menjelaskan logika pekerjaan diposting di GitHub.
Prototipe yang diusulkan dirancang untuk menyerang sistem dengan prosesor Intel Core i7-6500U di lingkungan Linux dan Chrome 88. Perubahan diperlukan untuk menerapkan eksploitasi ke lingkungan lain. Metode eksploitasi tidak spesifik untuk prosesor Intel - setelah adaptasi yang sesuai, eksploitasi tersebut dipastikan bekerja pada sistem dengan CPU dari produsen lain, termasuk Apple M1 berdasarkan arsitektur ARM. Setelah sedikit penyesuaian, eksploitasi juga berfungsi pada sistem operasi lain dan browser lain yang berbasis mesin Chromium.
Dalam lingkungan yang didasarkan pada prosesor Chrome 88 dan Intel Skylake standar, data bocor dari proses yang bertanggung jawab untuk memproses konten web di tab Chrome saat ini (proses perender), dengan kecepatan 1 kilobyte per detik. Selain itu, prototipe alternatif dikembangkan, misalnya, eksploitasi yang memungkinkan, dengan mengorbankan stabilitas, meningkatkan laju kebocoran hingga 8kB/s saat menggunakan pengatur waktu performance.now() dengan akurasi 5 mikrodetik (0.005 milidetik) . Sebuah varian juga telah disiapkan, bekerja dengan pengatur waktu dengan akurasi satu milidetik, yang dapat digunakan untuk mengatur akses ke memori proses lain dengan kecepatan sekitar 60 byte per detik.
Kode demo yang dipublikasikan terdiri dari tiga bagian. Bagian pertama mengkalibrasi pengatur waktu untuk memperkirakan waktu eksekusi operasi yang diperlukan untuk memulihkan data yang tersisa di cache prosesor sebagai akibat dari eksekusi instruksi CPU yang spekulatif. Bagian kedua menentukan tata letak memori yang digunakan saat mengalokasikan array JavaScript.
Bagian ketiga secara langsung mengeksploitasi kerentanan Spectre untuk menentukan isi memori dari proses saat ini sebagai akibat dari penciptaan kondisi untuk eksekusi spekulatif dari operasi tertentu, yang hasilnya dibuang oleh prosesor setelah menentukan prediksi yang gagal, tetapi eksekusi jejak disimpan dalam cache umum dan dapat dipulihkan menggunakan metode untuk menentukan konten cache melalui saluran pihak ketiga yang menganalisis perubahan waktu akses ke data yang di-cache dan non-cache.
Teknik eksploitasi yang diusulkan menghilangkan pengatur waktu presisi tinggi yang tersedia melalui API performance.now(), dan tanpa dukungan untuk tipe SharedArrayBuffer, yang memungkinkan pembuatan array di memori bersama. Eksploitasinya mencakup gadget Spectre, yang menyebabkan eksekusi kode spekulatif terkontrol, dan penganalisis kebocoran saluran samping, yang menentukan data yang diperoleh selama eksekusi spekulatif yang masuk ke dalam cache.
Gadget diimplementasikan menggunakan array JavaScript, di mana upaya dilakukan untuk mengakses area di luar batas buffer, yang memengaruhi status blok prediksi cabang karena pemeriksaan ukuran buffer yang ditambahkan oleh kompiler (prosesor, melihat ke depan , secara spekulatif melakukan akses, tetapi mengembalikan status setelah pemeriksaan). Untuk menganalisis isi cache dalam kondisi akurasi pengatur waktu yang tidak mencukupi, sebuah metode diusulkan yang menipu strategi penggusuran cache Tree-PLRU yang digunakan dalam prosesor dan memungkinkan, dengan meningkatkan jumlah siklus, untuk secara signifikan meningkatkan perbedaan waktu saat mengembalikan a nilai dari cache dan ketika tidak ada nilai dalam cache.
Perlu dicatat bahwa Google menerbitkan prototipe eksploitasi untuk menunjukkan realisme serangan menggunakan kerentanan kelas Spectre dan untuk mendorong pengembang web menggunakan teknik yang meminimalkan risiko serangan tersebut. Pada saat yang sama, Google percaya bahwa tanpa revisi signifikan terhadap prototipe yang diusulkan, mustahil menciptakan eksploitasi universal yang siap tidak hanya untuk demonstrasi, tetapi juga untuk penggunaan luas.
Untuk memitigasi risiko, pemilik situs didorong untuk menggunakan Kebijakan Pembuka Lintas Asal (COOP), Kebijakan Penyematan Lintas Asal (COEP), Kebijakan Sumber Daya Lintas Asal (CORP) yang baru diterapkan, Permintaan Metadata Pengambilan, Opsi X-Frame, X -Opsi Tipe Konten dan Cookie Situs yang Sama. Mekanisme ini tidak secara langsung melindungi terhadap serangan, namun memungkinkan isolasi data situs dari kebocoran ke dalam proses di mana kode JavaScript penyerang dapat dieksekusi (kebocoran terjadi dari memori proses saat ini, di mana, selain kode penyerang, data dari situs lain yang dibuka di tab yang sama). Ide utamanya adalah untuk memisahkan eksekusi kode situs dalam berbagai proses dari kode pihak ketiga yang diperoleh dari sumber yang tidak dapat diandalkan, misalnya, disertakan melalui iframe.
Sumber: opennet.ru