Ранливост на коренот во пакетот алатки за управување со пакети Snap

Qualys ја идентификуваше третата опасна ранливост оваа година (CVE-2022-3328) во алатката snap-confine, која доаѓа со коренското знаменце SUID и е повикана од процесот 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 да стане root директориум /tmp/snap .rootfs_XXXXXX од првиот. Веднаш по завршувањето на преименувањето, вториот примерок падна и /tmp/snap.rootfs_XXXXXX беше заменет со манипулација со условите за раса, како кога се искористуваше ранливоста од февруари. По замената, бравата за извршување беше отстранета од првата инстанца и напаѓачите добија целосна контрола над snap root директориумот.

Последниот чекор беше да се создаде симболична врска /tmp/snap.rootfs_XXXXXX/tmp, која беше искористена од функцијата sc_bootstrap_mount_namespace() за да се поврзе-монтира вистинскиот директориум /tmp за кој било директориум во датотечниот систем, бидејќи повикот mount() ги следи симболите пред да се монтира. Таквото монтирање е блокирано од ограничувањата на AppArmor, но за да се заобиколи овој блок, експлоатот користеше две помошни пропусти во повеќепатиштата.

Извор: opennet.ru

Додадете коментар