Чи можливо, що віртуальна машина на зразок VirtualBox має вразливість безпеки "привид"? Я думаю, що VM, можливо, виконує поза замовлення, але, на мою думку, не вдається зазирнути в кеш, щоб прочитати результат.

Чи є пояснення, як можна читати кеш віртуального процесора?

Так, Spectre може перетинати межі хоста / гостя, гостя / хоста та гостя / гостя, оскільки це недолік рівня процесора, що означає, що потенційно чутлива інформація може просочуватися через все, що працює на ядрі процесора.

Більшість новин в Інтернеті говорять про те, що це найбільше постраждало від постачальників хмарних ситуацій, оскільки вони мають величезні кластери систем, які віртуалізуються і потенційно можуть бути використані для витоку конфіденційної інформації.

Більшість великих постачальників до цього часу вже мали б відповідати недолікам, як найкраще, але це буде проблема, яка живе з нами деякий час.

Security.SE має канонічні запитання щодо цього, і він згадує VM:

Я запускаю віртуальну машину / контейнери, наскільки я вразливий?

Відповідно до відповіді Steffen Ullrich

• Атаки зриву не перетинають VM, лише просочують пам'ять ядра до локальних процесів.
• Спектр може працювати у ВМ.

Також, від Steffen знову , Meltdown і Spectre працюють з контейнерами, оскільки контейнери покладаються на головне ядро.

Віртуальні машини використовують фактичний процесор у вашій системі з деякими привілейованими інструкціями, захопленими та можуть бути перенаправлені. Він використовує ті самі кеші та інструкції, що і хост. По суті це лише ще один шар у фізичному процесорі вашої системи.

Віртуалізація відбувається лише швидко, оскільки вона використовує фізичний процесор з якомога меншою абстракцією та покладається на апаратне забезпечення процесора для забезпечення ізоляції. Такі речі, як qemu, можуть робити емуляцію, що було б безпечніше, оскільки це не апаратний процесор, але він набагато повільніше і відрізняється від віртуалізації.

З канонічної публікації Security.se знову:

Спектр працює на іншому рівні і не дозволяє отримати доступ до даних про простір ядра з простору користувача. У цій атаці зловмисник хитрує спекулятивне виконання, щоб передбачувано виконувати вказівки помилково. Коротше кажучи, передбачувач змушений передбачати конкретний результат гілки (якщо -> істина), що призводить до запиту позамежного доступу до пам'яті, до якого зазвичай не вимагав би потерпілий процес, що призводить до неправильного спекулятивного виконання. Потім по бічному каналу отримує значення цієї пам'яті. Таким чином пам’ять, що належить до потерпілого процесу, просочується до шкідливого процесу.

Отже, оскільки VM працює на фактичному апаратному забезпеченні процесора, і все, що йому потрібно зробити, це запустити певний цикл, щоб "навчити" двигун спекулятивного виконання. Тоді він може використовувати точний термін для перегляду кешів для конкретних шаблонів доступу, що вказують на хост або гостьовий (або інший VM) процес, який він хоче використовувати.

Таким чином, це означає, що машина є експлуатованою у будь-якому напрямку. Від хоста до VM, від VM до хоста і від VM до VM.

Так, це аж ніяк не просто, і важко це витягнути, оскільки ядро ​​процесора VM може змінюватися за примхою хоста, і хост також може із задоволенням планувати завдання на різних ядрах, але протягом тривалого періоду часу достатньо інформації може просочитися, щоб видати секретний ключ до якоїсь важливої ​​системи чи облікового запису. Враховуючи достатньо часу та деякого належного прихованого програмного забезпечення, все потенційно відкрито.

Якщо ви хотіли "захищений" VM, ви повинні гарантувати, що його сердечники ізольовані. Єдиним реальним способом заблокувати цю атаку було б "змусити" хост і VM використовувати лише певні ядра, щоб вони ніколи не працювали на одному і тому ж апаратному забезпеченні, але це призведе до ефективного збільшення вартості, оскільки ви не зможете мати стільки віртуальних машин на даному хості. Ви ніколи не зможете уникнути роботи із більшою кількістю віртуальних машин, ніж у вас є наявні сердечники, що я б очікував зробити на серверах з низьким навантаженням, оскільки багато систем простоюють 90% свого життя.

gem5

Якщо вам цікаво вивчати / відтворювати вразливості виключно за допомогою емуляції, не використовуючи хост-процесор, я не думаю, що QEMU є досить детальним для їх спостереження, оскільки він не імітує конвеєр CPU.

gem5, однак, використовується для оцінки продуктивності системи в дослідженнях та розробках і моделює достатню кількість внутрішніх процесорів, щоб ви могли спостерігати Spectre у повністю чистому та контрольованому середовищі.

Класна демонстрація x86_64 з візуалізацією була опублікована за адресою: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Мінусом gem5 є те, що він набагато повільніше, ніж QEMU, моделювання більш детальне.