{"id":105785,"date":"2022-12-02T15:36:49","date_gmt":"2022-12-02T13:36:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/root-uyazvimost-v-instrumentarii-upravleniya-paketami-snap"},"modified":"2022-12-02T15:36:49","modified_gmt":"2022-12-02T13:36:49","slug":"root-uyazvimost-v-instrumentarii-upravleniya-paketami-snap","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/root-uyazvimost-v-instrumentarii-upravleniya-paketami-snap","title":{"rendered":"Root-Sicherheitsl\u00fccke im Paketverwaltungswerkzeug Snap","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Qualys hat eine dritte gef\u00e4hrliche Sicherheitsanf\u00e4lligkeit 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\u00fchrungsumgebung f\u00fcr in selbst\u00e4ndigen Paketen im Snap-Format verteilte Anwendungen zu erstellen. Die Sicherheitsanf\u00e4lligkeit erlaubt es einem lokalen unprivilegierten Benutzer, Code mit Root-Rechten in der Standardkonfiguration von Ubuntu auszuf\u00fchren. Das Problem wurde mit der Ver\u00f6ffentlichung von snapd 2.57.6 behoben. Pakete-Updates wurden f\u00fcr alle unterst\u00fctzten Ubuntu-Versionen bereitgestellt. <\/p>\n
Interessanterweise wurde die betreffende Sicherheitsanf\u00e4lligkeit im Zuge der Behebung einer \u00e4hnlichen Sicherheitsanf\u00e4lligkeit im Februar in snap-confine festgestellt. Die Forscher konnten einen funktionierenden Exploit entwickeln, der Root-Zugriff auf Ubuntu Server 22.04 gew\u00e4hrt; hierbei sind neben der Sicherheitsanf\u00e4lligkeit in snap-confine auch zwei Sicherheitsanf\u00e4lligkeiten im Prozess multipathd (CVE-2022-41974, CVE-2022-41973) beteiligt, die mit der Umgehung der Berechtigungspr\u00fcfung bei der \u00dcbertragung von privilegierten Befehlen und unsicherem Umgang mit symbolischen Links verbunden sind. <\/p>\n
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\u00fcgt wurde, und zwar nach der \u00dcberpr\u00fcfung des Eigent\u00fcmers, aber bevor der Systemaufruf mount aufgerufen wird, um Verzeichnisse f\u00fcr das Snap-Paket einzubinden. Der hinzugef\u00fcgte Schutz bestand darin, das Verzeichnis \/tmp\/snap.$SNAP_NAME in ein anderes Verzeichnis mit einem zuf\u00e4lligen Namen im \/tmp umzubenennen, sofern es existiert und nicht dem Benutzer root geh\u00f6rt. <\/p>\n
Bei der Durchf\u00fchrung der Umbenennung des Verzeichnisses \\\/tmp\\\/snap.$SNAP_NAME verwendeten die Forscher die Tatsache, dass snap-confine auch ein Verzeichnis \\\/tmp\\\/snap.rootfs_XXXXXX f\u00fcr den Inhalt 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 die Pr\u00fcfung in der Funktion sc_instance_name_validate bestehen (d.h. die Idee ist, dass der Name $SNAP_NAME den Wert «rootfs_XXXXXX» annimmt, wodurch die Umbenennung das Verzeichnis \\\/tmp\\\/snap.rootfs_XXXXXX mit dem Snap-Wurzelverzeichnis \u00fcberschreibt). <\/p>\n
Um die gleichzeitige Verwendung von \/tmp\/snap.rootfs_XXXXXX und die Umbenennung von \/tmp\/snap.$SNAP_NAME zu erm\u00f6glichen, 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\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 abgest\u00fcrzt, und \/tmp\/snap.rootfs_XXXXXX wurde durch Manipulation des Race Conditions ausgetauscht, \u00e4hnlich wie bei der Ausnutzung der Sicherheitsanf\u00e4lligkeit im Februar. Nach dem Austausch wurde die Ausf\u00fchrungsblockierung der ersten Instanz aufgehoben und Angreifer erhielten die volle Kontrolle \u00fcber das Wurzelverzeichnis von snap. <\/p>\n
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\u00e4nkungen blockiert. Um diese Blockade zu umgehen, wurden im Exploit zwei unterst\u00fctzende Schwachstellen in multipathd genutzt. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"