Root-уязвимость в инструментарии управления пакетами Snap
Автор
Сообщение
news_bot ®
Стаж: 6 лет 2 месяца
Сообщений: 27286
Компания Qualys выявила третью в этому году опасную уязвимость (CVE-2022-3328) в утилите snap-confine, поставляемой с флагом SUID root и вызываемой процессом snapd для формирования исполняемого окружения для приложений, распространяемых в самодостаточных пакетах в формате snap. Уязвимость позволяет локальному непривилегированному пользователю добиться выполнения кода с правами root в конфигурации Ubuntu по умолчанию. Проблема устранена в выпуске snapd 2.57.6. Обновления пакетов выпущены для всех поддерживаемых веток Ubuntu.
Интересно, что рассматриваемая уязвимость была внесена в процессе исправления похожей февральской уязвимости в snap-confine. Исследователям удалось подготовить рабочий эксплоит, предоставляющий root-доступ в Ubuntu Server 22.04, в котором кроме уязвимости в snap-confine также задействованы две уязвимости в процессе multipathd (CVE-2022-41974, CVE-2022-41973), связанные с обходом проверки полномочий при передаче привилегированных команд и небезопасной работой с символическими ссылками.
Уязвимость в snap-confine вызвана состоянием гонки в функции must_mkdir_and_open_with_perms(), добавленной для защиты от подмены каталога /tmp/snap.$SNAP_NAME на символическую ссылку в момент после проверки владельца, но перед обращением к системному вызову mount для bind-монтирования в него каталогов для пакета в формате snap. Добавленная защита сводилась к переименованию каталога /tmp/snap.$SNAP_NAME в другой каталог в /tmp со случайным именем, если он существует и не принадлежит пользователю root.
При эксплуатации операции переименования каталога /tmp/snap.$SNAP_NAME исследователи воспользовались тем, что snap-confine также создаёт каталог /tmp/snap.rootfs_XXXXXX для корня содержимого пакета snap. Часть "XXXXXX" в имени выбирается случайно при помощи mkdtemp(), но пакет с именем "rootfs_XXXXXX" может пройти проверку в функции sc_instance_name_validate (т.е. идея в том, чтобы имя $SNAP_NAME приняло значение "rootfs_XXXXXX" и тогда операция переименования приведёт к перезаписи каталога /tmp/snap.rootfs_XXXXXX с корнем snap).
Для того чтобы добиться одновременного использования /tmp/snap.rootfs_XXXXXX и переименования /tmp/snap.$SNAP_NAME было запущено два экземпляра snap-confine. Как только первый экземпляр создавал /tmp/snap.rootfs_XXXXXX процесс блокировался и запускался второй экземпляр с именем пакета rootfs_XXXXXX, что приводило к тому, что временный каталог /tmp/snap.$SNAP_NAME второго экземпляра становился корневым каталогом /tmp/snap.rootfs_XXXXXX первого. Сразу после выполнения переименования второй экземпляр аварийно завершался, а /tmp/snap.rootfs_XXXXXX подменялся с манипуляцией состоянием гонки, как при эксплуатации февральской уязвимости. После подмены с первого экземпляра снималась блокировка выполнения и атакующие получали полный контроль над корневым каталогом snap.
На последнем этапе создавалась символическая ссылка /tmp/snap.rootfs_XXXXXX/tmp, которая использовалась функцией sc_bootstrap_mount_namespace() для bind-монтирования доступного на запись реального каталога /tmp в любой каталог ФС, так как вызов mount() следует символическим ссылкам перед монтированием. Подобное монтирование блокируется ограничениями AppArmor, но для обхода этой блокировки в эксплоите были задействован две вспомогательные уязвимости в multipathd.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://blog.qualys.com/vulner...)
- OpenNews: Локальные root-уязвимости в инструментарии управления пакетами Snap
- OpenNews: Критическая уязвимость в PolKit, позволяющая получить root-доступ в большинстве дистрибутивов Linux
- OpenNews: Уязвимость во Flatpak, позволяющая повысить привилегии в системе
- OpenNews: Обновление Flatpak 1.10.2 с устранением уязвимости, нарушающей sandbox-изоляцию
- OpenNews: Опасные уязвимости в утилитах beep и patch
Похожие новости:
- Предложен механизм blksnap для создания снапшотов блочных устройств в Linux
- Разработчики Ubuntu приступили к решению проблем с медленным запуском snap-пакета Firefox
- Проект Celestial развивает сборку Ubuntu с Flatpak вместо Snap
- Браузер Firefox будет поставляться в Ubuntu 22.04 LTS только в формате Snap
- Локальные root-уязвимости в инструментарии управления пакетами Snap
- Компания Canonical анонсировала переработку инструментария Snapcraft
- [Дизайн мобильных приложений, Законодательство в IT, Социальные сети и сообщества] Snapchat удаляет фильтр спидометра из-за юридических проблем
- [] До 40 релизов в день в Enterprise: наша сool story
- [Настройка Linux, Резервное копирование, Разработка под Linux] Linux kernel: просто снять снапшот не просто
- [Компьютерное железо, Презентации, Ноутбуки] Samsung представила ноутбуки на Windows 10 с процессорами Arm
Теги для поиска: #_suid, #_qualys, #_snap
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 19-Апр 12:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 2 месяца |
|
|
Компания Qualys выявила третью в этому году опасную уязвимость (CVE-2022-3328) в утилите snap-confine, поставляемой с флагом SUID root и вызываемой процессом snapd для формирования исполняемого окружения для приложений, распространяемых в самодостаточных пакетах в формате snap. Уязвимость позволяет локальному непривилегированному пользователю добиться выполнения кода с правами root в конфигурации Ubuntu по умолчанию. Проблема устранена в выпуске snapd 2.57.6. Обновления пакетов выпущены для всех поддерживаемых веток Ubuntu. Интересно, что рассматриваемая уязвимость была внесена в процессе исправления похожей февральской уязвимости в snap-confine. Исследователям удалось подготовить рабочий эксплоит, предоставляющий root-доступ в Ubuntu Server 22.04, в котором кроме уязвимости в snap-confine также задействованы две уязвимости в процессе multipathd (CVE-2022-41974, CVE-2022-41973), связанные с обходом проверки полномочий при передаче привилегированных команд и небезопасной работой с символическими ссылками. Уязвимость в snap-confine вызвана состоянием гонки в функции must_mkdir_and_open_with_perms(), добавленной для защиты от подмены каталога /tmp/snap.$SNAP_NAME на символическую ссылку в момент после проверки владельца, но перед обращением к системному вызову mount для bind-монтирования в него каталогов для пакета в формате snap. Добавленная защита сводилась к переименованию каталога /tmp/snap.$SNAP_NAME в другой каталог в /tmp со случайным именем, если он существует и не принадлежит пользователю root. При эксплуатации операции переименования каталога /tmp/snap.$SNAP_NAME исследователи воспользовались тем, что snap-confine также создаёт каталог /tmp/snap.rootfs_XXXXXX для корня содержимого пакета snap. Часть "XXXXXX" в имени выбирается случайно при помощи mkdtemp(), но пакет с именем "rootfs_XXXXXX" может пройти проверку в функции sc_instance_name_validate (т.е. идея в том, чтобы имя $SNAP_NAME приняло значение "rootfs_XXXXXX" и тогда операция переименования приведёт к перезаписи каталога /tmp/snap.rootfs_XXXXXX с корнем snap). Для того чтобы добиться одновременного использования /tmp/snap.rootfs_XXXXXX и переименования /tmp/snap.$SNAP_NAME было запущено два экземпляра snap-confine. Как только первый экземпляр создавал /tmp/snap.rootfs_XXXXXX процесс блокировался и запускался второй экземпляр с именем пакета rootfs_XXXXXX, что приводило к тому, что временный каталог /tmp/snap.$SNAP_NAME второго экземпляра становился корневым каталогом /tmp/snap.rootfs_XXXXXX первого. Сразу после выполнения переименования второй экземпляр аварийно завершался, а /tmp/snap.rootfs_XXXXXX подменялся с манипуляцией состоянием гонки, как при эксплуатации февральской уязвимости. После подмены с первого экземпляра снималась блокировка выполнения и атакующие получали полный контроль над корневым каталогом snap. На последнем этапе создавалась символическая ссылка /tmp/snap.rootfs_XXXXXX/tmp, которая использовалась функцией sc_bootstrap_mount_namespace() для bind-монтирования доступного на запись реального каталога /tmp в любой каталог ФС, так как вызов mount() следует символическим ссылкам перед монтированием. Подобное монтирование блокируется ограничениями AppArmor, но для обхода этой блокировки в эксплоите были задействован две вспомогательные уязвимости в multipathd. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 19-Апр 12:09
Часовой пояс: UTC + 5