Root уязвимост в инструменти за управление на пакети Snap

Компания 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 за свързване на директории за пакета в формат 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