В гипервизоре Xen выявлены (https://blog.xenproject.org/2017/05/02/updates-on-xsa-213-xs.../) три уязвимости (XSA-213 (https://xenbits.xen.org/xsa/advisory-213.html), XSA-214 (https://xenbits.xen.org/xsa/advisory-213.html) и XSA-215 (https://xenbits.xen.org/xsa/advisory-213.html)), каждая из которых позволяет выйди за пределы текущего гостевого окружения. Уязвимости также могут использоваться (https://www.qubes-os.org/news/2017/05/02/qsb-30/) для обхода механизмов изоляции в ОС Qubes. Проблемы выявлены исследователями безопасности из группы Zero (https://googleprojectzero.blogspot.ru/), созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей.
Исправления пока доступны в виде патчей (http://xenbits.xen.org/xsa/). CVE-идентификатор пока не присвоен. Некоторые провайдеры публичных облачных систем были уведомлены о проблеме две недели назад и уже устранили уязвимость. Всем пользователям Xen и провайдерам, не включённым в список (https://www.xenproject.org/security-policy.html) упреждающей отправки уведомлений, рекомендуется срочно установить обновление. Для эксплуатации всех уязвимостей атакующий должен иметь доступ к выполнению кода в гостевой системе с правами ядра. В качестве обходного пути можно блокировать поддержку загрузки модулей ядра и других механизмов, позволяющих выполнить код на уровне ядра гостевой ОС.
Наиболее опасной из трёх уязвимостей является XSA-213, которая позволяет совершить атаку на хост-систему из любого 64-разрядного гостевого окружения, работающего в режиме паравиртуализации (PV). В результате атаки через манипуляцию с гипервызовом (hypercall) IRET злоумышленник может добиться изменения таблиц страниц памяти и получить доступ ко всей памяти хост-системы. Уязвимость проявляется только на системах x86_64. Платформа ARM, а также 32-разрядные гостевые системы и окружения режиме HVM, данной проблеме не подвержены.
Уязвимость XSA-213 отмечается (https://www.qubes-os.org/news/2017/05/02/qsb-30/) как одна из самых серьёзных ошибок в Xen за последние 8 лет (до этого было выявлено всего 3 ошибки подобного уровня - XSA-148 (https://www.opennet.me/opennews/art.shtml?num=43219), XSA-182 (https://www.opennet.me/opennews/art.shtml?num=44855) и XSA-212 (https://www.opennet.me/opennews/art.shtml?num=46322)). Важность проблемы также усугубляет возможность применения стабильно работающего эксплоита, не требующего каких-то особых условий для атаки. Прототип эксплоита уже подготовлен, но не опубликован в открытом доступе. PV-окружения теперь рассматриваются проектом Qubes как ненадёжные и в следующем выпуске Qubes 4.x планируется полностью перейти на окружения в режиме полной изоляции (HVM).Что касается остальных проблем, то эксплуатация уязвимости XSA-214 требует наличия контроля за двумя разными гостевыми системами, например, одним в режиме PV и одним в режима HVM, или одним 32-разрядным PV и одним 64-разрядным PV. Проблема XSA-215 затрагивает только хост-системы с очень большим объёмом памяти, от 3.5 Тб или 5 Тб ОЗУ, в зависимости от настроек.
URL: https://www.qubes-os.org/news/2017/05/02/qsb-30/
Новость: http://www.opennet.me/opennews/art.shtml?num=46493
Именно и только поэтому мы выбираем kvm, а не xen.
KVM неуязвим!
Пруфы:
https://goo.gl/TDQPtw
Уязвимость в xen страшнее чем в kvm.
да он вообще страшнее!
Странно, что в Debian jessie ещё прошлую до сих пор не пофиксили.
https://www.opennet.me/opennews/art.shtml?num=46322
>PV-окружения теперь рассматриваются проектом Qubes как ненадёжные и в следующем выпуске Qubes 4.x планируется полностью перейти на окружения в режиме полной изоляции (HVM).В xen PV безопасность обеспечивается открытым кодом, в HVM - проприетарным микрокодом процессора. В упор не догоню, почему первое считают небезопасным, а второе - безопасным. По-моему вероятность допустить ошибку приблизительно одинакова. Или считают, что закрытый код более безопасный?
Этого микрокода относительно мало (относительно объема кода для PV), поэтому и доверия ему больше. А баги там, конечно, были, но в целом их выловили за годы существования технологии.
Вы явный оптимист:) Были, есть и будут!!! Мало того если мы их вычислим при взаимодействии с какой либо крупной конторой, скажем при адаптации их оборудования под устанавливаемую нами инфраструктуру мы тут-же попадаем под неразглашение, и таких случаев немало. У них тоже сроки, костыли, и попытки за счет прошивки покрыть глюки в железе, чтобы производственную линию не переделывать(Читаем Брукса, ничего, ничего не изменилось за почти пол-века), а как патчатся сами прошивки, если за уязвимость не могут подать в суд, тоже отдельная история с мифологией. Я думаю многие мои коллеги могли бы выдать кучу подробностей, так что не идеализируйте :)
"PV-окружения теперь рассматриваются проектом Qubes как ненадёжные и в следующем выпуске Qubes 4.x планируется полностью перейти на окружения в режиме полной изоляции (HVM)."
Хе-хе. Что-то Яну занесло. В довесок получить весь долбаный legacy из qemu?
Пример: посмотрите на реализацию i8042 (если не вру). Что там в прошлый раз было? Флоповод? Часики (на которые hwclock смотрит) на очереди. (Qemu не виноват, что его назначили промышленным гипервизором, не вычистив код. Но результаты расхлёбываю в т.ч. я.)
Флопповод на i8042? Насколько помню, контроллер FDD это i82077.
А разве в Qubes приложения в PV запускаются от рута? Насколько я понял, XSA-213 и XSA-214 работают только если есть возможность загрузить собственный специально подготовленный модуль ядра.
> А разве в Qubes приложения в PV запускаются от рута? Насколько я
> понял, XSA-213 и XSA-214 работают только если есть возможность загрузить собственный
> специально подготовленный модуль ядра.Если честно, я тоже не совсем понял смысл фразы Рутковской: "This means that if an attacker has already exploited another vulnerability, e.g. in a Web browser or networking or USB stack, then the attacker would be able to compromise a whole Qubes system."
Про системные стеки понятно, но и вероятность атаки через них минимальна, но вот почему она упоминает Web Browser, который явно под обычным пользователем запускается.
>Про системные стеки понятно, но и вероятность атаки через них минимальна, но вот почему она упоминает Web Browser, который явно под обычным пользователем запускается.Потому что только школьники считают, что браузер не ломается. Или не ломается он _только_ под линуксом.
Все правильно она делает. После получения доступа на систему под обычным пользователем, вопрос получения рута вопрос времени.
> Все правильно она делает. После получения доступа на систему под обычным пользователем,
> вопрос получения рута вопрос времени.И как это вы получите рута в полупустом контейнере на обновлённой системе, в котором нет привилегированных процессов? Чтобы получить рута в системе из контейнера как минимум нужен root в контейнере, а в контейнере с браузром только работающий под обычным пользователем браузер.
> Про системные стеки понятно, но и вероятность атаки через них минимальна, но вот почему она упоминает Web Browser, который явно под обычным пользователем запускается.Потому, что -- сюрприз -- Рутковски не доверяет разграничениям доступа для процессов, которые предоставляет ОС. Это её парадигмальная установка. Если бы она доверяла, она бы не стала пилить Qubes, но организвала бы всё на этом разграничении: ведь нет никаких проблем с тем, чтобы создать по отдельному пользователю для каждого процесса.
потому что в qubes нет паролья на sudo по-умолчанию
> потому что в qubes нет паролья на sudo по-умолчаниювы qubes c чем-то путайте.
Интересно, что делает Amazon, когда появляются такие новости. Обновляют, перезагружают все свои датацентры?
±Вот это https://support.citrix.com/article/CTX132791
то же, что и когда "такие" не появляются - да, обновляют, штатная процедура. Содержимое при перезагрузке конкретной ноды - мигрирует, поэтому юзер ничего, обычно, не замечает - у него-то ничего не обновляется.
Чего удивительного-то?
В общем-то да, у них явно есть live migration. Дайунтайм будет минимальным.