форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
Сообщение от opennews (??) on 31-Дек-11, 13:40
В реализации virtio-устройств обнаружена уязвимость (https://rhn.redhat.com/errata/RHSA-2011-1849.html), позволяющая (https://lkml.org/lkml/2011/12/22/270) организовать из изолированных гостевых систем запись и чтение данных для блочных устройств или LVM-разделов, через отправку SCSI-команд через SG_IO ioctl. Уязвимости подвержены окружения, работающие под управлением QEMU и KVM. Проблеме также подвержен OpenVZ, но только в случае проброса разделов, что обычно не практикуется для окружений на базе OpenVZ. Системы на базе Xen не подвержены проблеме, так как драйвер блочных устройств, используемый в Xen, не поддерживает вызов SG_IO ioctl. Уязвимость распространяется только на блочные устройства, используемые в работе гостевых систем: например, если в гостевую систему проброшен раздел /dev/sda3, то злоумышленник, имеющий root-права в гостевой системе, может не покидая изолированное окружение получить доступ ко всем данным на диске /dev/sda, включая другие разделы и загрузочный сек... URL: http://rwmj.wordpress.com/2011/12/22/cve-2011-4127-privilege.../ Новость: http://www.opennet.me/opennews/art.shtml?num=32703
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
Сообщение от Аноним (??) on 31-Дек-11, 13:45
Я правильно понимаю, что эта брешь не распространяется на окружения, где не используется проброс разделов (т.е. файл-образ типа qcow2)?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Аноним (??) on 31-Дек-11, 13:46
	> Я правильно понимаю, что эта брешь не распространяется на окружения, где не > используется проброс разделов (т.е. файл-образ типа qcow2)? Т.е. используется файл-образ типа qcow2 fixed
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+6 +/–
	Сообщение от Аноним (??) on 31-Дек-11, 14:02
	> Я правильно понимаю, что эта брешь не распространяется на окружения, где не > используется проброс разделов (т.е. файл-образ типа qcow2)? Да, правильно. Проблема проявляется только если внутри гостевой системы используется физический раздел.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	11. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+4 +/–
	Сообщение от Аноним (??) on 31-Дек-11, 15:47
	Причем через virtio.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+1 +/–
Сообщение от Аноним (??) on 31-Дек-11, 15:50
Интересно, как оно действует при работе с томами LVM? Насколько я понимаю, работать не должно. Что автоматически отсекает все enterprise-системы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от shadow_alone (ok) on 31-Дек-11, 16:22
	> Интересно, как оно действует при работе с томами LVM? Насколько я понимаю, > работать не должно. Что автоматически отсекает все enterprise-системы. Мне вот тоже интересно по LVM. По идее не должно работать, если даешь гостю том, то за пределы тома он не выйдет полюбе.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	20. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Аноним (??) on 31-Дек-11, 17:36
	Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или нет. По идее, не должна, но я в данной области не спец, потому и спрашиваю.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от shadow_alone (ok) on 31-Дек-11, 18:03
	> Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или > нет. По идее, не должна, но я в данной области не > спец, потому и спрашиваю. По идее,том как отдельное устройство.То есть выше прыгать уже некуда.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	57. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Кирилл (??) on 02-Янв-12, 02:54
	Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical Volume?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	58. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от shadow_alone (ok) on 02-Янв-12, 04:13
	> Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical > Volume? Конечно же Logical Volume
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	59. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Кирилл (??) on 02-Янв-12, 04:33
	Тогда не очень понимаю, за пределы чего можно выйти, используя описанную "уязвимость". Похоже речь идёт, всё же, не о выходе на уровень логического тома, а на уровень, как минимум, группы томов, в которой этот логический том определён.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	61. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Аноним (??) on 02-Янв-12, 17:48
	Ну, например, если на логическом томе создана таблица разделов, и один из них выдан виртуалке :)
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

31. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+3 +/–
Сообщение от solardiz (ok) on 31-Дек-11, 20:50
> Проблеме также подвержен OpenVZ, но только в случае проброса разделов, что обычно не практикуется для окружений на базе OpenVZ. Проброс разделов в OpenVZ и даже просто разрешение использования /dev/loop* устройств внутри OpenVZ-контейнера небезопасны by design, и без этой уязвимости. Можно создать на таком устройстве запорченную файловую систему, которую потом попытаться подмонтировать - и получить таким образом kernel panic (гарантированно при направленных на это действиях - например, опция монтирования errors=panic для ext*), а потенциально - выполнение произвольного кода в ring 0 через особенности реализации одной из файловых систем. Таких настроек следует избегать. (По умолчанию, /dev/loop* из контейнеров не доступны - именно по этой причине.) Если нужно пробросить отдельный диск, RAID-массив и т.п. в контейнер, соответствующие файловые системы следует монтировать с хост-системы. Например, так: http://wiki.openvz.org/Bind_mounts
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Bx (ok) on 02-Янв-12, 15:20
	При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству в хост-системе, ошибка by design.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	62. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от Аноним (??) on 02-Янв-12, 17:51
	> При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству > в хост-системе, ошибка by design. Уязвимость необязательно обусловлена только одной ошибкой. Неконтролируемый ioctl - одна из таких ошибок. Но передача блочных устройств в контейнер - тоже, безусловно, неправильное и небезопасное решение. Сабжевая новость демонстрирует только одну из возможных проблем, связанных с этим решением (примеры других проблем приведены в комментарии выше).
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	63. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от solardiz (ok) on 02-Янв-12, 23:29
	Я не столько о конкретной уязвимости, сколько о том, что разработчики OpenVZ ранее приняли решение считать проброс блочных устройств и доступность /dev/loop* внутри контейнеров выходящими за рамки политики безопасности OpenVZ. Этот вопрос обсуждался во время моего аудита OpenVZ в конце 2005 (незадолго до выхода проекта на публику). Он сравнительно недавно поднимался повторно здесь: http://bugzilla.openvz.org/show_bug.cgi?id=1847 - вердикт по конкретным проблемам, проявляющимся при доступности блочных устройств в контейнере, пока что остался прежним - как видим, это WONTFIX. С правильностью этого подхода можно соглашаться или спорить, но это нынешняя позиция OpenVZ upstream, и она остается неизменной вот уже 6 лет. Возможно, следует улучшить документацию, чтобы эти и другие риски были более очевидны для OpenVZ-сисадминов. (Говоря о других рисках - например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ. Это тоже могло бы быть документировано явно, что, кажется, на данный момент не сделано.)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	64. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от alex.h (??) on 06-Янв-12, 22:27
	> например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ Можно раскрыть этот момент подробнее? Получается что такая система как Proxmox VE (http://proxmox.com/products/proxmox-ve) потенциально небезопасна согласно политики OpenVZ?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	65. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от solardiz (ok) on 06-Янв-12, 23:03
	В OpenVZ не предусмотрена изоляция процессов внутри контейнеров от действий процессов с тем же uid на хост-системе. (В другую сторону и между контейнерами - предусмотрена.) Также, с хост-системы видны через procfs процессы всех контейнеров. Поэтому если на хост-системе создать пользователя, то такой пользователь получит излишние привилегии. Это же относится к псевдо-пользователям сервисов хост-системы и аналогичным в контейнерах (совпадение uid). Правда, роль играет еще флаг dumpable (который в privsep children обычно оказывается сброшен), да и, похоже, защита от ptrace(2) с хост-системы теперь появилась (только что проверил на недавнем ядре из rhel5-ветки: kill процесса с тем же uid в контейнере прошел, а вот ptrace уже нет; насколько я помню, раньше проходил и ptrace тоже). Но формально об изменении политики заявлено не было, так что это скорее hardening. Реально это относится прежде всего к ситуациям, когда на системе уже что-то было, а потом, не убирая этого, ядро заменили на OpenVZ'ное и стали еще и создавать контейнеры. Настроенные таким образом системы подвергают пользователей и сервисы в контейнерах дополнительному риску атак со стороны пользователей и сервисов хост-системы. > Получается что такая система как Proxmox VE потенциально небезопасна согласно политики OpenVZ? Я не в курсе деталей, но мне представляется что там риск оправданный - т.е. всё, что делается на хост-системе, относится к администрированию контейнеров. (Разве что администрирование еще и виртуальных машин KVM можно посчитать неоправданным риском для систем в OpenVZ-контейнерах, но и тут есть некоторый смысл в этой универсальности, что может оправдывать риск.) Они могли бы этот риск снизить выбрав для своего веб-интерфейса диапазон uid, обычно в контейнерах не используемый. (Сделали ли они так или нет - не знаю. Я сам Proxmox VE пока не использовал.)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	66. "Уязвимость, позволяющая получить доступ к диску хост-системы..."	+/–
	Сообщение от alex.h (??) on 07-Янв-12, 02:10
	Спасибо за развёрнутый ответ! Изначально я подумал что существует обратная опасность, т.е. повлиять на сервисы хост-сиситемы из контейнера.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема