Qualys har identifisert en tredje alvorlig sårbarhet i år (CVE-2022-3328) i snap-confine-verktøyet, som kommer med SUID-rotflagget og kalles opp av snapd-prosessen for å danne et kjørbart miljø for applikasjoner distribuert i selvstendige pakker i snap-format. Sårbarheten lar en lokal uprivilegert bruker oppnå kodekjøring som root i standard Ubuntu-konfigurasjon. Problemet er løst i utgivelsen av snapd 2.57.6. Pakkeoppdateringer er utgitt for alle støttede grener av Ubuntu.
Interessant nok ble den aktuelle sårbarheten introdusert i prosessen med å fikse en lignende februar-sårbarhet i snap-confine. Forskerne var i stand til å forberede en fungerende utnyttelse som gir root-tilgang i Ubuntu Server 22.04, som, i tillegg til snap-confine-sårbarheten, også involverer to sårbarheter i multipathd-prosessen (CVE-2022-41974, CVE-2022-41973) relatert til omgåelse av tillatelser ved overføring av privilegerte kommandoer og usikker håndtering av symbolske lenker.
Sårbarheten i snap-confine er forårsaket av en rasetilstand i must_mkdir_and_open_with_perms()-funksjonen, lagt til for å beskytte mot erstatning av katalogen /tmp/snap.$SNAP_NAME for en symbolsk lenke etter eiersjekken, men før mount-systemkallet kalles for å binde-montere kataloger inn i den for en pakke i snap-format. Sikkerheten som ble lagt til var å gi nytt navn til katalogen /tmp/snap.$SNAP_NAME til en annen katalog i /tmp med et tilfeldig navn hvis den eksisterer og ikke eies av rotbrukeren.
Da forskerne utnyttet operasjonen /tmp/snap.$SNAP_NAME-katalogendringen, utnyttet forskerne det faktum at snap-confine også oppretter en /tmp/snap.rootfs_XXXXXX-katalog for roten til innholdet i snap-pakken. "XXXXXX"-delen av navnet velges tilfeldig av mkdtemp(), men en pakke som heter "rootfs_XXXXXX" kan sende sc_instance_name_validate (dvs. ideen er å ha $SNAP_NAME satt til "rootfs_XXXXXX", og deretter vil rename-operasjonen resultere i overskriving katalogen /tmp/snap.rootfs_XXXXXX med snaproten).
For å oppnå samtidig bruk av /tmp/snap.rootfs_XXXXXX og gi nytt navn til /tmp/snap.$SNAP_NAME, ble to forekomster av snap-confine startet. Så snart den første forekomsten opprettet /tmp/snap.rootfs_XXXXXX, ville prosessen blokkere og en andre forekomst med pakkenavnet rootfs_XXXXXX ville starte, noe som førte til at den andre forekomstens midlertidige katalog /tmp/snap.$SNAP_NAME ble /tmp/snap .rootfs_XXXXXX rotkatalogen for den første forekomsten. Umiddelbart etter at omnavnet ble utført, krasjet den andre forekomsten, og /tmp/snap.rootfs_XXXXXX ble erstattet med manipulasjon av rasetilstand, som i utnyttelsen av februar-sårbarheten. Etter endringen ble utførelseslåsen fjernet fra første instans og angriperne fikk full kontroll over snaprotkatalogen.
Det siste trinnet var å lage en symbolkobling /tmp/snap.rootfs_XXXXXX/tmp som ble brukt av sc_bootstrap_mount_namespace()-funksjonen for å bind-mounte den skrivbare virkelige katalogen /tmp til en hvilken som helst katalog i filsystemet, siden mount()-kallet følger symbollinker før montering. Slik montering er blokkert av AppArmor-restriksjoner, men for å omgå denne blokkeringen, utnyttet de to hjelpesårbarhetene i multipathd.
Kilde: opennet.ru