Das Unternehmen Qualys hat eine dritte gefährliche Sicherheitsanfälligkeit in diesem Jahr (CVE-2022-3328) in dem Tool snap-confine entdeckt, das mit dem SUID-Root-Flag geliefert wird und vom Prozess snapd aufgerufen wird, um eine Ausführungsumgebung für in selbständigen Paketen im Snap-Format verteilte Anwendungen zu erstellen. Die Sicherheitsanfälligkeit erlaubt es einem lokalen unprivilegierten Benutzer, Code mit Root-Rechten in der Standardkonfiguration von Ubuntu auszuführen. Das Problem wurde mit der Veröffentlichung von snapd 2.57.6 behoben. Pakete-Updates wurden für alle unterstützten Ubuntu-Versionen bereitgestellt.
Interessanterweise wurde die betreffende Sicherheitsanfälligkeit im Zuge der Behebung einer ähnlichen Sicherheitsanfälligkeit im Februar in snap-confine festgestellt. Die Forscher konnten einen funktionierenden Exploit entwickeln, der Root-Zugriff auf Ubuntu Server 22.04 gewährt; hierbei sind neben der Sicherheitsanfälligkeit in snap-confine auch zwei Sicherheitsanfälligkeiten im Prozess multipathd (CVE-2022-41974, CVE-2022-41973) beteiligt, die mit der Umgehung der Berechtigungsprüfung bei der Übertragung von privilegierten Befehlen und unsicherem Umgang mit symbolischen Links verbunden sind.
Die Schwachstelle in snap-confine wird durch einen Race Condition in der Funktion must_mkdir_and_open_with_perms() verursacht, die zum Schutz vor der Umgehung des Verzeichnisses /tmp/snap.$SNAP_NAME auf einen symbolischen Link hinzugefügt wurde, und zwar nach der Überprüfung des Eigentümers, aber bevor der Systemaufruf mount aufgerufen wird, um Verzeichnisse für das Snap-Paket einzubinden. Der hinzugefügte Schutz bestand darin, das Verzeichnis /tmp/snap.$SNAP_NAME in ein anderes Verzeichnis mit einem zufälligen Namen im /tmp umzubenennen, sofern es existiert und nicht dem Benutzer root gehört.
Bei der Ausnutzung der Umbenennung des Verzeichnisses /tmp/snap.$SNAP_NAME nutzten die Forscher aus, dass snap-confine auch ein Verzeichnis /tmp/snap.rootfs_XXXXXX für den Root-Inhalt des Snap-Pakets erstellt. Der Teil „XXXXXX“ im Namen wird zufällig mit mkdtemp() ausgewählt, aber ein Paket mit dem Namen „rootfs_XXXXXX“ kann 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 somit die Umbenennung zu einer Überschreibung des Verzeichnisses /tmp/snap.rootfs_XXXXXX mit dem Root des Snap führt).
Um die gleichzeitige Verwendung von /tmp/snap.rootfs_XXXXXX und die Umbenennung von /tmp/snap.$SNAP_NAME zu ermöglichen, wurden zwei Instanzen von snap-confine gestartet. Sobald die erste Instanz /tmp/snap.rootfs_XXXXXX erstellte, 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 abgestürzt, und /tmp/snap.rootfs_XXXXXX wurde durch Manipulation des Race Conditions ausgetauscht, ähnlich wie bei der Ausnutzung der Sicherheitsanfälligkeit im Februar. Nach dem Austausch wurde die Ausführungsblockierung der ersten Instanz aufgehoben und Angreifer erhielten die volle Kontrolle über das Wurzelverzeichnis von snap.
In der letzten Phase wurde ein symbolischer Link /tmp/snap.rootfs_XXXXXX/tmp erstellt, der von der Funktion sc_bootstrap_mount_namespace() verwendet wurde, um das schreibbare reale Verzeichnis /tmp in jedes beliebige Verzeichnis des Dateisystems zu binden. Da der Aufruf von mount() symbolischen Links vor dem Mounten folgt, wird ein solches Mounten durch AppArmor-Beschränkungen blockiert. Um diese Blockade zu umgehen, wurden im Exploit zwei unterstützende Schwachstellen in multipathd genutzt.
Quelle: opennet.ru
