Основна уязвимост в инструментариума за управление на пакети 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 включва и две уязвимости в многопътния процес (CVE-2022-41974, CVE-2022-41973) , свързани с заобикаляне на проверката за правомощия при предаване на привилегировани команди и опасна работа със символни връзки.

Уязвимостта в snap-confine е причинена от условие за състезание във функцията must_mkdir_and_open_with_perms(), добавена за защита срещу заместване на директорията /tmp/snap.$SNAP_NAME със символна връзка след проверка на собственика, но преди извикване на системата за монтиране извикване за свързване на директории за монтиране в него за пакет във формат 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 с root 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() за свързване-монтиране на записваемата реална директория /tmp към всяка директория във файловата система, тъй като извикването mount() следва символни връзки преди монтиране. Такова монтиране е блокирано от ограниченията на AppArmor, но за да заобиколи този блок, експлойтът използва две спомагателни уязвимости в multipathd.

Източник: opennet.ru