Rotsårbarhet i Snap-pakethanteringsverktyget

Qualys har identifierat den tredje farliga sårbarheten i år (CVE-2022-3328) i snap-confine-verktyget, som kommer med SUID-rotflaggan och anropas av snapd-processen för att skapa en körbar miljö för applikationer distribuerade i fristående paket i snap-format. Sårbarheten tillåter en lokal oprivilegierad användare att få kodexekvering som root i standardkonfigurationen för Ubuntu. Problemet är åtgärdat i snapd 2.57.6-versionen. Paketuppdateringar har släppts för alla grenar av Ubuntu som stöds.

Intressant nog introducerades sårbarheten i fråga under processen att fixa en liknande sårbarhet i februari i snap-confine. Forskare kunde förbereda en fungerande exploatering som ger root-åtkomst till Ubuntu Server 22.04, som, förutom sårbarheten i snap-confine, också involverar två sårbarheter i flervägsprocessen (CVE-2022-41974, CVE-2022-41973) , förknippad med att kringgå auktoritetskontrollen vid överföring av privilegierade kommandon och osäkert arbete med symboliska länkar.

Sårbarheten i snap-confine orsakas av ett rastillstånd i funktionen must_mkdir_and_open_with_perms() som lagts till för att skydda mot ersättning av katalogen /tmp/snap.$SNAP_NAME med en symbolisk länk efter att ha kontrollerat ägaren, men innan monteringssystemet anropas anrop till bind-mount kataloger i den för ett paket i snap-format. Det extra skyddet var att byta namn på katalogen /tmp/snap.$SNAP_NAME till en annan katalog i /tmp med ett slumpmässigt namn om den finns och inte ägs av root.

När forskarna utnyttjade operationen /tmp/snap.$SNAP_NAME katalogbyte, utnyttjade forskarna det faktum att snap-confine också skapar en /tmp/snap.rootfs_XXXXXX-katalog för roten av snap-paketets innehåll. "XXXXXX"-delen av namnet väljs slumpmässigt av mkdtemp(), men ett paket med namnet "rootfs_XXXXXX" kan valideras i sc_instance_name_validate-funktionen (dvs tanken är att $SNAP_NAME kommer att ställas in på "rootfs_XXXXXX" och sedan byt namn på operationen kommer att resultera i att katalogen /tmp/snap.rootfs_XXXXXX skrivs över med root-snäppet).

För att uppnå samtidig användning av /tmp/snap.rootfs_XXXXXX och byta namn på /tmp/snap.$SNAP_NAME, lanserades två instanser av snap-confine. När den första instansen skapade /tmp/snap.rootfs_XXXXXX, skulle processen blockeras och en andra instans skulle börja med paketnamnet rootfs_XXXXXX, vilket gör att den andra instansens temporära katalog /tmp/snap.$SNAP_NAME blir rotkatalogen /tmp/snap .rootfs_XXXXXX av de första. Omedelbart efter att namnbytet slutförts kraschade den andra instansen och /tmp/snap.rootfs_XXXXXX ersattes med manipulation av rasvillkor, som när man utnyttjade sårbarheten i februari. Efter ersättningen togs exekveringslåset bort från första instans och angriparna fick full kontroll över snaprotkatalogen.

Det sista steget var att skapa en symbollänk /tmp/snap.rootfs_XXXXXX/tmp, som användes av funktionen sc_bootstrap_mount_namespace() för att bind-mounta den skrivbara riktiga katalogen /tmp till valfri katalog i filsystemet, eftersom mount() anropar följer symbollänkar innan montering. Sådan montering blockeras av AppArmor-restriktioner, men för att kringgå detta block använde exploateringen två extra sårbarheter i multipathd.

Källa: opennet.ru

Lägg en kommentar