Компанія 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/snaXXX. Відразу після перейменування другий екземпляр аварійно завершувався, а /tmp/snap.rootfs_XXXXXX підмінявся з маніпуляцією станом гонки, як при експлуатації лютневої вразливості. Після підміни з першого екземпляра знімалося блокування виконання та атакуючі отримували повний контроль над кореневим каталогом snap.
На останньому етапі створювалося символічне посилання /tmp/snap.rootfs_XXXXXX/tmp, яке використовувалося функцією sc_bootstrap_mount_namespace() для bind-монтування доступного на запис реального каталогу /tmp в будь-який каталог ФС, так як виклик mount() слідує символічним посиланням перед монт. Подібне монтування блокується обмеженнями AppArmor, але для обходу цього блокування в експлоїті були задіяні дві допоміжні вразливості multipathd.
Джерело: opennet.ru