Meltdown & Spectre - предотвращает ли утечка памяти между виртуальными машинами исправление гостевого ядра непатентованного гипервизора?

12

Через 24 часа после широкомасштабного выпуска уязвимостей Rackspace ничего не говорит о Spectre и Meltdown. У них нет плана исправления всех своих гипервизоров Xen. Все их новые серверы платформы являются серверами HVM, которые уязвимы. Старые PV-серверы не уязвимы.

Я обновил ядро Linux моих гостей HVM, но Rackspace не обновил ни одного из их гипервизоров. Поможет ли обновление гостевого ядра на непатентованном гипервизоре предотвратить доступ виртуальных машин «плохого парня» к утечке памяти с моего пропатченного хоста?

— Дэнни Ф
источник

1

См. Также security.stackexchange.com/q/176709/11291

— Майкл Хэмптон

12

Из того, что я понимаю об уязвимостях, нет - спекулятивные кеширующие атаки обходят все защиты процессора от процесса, захвата памяти с любого произвольного адреса.

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

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

— Шейн Мэдден
источник

6

Проще говоря: наличие исправленного гостевого ядра может помешать вашей ВМ получить доступ к гипервизору или другим ВМ, но это не помешает другим ВМ получить доступ к вашей!

— Майкл Хэмптон

Привет Шейн, это и моя вера. У вас есть документация, подтверждающая это? Дело в том, что память исправленного гостя уязвима для других гостей на том же оборудовании. Благодарю.

— Дэнни Ф

2

@DannyF Самая прямая ссылка на это, что я смог найти, была в статье об отказе - «физической памяти других процессов, ядра, а также в случае решений« песочницы »для совместного использования ядра (например, Docker, LXC) или Xen в режиме паравиртуализации, память ядра (или гипервизора) и других совмещенных экземпляров "

— Шейн Мэдден

-4

Призрак и Обвал.

С чего начать? плохой, я имею в виду очень плохой пресс-релиз о том, что может или не может повлиять на ваш компьютер, рабочую станцию, сервер или сервер в облаке. Да, это так, но у вас должен быть локальный доступ к связанному с процессором процессору, это может быть ПК или телефон, кажется, Apple был примером, но давайте подумаем о своем процессоре ARM, так что это каждая мобильная платформа, которая поддерживает функцию ( / экспозиция микрокода / слишком большой контроль над процессором из ОС / и т. д. / и т. д.)

Приложение должно быть запущено на процессоре устройства, поэтому я думаю, консольный доступ или, по крайней мере, удаленный пользователь, который получает доступ к системе, доступ к устройству ввода ....

В настоящее время единственным известным способом использования этих уязвимостей является локальный / прямой доступ к ЦП (опять же, если у вас есть SSH / VNC и т. Д.), Он может быть удаленным.

Ниже приведены патчи, которые я нашел до сих пор.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Теперь это должно быть лучшим ответом на проблему сейчас

Что сказали наши друзья из BSD?

Плохой гугл; (

проверка Powershell на то же самое;)

Ядро Linux Хорошо, у нас была интересная неделя, и теперь все знают, почему мы объединяли все эти нечетные патчи изоляции таблицы страниц x86, не следуя всем нормальным правилам синхронизации выпуска.

Я могу / вернусь и отредактирую этот пост. Я уверен, что не проблема (пока в дикой природе) не будет реальной проблемой в долгосрочной перспективе. Google действительно следовал датам раскрытия информации здесь! -1 для Google

— Эндрю Смолли
источник

«Amazon Linux (AMI)» - это дистрибутив Amazon Linux, который подвержен так же, как и все другие гостевые операционные системы. В этом контексте более актуальным является aws.amazon.com/de/security/security-bulletins/AWS-2018-013 (начальный раздел) для объявления EC2 (их платформы виртуализации), поскольку вы, похоже, пытались перечислить решения для виртуализации.

— Хокан Линдквист

1

Читая и перечитывая это, я не верю, что это действительно решает вопрос? В основном это просто напыщенная речь о процессе раскрытия?

— Хакан Линдквист,

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

— Дэнни Ф