Das Unternehmen Qualys hat eine dritte gefĂ€hrliche SicherheitsanfĂ€lligkeit (CVE-2022-3328) in dem mit dem SUID-root-Flag gelieferten Tool snap-confine entdeckt, das vom snapd-Prozess aufgerufen wird, um eine AusfĂŒhrungsumgebung fĂŒr in eigenstĂ€ndigen Snap-Paketen verteilte Anwendungen zu schaffen. Die SicherheitsanfĂ€lligkeit ermöglicht es einem lokalen, nicht privilegierten Benutzer, Code mit Root-Rechten in der Standardkonfiguration von Ubuntu auszufĂŒhren. Das Problem wurde in der Version snapd 2.57.6 behoben. Updates von Paketen wurden fĂŒr alle unterstĂŒtzten Ubuntu-Versionen veröffentlicht.
Interessanterweise wurde die betreffende SicherheitsanfĂ€lligkeit im Rahmen der Behebung einer Ă€hnlichen SicherheitsanfĂ€lligkeit im Februar in snap-confine eingefĂŒhrt. Den Forschern ist es gelungen, einen funktionierenden Exploit vorzubereiten, der Root-Zugriff auf Ubuntu Server 22.04 ermöglicht. Dabei wurden neben der SicherheitsanfĂ€lligkeit in snap-confine auch zwei SicherheitsanfĂ€lligkeiten im Prozess multipathd (CVE-2022-41974, CVE-2022-41973) ausgenutzt, die mit dem Umgehen der BerechtigungsĂŒberprĂŒfung beim Ăbermitteln privilegierter Befehle und der unsicheren Handhabung von symbolischen Links zusammenhĂ€ngen.
Die SicherheitsanfĂ€lligkeit in snap-confine wird durch einen Race Condition in der Funktion must_mkdir_and_open_with_perms() verursacht, die zum Schutz vor dem Austausch des Verzeichnisses /tmp/snap.$SNAP_NAME durch einen symbolischen Link hinzugefĂŒgt wurde, und zwar nach der ĂberprĂŒfung des EigentĂŒmers, jedoch vor dem Aufruf des Systemaufrufs mount, um die Verzeichnisse fĂŒr das Snap-Paket zu binden. Der hinzugefĂŒgte Schutz bestand darin, das Verzeichnis /tmp/snap.$SNAP_NAME in ein anderes Verzeichnis in /tmp mit einem zufĂ€lligen Namen umzubenennen, falls es existierte und nicht dem Benutzer root gehörte.
Beim Ausnutzen der Umbenennungsoperation des Verzeichnisses /tmp/snap.$SNAP_NAME machten die Forscher sich zunutze, dass snap-confine auch das Verzeichnis /tmp/snap.rootfs_XXXXXX fĂŒr den Root-Inhalt des Snap-Pakets erstellt. Der Teil âXXXXXXâ im Namen wird zufĂ€llig durch mkdtemp() ausgewĂ€hlt, jedoch kann ein Paket mit dem Namen ârootfs_XXXXXXâ die ĂberprĂŒfung in der Funktion sc_instance_name_validate bestehen (d.h. die Idee ist, dass der Name $SNAP_NAME den Wert ârootfs_XXXXXXâ annimmt und die Umbenennungsoperation dann dazu fĂŒhrt, dass das Verzeichnis /tmp/snap.rootfs_XXXXXX mit dem Root des Snap ĂŒberschrieben wird).
Um eine gleichzeitige Nutzung von /tmp/snap.rootfs_XXXXXX und der Umbenennung von /tmp/snap.$SNAP_NAME zu erreichen, wurden zwei Instanzen von snap-confine gestartet. Sobald die erste Instanz /tmp/snap.rootfs_XXXXXX erzeugte, wurde der Prozess blockiert und die zweite Instanz mit dem Paketnamen rootfs_XXXXXX gestartet, was dazu fĂŒhrte, dass das temporĂ€re Verzeichnis /tmp/snap.$SNAP_NAME der zweiten Instanz zum Wurzelverzeichnis /tmp/snap.rootfs_XXXXXX der ersten wurde. Unmittelbar nach der Umbenennung wurde die zweite Instanz abrupt beendet, und /tmp/snap.rootfs_XXXXXX wurde mit einer Zustandsmanipulation wĂ€hrend eines Race Conditions ersetzt, Ă€hnlich wie bei der Ausnutzung der Februar-Schwachstelle. Nach der Ersetzung wurde die AusfĂŒhrungsblockade von der ersten Instanz entfernt, und die Angreifer erhielten die volle Kontrolle ĂŒber das Wurzelverzeichnis des Snap.
In der letzten Phase wurde ein symbolischer Link /tmp/snap.rootfs_XXXXXX/tmp erstellt, der von der Funktion sc_bootstrap_mount_namespace() zum Bindemount des beschreibbaren echten Verzeichnisses /tmp in jedes Verzeichnis des Dateisystems verwendet wurde, da der Aufruf von mount() vor dem Mounten den symbolischen Links folgt. Ein solches Mounten wird durch AppArmor-BeschrÀnkungen blockiert, doch um diese Blockade zu umgehen, wurden im Exploit zwei weitere Schwachstellen in multipathd ausgenutzt.
Quelle: opennet.ru
