URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 118239
[ Назад ]

Исходное сообщение
"Уязвимость, позволяющая выйти из изолированного окружения QEMU"

Отправлено opennews , 23-Авг-19 11:20 
Раскрыты (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


Содержание

Сообщения в этом обсуждении
"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 11:20 
Короче говоря, пора уже привыкнуть к тому, что виртуализация не есть изоляция.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено mumu , 23-Авг-19 11:26 
Да. Думаю практически у всех (за редким исключением) вся безопасность построена на том, что нельзя выйти из контейнера в хостовую систему.
А сейчас уже приходится делать чуть ли не по отдельному датацентру на каждую DMZ. Это капец как накладно и мало кто такое может потянуть.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 12:11 
по этому нужно виртуалку запускать в виртуалке. что бы ломателю не скучно было

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Корец , 23-Авг-19 18:39 
Я же говорил, что вместо процов надо ставить FPGA! Во-первых, можно будет исправлять любые аппаратные уязвимости, а во-вторых, можно будет реализовать аппаратные контейнеры.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Hewlett Packard , 23-Авг-19 23:12 
И цены на аккумуляторы упадут еще сильнее, их ведь, если во всей мобильной технике заменить CPU на FPGA, потребуется в десятки раз больше.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Тупой погроммист , 23-Авг-19 12:22 
SLIRP на серверах с виртуалками не используют - он медленный и не может слушать порты (без дополнительной настройки). Он для тех, кому лень настроить бридж (домашние пользователи) или нет возможности настроить систему из под рута (CI). Вообщем, тут мимо.
P.S. Redhat-овский buildah & podman (рекламируемый как "более безопасный docker"), кстати, тоже по-дефолту SLIRP для контейнеров использует.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено mumu , 23-Авг-19 13:18 
Где одно там и другое. Тут важен сам факт такой возможности и что это не что-то там заоблачное. Уязвимость в vmxnet3 многих заставила пересмотреть всю архитектуру ИБ и наплодить буферных зон там, где их раньше не было.
Когда все топили за виртуализацию году в 2006-м вообще никто предположить не мог (ну или я один такой наивный был), что выход из гостевой VM физически возможен. Это казалось святым граалем в плане изоляции недоверенных сред.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено пох. , 23-Авг-19 13:38 
один. Мы и в 2008м физически разделяли закрытые и открытые сервисы - не просто не смешивая их на соседних виртуалках, а вообще в разных стойках и на разном сетевом оборудовании (да, никаких "грязных" вланов на том же свитче, на котором крутятся внутренние сервисы)

> Это казалось святым граалем в плане изоляции недоверенных сред.

ну надеюсь теперь-то поняли, что это просто еще один презерватив, надетый на свечку?


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено mumu , 23-Авг-19 14:32 
С SDN и всякой гиперконвергентностью всё стало гораздо запутанней. Не буду же я отдельный Cisco ACI под разные среды поднимать. Ладно, суёшь в целые отдельные тенанты. А потом такой радостно читаешь ньюз на опеннете: "Выход за границы tenant-а"...
И зачем нужен vmware NSX, если всё железными коммутами отбивать. Тут приходится идти на компромиссы.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено пох. , 23-Авг-19 14:38 
> А потом такой радостно читаешь ньюз на опеннете: "Выход за границы tenant-а"...

ну вот по этой причине - презервативов на свечке должно быть поболее одного.

(причем при большом желании все равно поимеют, так или иначе)


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено mickvav , 23-Авг-19 19:14 
Imho, тут так - виртуалки - неплохой способ отделить незлонамеренных бакланов друг от друга. Не более.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено пох. , 24-Авг-19 09:19 
"днем-то он мирный абрикос, а ночью - дикий урюк!" поломали очередной врот-пресс, и вместо незлонамеренного резвится стая любителей свежих эксплойтов.


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено G0Dzilla , 25-Авг-19 13:12 
Вы на полном серьезе считаете вмтварь виртуализацией? Мне страшно за вас.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено leap42 , 23-Авг-19 11:33 
так это давно понятно, поэтому связка из libvirt+qemu+kvm легко и приятно подхватывает SELinux или AppArmor. буквально надо 2 строчки в конфиге поправить для суровой изоляции.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 11:45 
Вполне себе изоляция с определенным степенем надежности.
Одна серьезная уязвимость в qemu в раз полгода - лучше, нежели поддержка зоопарка вроде бы изолированных серверов с потенциальными аппаратными уязвимостям, которые пофиксятся только апдейтом железа.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 24-Авг-19 20:17 
Дыры в qemu не отменяют аппаратных дыр.
Виртуализация не решает никаких проблем безопасности, только создаёт дополнительные.
Другой вопрос, что иногда без виртуализации прикладные проблемы решать неудобно. Поэтому приходится мириться с дополнительными потенциальными проблемами в безопасности.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Leo90 , 23-Авг-19 12:29 
ага, как не пытаются просто закрыть глаза и писать свой г-код без оглядки на безопастноить, да и вобще, без оглядки, все никак не получится..

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено advisor , 23-Авг-19 11:40 
о хоть где-то плюс убунты. а то я уже хотел уходить с нее.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 11:44 
> Из-за ошибки в функции ip_reass(),

А вот называли бы функции менее ругательно -- и ошибки поди не допустили бы:)


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено пох. , 23-Авг-19 12:22 
наоборот - так она прошла бы sjw контроль, и была бы и в убунте тоже

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 13:05 
Нет бесплатного сыра. Дешево, в адекекватные сроки (не 10 лет), безопасно. Выберете что-то одно.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 13:15 
Бесплатный сыр ЕСТЬ — в нетоварной экономике, например в opensource.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено OpenEcho , 23-Авг-19 16:53 
>например в opensource

Где все более менее крупные проекты живут за счет вливаний от большого бизнеса, а как известно, - кто девушку поит, то ее и танцует


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено пох. , 24-Авг-19 09:23 
а некрупные выживают на donate и тааакой рекламе, с которой уже даже гугель борется, потому что она позорит его бизнес.

А о "нетоварной экономике" рассказывают только те, кто бесплатный сыр потом жрет с лопаты, не слишком брезгуя.


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 24-Авг-19 22:00 
> потому что она позорит его бизнес.

Ну вот, как говорят мудрые люди, и на старуху найдется проруха.


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 13:13 
Proxmox уязвим?

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Мертвые_опята , 23-Авг-19 14:16 
Не должен. В продакшене slirp не используют

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено анонн , 23-Авг-19 15:02 
> но остаётся неисправленной в Debian, Arch Linux и FreeBSD


# ipfw list|head
00100 reass ip from any to any in

Удачи проэксплуатировать.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 26-Авг-19 01:21 
На, жри кактус: https://www.opennet.me/opennews/art.shtml?num=39674

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено анонн , 26-Авг-19 12:23 
> На, жри кактус: 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/
но ты продолжай, продолжай.


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Дон Ягон , 23-Авг-19 15:11 
Не могу не вспомнить прекрасное:
"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."

(https://marc.info/?l=openbsd-misc&m=119318909016582)


"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 16:19 
В CentOS 7 эксплойт таки работает: процесс qemu падает.

"Уязвимость, позволяющая выйти из изолированного окружения QE..."
Отправлено Аноним , 23-Авг-19 16:58 
А калькулятор/другое тестовое приложение запускается?