Google telah menerbitkan beberapa prototaip eksploit yang menunjukkan kemungkinan mengeksploitasi kelemahan kelas Spectre apabila melaksanakan kod JavaScript dalam penyemak imbas, memintas kaedah perlindungan yang ditambah sebelum ini. Eksploitasi boleh digunakan untuk mendapatkan akses kepada memori proses memproses kandungan web dalam tab semasa. Untuk menguji operasi eksploitasi, tapak web leaky.page telah dilancarkan dan kod yang menerangkan logik kerja telah disiarkan pada GitHub.
Prototaip yang dicadangkan direka bentuk untuk menyerang sistem dengan pemproses Intel Core i7-6500U dalam persekitaran dengan Linux dan Chrome 88. Untuk menggunakan eksploitasi untuk persekitaran lain, pengubahsuaian diperlukan. Kaedah eksploitasi tidak khusus untuk pemproses Intel - selepas penyesuaian yang sesuai, eksploitasi itu disahkan berfungsi pada sistem dengan CPU daripada pengeluar lain, termasuk Apple M1 berdasarkan seni bina ARM. Selepas pelarasan kecil, eksploitasi juga boleh dilaksanakan dalam sistem pengendalian lain dan dalam penyemak imbas lain berdasarkan enjin Chromium.
Dalam persekitaran berdasarkan pemproses Chrome 88 dan Intel Skylake standard, data daripada proses yang bertanggungjawab untuk memproses kandungan web boleh dibocorkan dalam tab Chrome semasa (proses pemapar) pada kelajuan 1 kilobait sesaat. Selain itu, prototaip alternatif telah dibangunkan, sebagai contoh, eksploitasi yang membolehkan, dengan kos mengurangkan kestabilan, untuk meningkatkan kadar kebocoran kepada 8kB/s apabila menggunakan pemasa performance.now() dengan ketepatan 5 mikrosaat (0.005 milisaat). ). Versi juga disediakan yang berfungsi dengan ketepatan pemasa satu milisaat, yang boleh digunakan untuk mengatur akses kepada memori proses lain pada kelajuan kira-kira 60 bait sesaat.
Kod demo yang diterbitkan terdiri daripada tiga bahagian. Bahagian pertama menentukur pemasa untuk menganggarkan masa pelaksanaan operasi yang diperlukan untuk memulihkan data yang tinggal dalam cache pemproses hasil daripada pelaksanaan spekulatif arahan CPU. Bahagian kedua menentukan susun atur memori yang digunakan semasa memperuntukkan tatasusunan JavaScript.
Bahagian ketiga secara langsung mengeksploitasi kelemahan Spectre untuk menentukan kandungan memori proses semasa sebagai hasil daripada mewujudkan keadaan untuk pelaksanaan spekulatif operasi tertentu, yang hasilnya dibuang oleh pemproses selepas menentukan ramalan yang tidak berjaya, tetapi kesan daripada pelaksanaan disimpan dalam cache umum dan boleh dipulihkan menggunakan kaedah untuk menentukan kandungan cache oleh saluran pihak ketiga yang menganalisis perubahan dalam masa capaian kepada data cache dan tidak cache.
Teknik eksploitasi yang dicadangkan memungkinkan untuk dilakukan tanpa pemasa ketepatan tinggi yang tersedia melalui API performance.now() dan tanpa sokongan untuk jenis SharedArrayBuffer, yang membolehkan mencipta tatasusunan dalam memori dikongsi. Eksploitasi termasuk alat Spectre, yang menyebabkan pelaksanaan kod spekulatif terkawal, dan penganalisis kebocoran saluran sisi, yang mengesan data cache yang diperoleh semasa pelaksanaan spekulatif.
Alat ini dilaksanakan menggunakan tatasusunan JavaScript di mana percubaan dibuat untuk mengakses kawasan di luar sempadan penimbal, menjejaskan keadaan blok ramalan cawangan disebabkan kehadiran semakan saiz penimbal yang ditambahkan oleh pengkompil (pemproses, memandang ke hadapan, melakukan akses secara spekulatif, tetapi mengembalikan keadaan selepas menyemak). Untuk menganalisis kandungan cache dalam keadaan ketepatan pemasa yang tidak mencukupi, kaedah dicadangkan yang memperdayakan strategi Tree-PLRU bagi pengusiran data yang digunakan dalam pemproses dan membolehkan, dengan meningkatkan bilangan kitaran, untuk meningkatkan perbezaan masa dengan ketara apabila kembali. nilai daripada cache dan apabila tiada nilai dalam cache.
Adalah diperhatikan bahawa Google menerbitkan prototaip eksploitasi untuk menunjukkan kemungkinan serangan menggunakan kelemahan kelas Spectre dan untuk menggalakkan pembangun web menggunakan teknik yang meminimumkan risiko daripada serangan tersebut. Pada masa yang sama, Google percaya bahawa tanpa kerja semula prototaip yang dicadangkan secara signifikan, adalah mustahil untuk mencipta eksploitasi sejagat yang sedia bukan sahaja untuk demonstrasi, tetapi juga untuk kegunaan meluas.
Untuk mengurangkan risiko, pemilik tapak digalakkan untuk menggunakan pengepala Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- Pilihan, X -Content-Type-Options dan SameSite Cookie. Mekanisme ini tidak secara langsung melindungi daripada serangan, tetapi ia membenarkan anda mengasingkan data tapak daripada kebocoran ke dalam proses di mana kod JavaScript penyerang boleh dilaksanakan (kebocoran berlaku daripada ingatan proses semasa, yang, sebagai tambahan kepada kod penyerang , juga boleh memproses data daripada tapak lain yang dibuka dalam tab yang sama). Idea utama adalah untuk memisahkan pelaksanaan kod tapak dalam proses yang berbeza daripada kod pihak ketiga yang diterima daripada sumber yang tidak boleh dipercayai, contohnya, disertakan melalui iframe.
Sumber: opennet.ru