Чи може віртуальна машина (VM) "зламати" інший VM, що працює на тій же фізичній машині?

Запитання:

• якщо VM пошкоджений (зламаний), що я ризикую для інших VM, що працюють на одній фізичній машині?
• Які проблеми із безпекою існують між віртуальними машинами, що працюють на одному фізичному хості?
• Чи є (ви можете скласти) список тих (потенційних) слабких місць та / або проблем?

Увага:

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

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

• Приклади:

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

EDIT: Я також виявив, що ця атака "Flush + Reload" здатна отримати секретні ключі GnuPG на тій же фізичній машині, використовуючи кеш процесора L3, навіть якщо GnuPG працює на іншому VM. З цього часу GnuPG виправлено.

Звичайно, можна використовувати інший VM, що працює на тому ж апаратному забезпеченні, враховуючи робочий подвиг. Крім того, можна існувати. У вашому запитанні цитується деяка нещодавня робота, яка показує одну. Я не збираюся ділитися тут якимись конкретними подвигами чи PoC, але з радістю скажу, як їх можна зробити.

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

• Напад на гіпервізора . Якщо ви можете отримати достатньо привілейовану оболонку на гіпервізорі, якому надається VM, ви можете отримати контроль над будь-яким ВМ в системі. Спосіб підходу до цього полягає в пошуку потоків даних, що існують з ВМ в гіпервізор, і вони дуже залежні від гіпервізора; Такі речі, як паравіртуалізовані драйвери, обмін буфером обміну, вихідний показ та мережевий трафік, як правило, створюють цей тип каналу. Наприклад, зловмисний виклик паравіртуалізованого мережевого пристрою може призвести до довільного виконання коду в контексті гіпервізора, відповідального за передачу цього трафіку фізичному драйверу NIC.
• Атакувати апаратне забезпечення на хості . Багато пристроїв дозволяють оновлювати прошивку, і якщо трапляється можливість отримати доступ до механізму для цього з VM, ви можете завантажувати нову прошивку, яка сприяє вашим намірам. Наприклад, якщо вам дозволено оновлювати мікропрограмне забезпечення в NIC, ви можете змусити його дублювати трафік, пов’язаний з однією MAC-адресою (жертвою), але з іншою MAC-адресою призначення (вашою). З цієї причини багато гіпервізорів фільтрують такі команди, де це можливо; ESXi фільтрує оновлення мікрокоду CPU, коли вони походять від VM.
• Атакувати архітектуру хоста. Атака, яку ви цитували, це, по суті, ще одна атака розкриття ключових даних, що базується на хронометражі, робить це: вона використовує вплив механізму кешування на час роботи, щоб виявити дані, які використовує жертва VM у своїх операціях. В основі віртуалізації лежить обмін компонентами; де компонент спільний, існує можливість бічного каналу. У тій мірі, коли інша VM на тому ж хості здатна впливати на поведінку апаратури під час роботи в контексті жертви VM, жертва VM контролюється зловмисником. Згадана атака використовує можливість VM контролювати поведінку кешу CPU (по суті, загального універсального стану), щоб часи доступу до пам'яті жертви точніше розкривали дані, до яких вона отримує доступ; де б не було спільної глобальної держави, існує також можливість розкриття інформації. Щоб перейти до гіпотетичного, щоб навести приклади, уявіть собі атаку, яка масажує VMFS ESXi і змушує частини віртуальних томів посилатися на ті ж адреси фізичних дисків, або атака, яка змушує систему балонної пам’яті вірити, що деякою пам’яттю можна ділитися, коли насправді це має бути приватний (це дуже схоже на те, як працюють подвиги без використання або подвійного розподілу). Розглянемо гіпотетичний MSR процесора (реєстр, що залежить від моделі), до якого гіпервізор ігнорує, але дозволяє отримати доступ до нього; це може бути використане для передачі даних між ВМ, порушуючи ізоляцію, яку повинен забезпечити гіпервізор. Розглянемо також можливість використання компресії для того, щоб повторювані компоненти віртуальних дисків зберігалися лише один раз - у деяких конфігураціях може існувати (дуже складний) бічний канал, де зловмисник може розпізнати вміст інших віртуальних дисків, записуючи власні та спостерігаючи що робить гіпервізор. Звичайно, гіпервізор повинен захищати це, і гіпотетичні приклади можуть бути критичними помилками безпеки, але іноді ці речі прослизають.
• Нападайте на інший VM безпосередньо . Якщо у вас є проксимальний хост до жертви VM, ви, можливо, зможете скористатись розслабленим контролем доступу або навмисним між-VM-зв’язком залежно від того, як налаштовано хост і які припущення зроблені під час розгортання контролю доступу. Це лише незначно, але все-таки згадується.

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

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

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

Теоретично, ні. Вся суть гіпервізора полягає в ізоляції віртуальних машин один від одного.

На практиці були помилки безпеки у різних гіпервізорах, які могли б дозволити одній віртуальній машині впливати на гіпервізор чи інші віртуальні машини на одному хості. Такі заходи безпеки, як sVirt (для KVM / QEMU), призначені для вирішення цієї проблеми.

Редагувати: Я думав, що ця тема була зроблена з місяцями тому, але вона просто відродилася, і зараз ОП просить більше "реальних фактів, цитованих досліджень" і т. Д., Тож я зрозумів, що за чорт.

Подібні подвиги:

1. Рідкісний
2. Чутливий за своєю суттю, і тому не публічно публікується, і коли вони будуть, подвиги буде виправлене продавцем, перш ніж хто-небудь на цьому веб-сайті коли-небудь знав про них
3. Складний і відрізнятиметься від постачальника

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

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

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

Ось уривок із звіту про тенденції та ризики IBM X-Force 2010 за середній рік:

(Відкрийте це зображення на новій вкладці, щоб переглянути його у повному розмірі.)

Зверніть увагу на виміряний відсоток уразливості "Втеча до гіпервізора", що для мене звучить досить страшно. Звичайно, ви хочете прочитати решту звіту, оскільки в ньому є набагато більше даних для резервного копіювання претензій.

Ось історія про можливий подвиг, здійснений на гіпервізорі Playstation 3, який є кумедним. Можливо, не настільки сильно впливає на ваш бізнес, якщо ви не займаєтеся компанією Sony, в цьому випадку це надзвичайно ефектно.

Ось чудова стаття від Еріка Хоршмана з VMware, в якій він начебто злітається зі мною, звучачи як підліток, який переживає повний анти-Micro $ oft, але це все-таки хороша стаття. У цій статті ви знайдете такі примхливості:

У мешканців скляного будинку Microsoft були ще якісь камені, щоб кинути нам шлях. Microsoft вказала на CVE-2009-1244 як приклад вразливості прориву гостей у ESX та ESXi. Експлоатація гостьового прориву - серйозний бізнес, але, знову ж таки, Microsoft неправильно представляє факти. VMware швидко реагує на виправлення цієї вразливості в наших продуктах, а ESX набагато менше впливає, ніж Microsoft спонукає вас до думки:

Вікторина серед конкурентів. Але, мабуть, найяскравіше, що він говорить у всій статті, це:

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

Коли цитований Тео де Raddt проекту OpenBSD:

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

Трохи запальний, але його точка зору добре. Теоретично віртуалізація повинна забезпечувати повну ізоляцію між віртуальними машинами та їх хостом. На практиці є випадкові вразливості безпеки, які дозволяють передовим зловмисникам обійти ці захисти та отримати доступ до інших віртуальних машин або ще гірше їх хоста (див . Емпіричне дослідження експозиції безпеки для господарів ворожих віртуалізованих середовищ ). Як згадує Райан Райс, такі вразливості досить рідкісні (це не означає, що їх немає) і часто не розкриваються постачальниками, але вони існують.

Якщо ви стурбовані можливістю подібних атак (і я певною мірою думаю, що ви повинні бути), я рекомендую не змішувати зони безпеки на одному віртуальному хості або віртуальному хостовому кластері. Наприклад - у вас буде виділений два віртуальних хост-кластера для віртуальних машин DMZ, виділений кластер для проміжного програмного забезпечення та виділений кластер для захищених активів. Таким чином, якщо вразливість експлуатується таким чином, що дозволяє зловмиснику підривати інші віртуальні машини або, що ще гірше, сам гіпервізор, ваша модель безпеки залишається недоторканою.