Раскрыты (https://blog.bi0s.in/2019/08/20/Pwn/VM-Escape/2019-07-29-qem.../) детали критической уязвимости (CVE-2019-14378 (https://security-tracker.debian.org/tracker/CVE-2019-14378)) в обработчике SLIRP, по умолчанию применяемом в QEMU для организации канала связи между виртуальным сетевым адаптером в гостевой системе и сетевым бэкендом на стороне QEMU. Проблема также затрагивает системы виртуализации на базе KVM (в режиме Usermode (https://www.linux-kvm.org/page/Networking)) и Virtualbox, в которых используются бэкенд slirp из QEMU, а также приложения, применяющие сетевой стек в пространстве пользователя libSLIRP (https://github.com/rd235/libslirp) (эмулятор TCP/IP).Уязвимость позволяет добиться выполнение кода на стороне хост-системы с правами процесса-обработчика QEMU при отправки со стороны гостевой системы специально оформленного очень большого сетевого пакета, для которого требуется проведение фрагментации. Из-за ошибки в функции ip_reass(), вызываемой при пересборке входящих пакетов, первый фрагмент может не уместится в выделенный буфер и его хвост будет записан в следующие за буфером области памяти. Для тестирования уже доступен (https://github.com/vishnudevtj/exploits/tree/master/qemu/CVE...) рабочий прототип эксплоита, в котором в том числе предусмотрен обход ASLR.
Уязвимость уже устранена в Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1735654) и SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-14378), но остаётся неисправленной в Debian (https://security-tracker.debian.org/tracker/CVE-2019-14378), Arch Linux (https://security.archlinux.org/CVE-2019-14378) и FreeBSD (http://www.vuxml.org/freebsd/). В Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...) и RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14378) проблема не проявляется из-за неиспользования slirp. Уязвимость остаётся неисправленой в последнем выпуске libslirp 4.0 (https://gitlab.freedesktop.org/slirp/libslirp/-/releases) (исправление пока доступно в виде патча (https://gitlab.freedesktop.org/slirp/libslirp/commit/126c04a...)).
URL: https://blog.bi0s.in/2019/08/20/Pwn/VM-Escape/2019-07-29-qem.../
Новость: https://www.opennet.me/opennews/art.shtml?num=51343
Короче говоря, пора уже привыкнуть к тому, что виртуализация не есть изоляция.
Да. Думаю практически у всех (за редким исключением) вся безопасность построена на том, что нельзя выйти из контейнера в хостовую систему.
А сейчас уже приходится делать чуть ли не по отдельному датацентру на каждую DMZ. Это капец как накладно и мало кто такое может потянуть.
по этому нужно виртуалку запускать в виртуалке. что бы ломателю не скучно было
Я же говорил, что вместо процов надо ставить FPGA! Во-первых, можно будет исправлять любые аппаратные уязвимости, а во-вторых, можно будет реализовать аппаратные контейнеры.
И цены на аккумуляторы упадут еще сильнее, их ведь, если во всей мобильной технике заменить CPU на FPGA, потребуется в десятки раз больше.
SLIRP на серверах с виртуалками не используют - он медленный и не может слушать порты (без дополнительной настройки). Он для тех, кому лень настроить бридж (домашние пользователи) или нет возможности настроить систему из под рута (CI). Вообщем, тут мимо.
P.S. Redhat-овский buildah & podman (рекламируемый как "более безопасный docker"), кстати, тоже по-дефолту SLIRP для контейнеров использует.
Где одно там и другое. Тут важен сам факт такой возможности и что это не что-то там заоблачное. Уязвимость в vmxnet3 многих заставила пересмотреть всю архитектуру ИБ и наплодить буферных зон там, где их раньше не было.
Когда все топили за виртуализацию году в 2006-м вообще никто предположить не мог (ну или я один такой наивный был), что выход из гостевой VM физически возможен. Это казалось святым граалем в плане изоляции недоверенных сред.
один. Мы и в 2008м физически разделяли закрытые и открытые сервисы - не просто не смешивая их на соседних виртуалках, а вообще в разных стойках и на разном сетевом оборудовании (да, никаких "грязных" вланов на том же свитче, на котором крутятся внутренние сервисы)> Это казалось святым граалем в плане изоляции недоверенных сред.
ну надеюсь теперь-то поняли, что это просто еще один презерватив, надетый на свечку?
С SDN и всякой гиперконвергентностью всё стало гораздо запутанней. Не буду же я отдельный Cisco ACI под разные среды поднимать. Ладно, суёшь в целые отдельные тенанты. А потом такой радостно читаешь ньюз на опеннете: "Выход за границы tenant-а"...
И зачем нужен vmware NSX, если всё железными коммутами отбивать. Тут приходится идти на компромиссы.
> А потом такой радостно читаешь ньюз на опеннете: "Выход за границы tenant-а"...ну вот по этой причине - презервативов на свечке должно быть поболее одного.
(причем при большом желании все равно поимеют, так или иначе)
Imho, тут так - виртуалки - неплохой способ отделить незлонамеренных бакланов друг от друга. Не более.
"днем-то он мирный абрикос, а ночью - дикий урюк!" поломали очередной врот-пресс, и вместо незлонамеренного резвится стая любителей свежих эксплойтов.
Вы на полном серьезе считаете вмтварь виртуализацией? Мне страшно за вас.
так это давно понятно, поэтому связка из libvirt+qemu+kvm легко и приятно подхватывает SELinux или AppArmor. буквально надо 2 строчки в конфиге поправить для суровой изоляции.
Вполне себе изоляция с определенным степенем надежности.
Одна серьезная уязвимость в qemu в раз полгода - лучше, нежели поддержка зоопарка вроде бы изолированных серверов с потенциальными аппаратными уязвимостям, которые пофиксятся только апдейтом железа.
Дыры в qemu не отменяют аппаратных дыр.
Виртуализация не решает никаких проблем безопасности, только создаёт дополнительные.
Другой вопрос, что иногда без виртуализации прикладные проблемы решать неудобно. Поэтому приходится мириться с дополнительными потенциальными проблемами в безопасности.
ага, как не пытаются просто закрыть глаза и писать свой г-код без оглядки на безопастноить, да и вобще, без оглядки, все никак не получится..
о хоть где-то плюс убунты. а то я уже хотел уходить с нее.
> Из-за ошибки в функции ip_reass(),А вот называли бы функции менее ругательно -- и ошибки поди не допустили бы:)
наоборот - так она прошла бы sjw контроль, и была бы и в убунте тоже
Нет бесплатного сыра. Дешево, в адекекватные сроки (не 10 лет), безопасно. Выберете что-то одно.
Бесплатный сыр ЕСТЬ — в нетоварной экономике, например в opensource.
>например в opensourceГде все более менее крупные проекты живут за счет вливаний от большого бизнеса, а как известно, - кто девушку поит, то ее и танцует
а некрупные выживают на donate и тааакой рекламе, с которой уже даже гугель борется, потому что она позорит его бизнес.А о "нетоварной экономике" рассказывают только те, кто бесплатный сыр потом жрет с лопаты, не слишком брезгуя.
> потому что она позорит его бизнес.Ну вот, как говорят мудрые люди, и на старуху найдется проруха.
Proxmox уязвим?
Не должен. В продакшене slirp не используют
> но остаётся неисправленной в Debian, Arch Linux и FreeBSD
# ipfw list|head
00100 reass ip from any to any in
Удачи проэксплуатировать.
На, жри кактус: https://www.opennet.me/opennews/art.shtml?num=39674
> На, жри кактус: https://www.opennet.me/opennews/art.shtml?num=39674Т.е. ты не в курсе, чем TCP-фрагментация "out-of-order" отличается от фрагментации "больших" IP-пакетов или к чему эта ссылка (которую ты похоже даже и не читал толком)?
> It is possible to defend to these attacks by doing traffic normalization
> using a firewall. This can be done by including the following /etc/pf.conf
> configuration:
> scrub in allКстати, уязвимости только этого года у "некактосов":
https://www.cvedetails.com/cve/CVE-2019-11683/
https://www.cvedetails.com/cve/CVE-2019-11479/
https://www.cvedetails.com/cve/CVE-2019-11815/
но ты продолжай, продолжай.
Не могу не вспомнить прекрасное:
"You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes."
В CentOS 7 эксплойт таки работает: процесс qemu падает.
А калькулятор/другое тестовое приложение запускается?