Qualys hat die dritte gefährliche Schwachstelle in diesem Jahr (CVE-2022-3328) im Dienstprogramm snap-confine identifiziert, das mit dem SUID-Root-Flag ausgestattet ist und vom snapd-Prozess aufgerufen wird, um eine ausführbare Umgebung für Anwendungen zu erstellen, die in eigenständigen Paketen verteilt werden im Snap-Format. Die Sicherheitslücke ermöglicht es einem lokalen, nicht privilegierten Benutzer, die Codeausführung als Root in der Standard-Ubuntu-Konfiguration zu erreichen. Das Problem wurde in der Snapd-Version 2.57.6 behoben. Für alle unterstützten Ubuntu-Zweige wurden Paketaktualisierungen veröffentlicht.
Interessanterweise wurde die betreffende Sicherheitslücke während des Behebungsprozesses einer ähnlichen Sicherheitslücke im Februar in Snap-Confine eingeführt. Forscher konnten einen funktionierenden Exploit vorbereiten, der Root-Zugriff auf Ubuntu Server 22.04 ermöglicht, der neben der Schwachstelle in Snap-Confine auch zwei Schwachstellen im Multipathd-Prozess beinhaltet (CVE-2022-41974, CVE-2022-41973). , verbunden mit der Umgehung der Autoritätsprüfung bei der Übertragung privilegierter Befehle und unsicherer Arbeit mit symbolischen Links.
Die Schwachstelle in snap-confine wird durch eine Race-Bedingung in der Funktion „must_mkdir_and_open_with_perms()“ verursacht, die zum Schutz vor der Ersetzung des Verzeichnisses /tmp/snap.$SNAP_NAME durch einen symbolischen Link hinzugefügt wurde, nachdem der Besitzer überprüft wurde, aber bevor das Mount-System aufgerufen wurde Aufruf zum Binden von Verzeichnissen darin für ein Paket im Snap-Format. Der zusätzliche Schutz bestand darin, das Verzeichnis /tmp/snap.$SNAP_NAME in ein anderes Verzeichnis in /tmp mit einem zufälligen Namen umzubenennen, wenn es existiert und nicht im Besitz von Root ist.
Bei der Ausnutzung der Verzeichnisumbenennungsoperation „/tmp/snap.$SNAP_NAME“ machten sich die Forscher die Tatsache zunutze, dass „snap-confine“ auch ein Verzeichnis „/tmp/snap.rootfs_XXXXXX“ für das Stammverzeichnis des Inhalts des Snap-Pakets erstellt. Der „XXXXXX“-Teil des Namens wird von mkdtemp() zufällig ausgewählt, aber ein Paket mit dem Namen „rootfs_XXXXXX“ kann in der sc_instance_name_validate-Funktion validiert werden (d. h. die Idee ist, dass $SNAP_NAME auf „rootfs_XXXXXX“ gesetzt wird und dann der Umbenennungsvorgang ausgeführt wird führt dazu, dass das Verzeichnis /tmp/snap.rootfs_XXXXXX mit dem Root-Snap überschrieben wird.
Um die gleichzeitige Verwendung von /tmp/snap.rootfs_XXXXXX und die Umbenennung von /tmp/snap.$SNAP_NAME zu erreichen, wurden zwei Instanzen von snap-confine gestartet. Sobald die erste Instanz /tmp/snap.rootfs_XXXXXX erstellt hatte, wurde der Prozess blockiert und eine zweite Instanz würde mit dem Paketnamen rootfs_XXXXXX beginnen, wodurch das temporäre Verzeichnis /tmp/snap.$SNAP_NAME der zweiten Instanz zum Stammverzeichnis /tmp/snap wurde .rootfs_XXXXXX des ersten. Unmittelbar nach Abschluss der Umbenennung stürzte die zweite Instanz ab und /tmp/snap.rootfs_XXXXXX wurde durch eine Race-Condition-Manipulation ersetzt, wie bei der Ausnutzung der Februar-Schwachstelle. Nach der Ersetzung wurde die Ausführungssperre von der ersten Instanz entfernt und die Angreifer erlangten die volle Kontrolle über das Snap-Root-Verzeichnis.
Der letzte Schritt bestand darin, einen Symlink /tmp/snap.rootfs_XXXXXX/tmp zu erstellen, der seit dem Aufruf von mount() von der Funktion sc_bootstrap_mount_namespace() verwendet wurde, um das beschreibbare reale Verzeichnis /tmp an ein beliebiges Verzeichnis im Dateisystem zu binden Folgt Symlinks vor dem Mounten. Ein solches Mounten wird durch AppArmor-Einschränkungen blockiert, aber um diesen Block zu umgehen, nutzte der Exploit zwei zusätzliche Schwachstellen in multipathd.
Source: opennet.ru