Das Unternehmen Qualys hat eine dritte gef\u00e4hrliche Sicherheitsanf\u00e4lligkeit (CVE-2022-3328) in dem mit dem SUID-root-Flag gelieferten Tool snap-confine entdeckt, das vom snapd-Prozess aufgerufen wird, um eine Ausf\u00fchrungsumgebung f\u00fcr in eigenst\u00e4ndigen Snap-Paketen verteilte Anwendungen zu schaffen. Die Sicherheitsanf\u00e4lligkeit erm\u00f6glicht es einem lokalen, nicht privilegierten Benutzer, Code mit Root-Rechten in der Standardkonfiguration von Ubuntu auszuf\u00fchren. Das Problem wurde in der Version snapd 2.57.6 behoben. Updates von Paketen wurden f\u00fcr alle unterst\u00fctzten Ubuntu-Versionen ver\u00f6ffentlicht. <\/p>\n
Interessanterweise wurde die betreffende Sicherheitsanf\u00e4lligkeit im Rahmen der Behebung einer \u00e4hnlichen Sicherheitsanf\u00e4lligkeit im Februar in snap-confine eingef\u00fchrt. Den Forschern ist es gelungen, einen funktionierenden Exploit vorzubereiten, der Root-Zugriff auf Ubuntu Server 22.04 erm\u00f6glicht. Dabei wurden neben der Sicherheitsanf\u00e4lligkeit in snap-confine auch zwei Sicherheitsanf\u00e4lligkeiten im Prozess multipathd (CVE-2022-41974, CVE-2022-41973) ausgenutzt, die mit dem Umgehen der Berechtigungs\u00fcberpr\u00fcfung beim \u00dcbermitteln privilegierter Befehle und der unsicheren Handhabung von symbolischen Links zusammenh\u00e4ngen. <\/p>\n
Die Sicherheitsanf\u00e4lligkeit 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\u00fcgt wurde, und zwar nach der \u00dcberpr\u00fcfung des Eigent\u00fcmers, jedoch vor dem Aufruf des Systemaufrufs mount, um die Verzeichnisse f\u00fcr das Snap-Paket zu binden. Der hinzugef\u00fcgte Schutz bestand darin, das Verzeichnis \/tmp\/snap.$SNAP_NAME in ein anderes Verzeichnis in \/tmp mit einem zuf\u00e4lligen Namen umzubenennen, falls es existierte und nicht dem Benutzer root geh\u00f6rte. <\/p>\n
Bei der Durchf\u00fchrung der Umbenennungsoperation des Verzeichnisses \/tmp\/snap.$SNAP_NAME nutzten die Forscher aus, dass snap-confine ebenfalls das Verzeichnis \/tmp\/snap.rootfs_XXXXXX f\u00fcr den Wurzelinhalt des Snap-Pakets erstellt. Der Teil «XXXXXX» im Namen wird zuf\u00e4llig mit mkdtemp() ausgew\u00e4hlt, aber das Paket mit dem Namen «rootfs_XXXXXX» kann in der Funktion sc_instance_name_validate \u00fcberpr\u00fcft werden (d.h. die Idee ist, dass der Name $SNAP_NAME den Wert «rootfs_XXXXXX» annimmt und die Umbenennungsoperation dann dazu f\u00fchrt, dass das Verzeichnis \/tmp\/snap.rootfs_XXXXXX mit dem Wurzel-Snap \u00fcberschrieben wird). <\/p>\n
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\u00fchrte, dass das tempor\u00e4re 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\u00e4hrend eines Race Conditions ersetzt, \u00e4hnlich wie bei der Ausnutzung der Februar-Schwachstelle. Nach der Ersetzung wurde die Ausf\u00fchrungsblockade von der ersten Instanz entfernt, und die Angreifer erhielten die volle Kontrolle \u00fcber das Wurzelverzeichnis des Snap. <\/p>\n