Das Unternehmen Qualys hat 9 Schwachstellen im mandatorischen Zugriffsmanagementsystem AppArmor identifiziert, von denen die gefährlichsten es einem nicht privilegierten lokalen Benutzer ermöglichen, root-Rechte im System zu erlangen, isolierte Container zu verlassen und Beschränkungen, die über AppArmor festgelegt wurden, zu umgehen. Die Schwachstellen tragen den Codenamen CrackArmor. Die CVE-Identifikatoren wurden noch nicht zugewiesen. Erfolgreiche Beispiele für Privilegieneskalationen wurden in Ubuntu 24.04 und Debian 13 demonstriert.
Die Probleme bestehen im LSM-Modul AppArmor seit dem Linux-Kernel 4.11, der 2017 veröffentlicht wurde, und treten in Distributionen auf, die AppArmor verwenden, wie Ubuntu, Debian, openSUSE und SUSE (seit openSUSE/SUSE 16 ist SELinux standardmäßig aktiv, aber AppArmor bleibt optional). Patches zur Behebung der Schwachstellen wurden den Entwicklern des Linux-Kernels übergeben und werden in den kommenden Tagen den Benutzern in den Updates 6.18.18, 6.19.8, 6.12.77, 6.6.130, 6.1.167, 5.15.203 und 5.10.253 angeboten. Die Korrekturen sind auch in den heutigen Kernel-Paketupdates für Ubuntu enthalten. Zusätzlich wurden in Ubuntu Updates für die Pakete sudo, sudo-ldap und util-linux (das das Tool su enthält) veröffentlicht, in denen Mängel behoben wurden, die das Ausnutzen der Schwachstelle in AppArmor ermöglichten. Ein Update für Debian befindet sich in der Vorbereitung.
Die Probleme beruhen auf einer fundamentalen Schwachstelle in AppArmor der Klasse „verwirrter Stellvertreter“ („confused-deputy“), die es nicht privilegierten Benutzern ermöglicht, beliebige AppArmor-Profile zu laden, zu ersetzen und zu löschen. Diese Schwachstelle kann direkt zur Deaktivierung des Schutzes von Programmen und Diensten gegen lokale und entfernte Angriffe verwendet werden (zum Beispiel durch das Schreiben von Pseudodateien /sys/kernel/security/apparmor/.load, .replace und .remove, um Beschränkungen in cupsd und rsyslogd zu entfernen), um einen Denial-of-Service-Angriff durch Anwendung verbotener Profile auszulösen und um Namespaces-Beschränkungen zu umgehen (durch Laden eines neuen AppArmor-Profils „userns“, beispielsweise für /usr/bin/time, das die Erstellung unbeschränkter user namespaces ermöglicht).
Die Möglichkeit, AppArmor-Profile zu ersetzen, ermöglicht es auch, root-Rechte zu erlangen, indem man neue Profile an privilegierte Tools wie su und sudo bindet, die den Zugriff auf einige Systemaufrufe blockieren. Insbesondere können root-Rechte erlangt werden, indem die setuid-Operation (CAP_SETUID) für das Tool sudo in Verbindung mit der Manipulation der Umgebungsvariablen MAIL_CONFIG blockiert wird, um das Verzeichnis mit den Einstellungen für die E-Mail zu ändern. сервера Postfix.
Das Konzept der Methode besteht darin, dass das Tool sudo bei Problemen eine E-Mail an den Administrator sendet, indem es /usr/sbin/sendmail aufruft. Durch das Blockieren der Privilegienanpassung kann erreicht werden, dass dieser Prozess mit root-Rechten gestartet wird, und durch Setzen der Umgebungsvariable MAIL_CONFIG vor dem Start von sudo können andere Einstellungen an das Tool sendmail übergeben werden, einschließlich der Angabe eines eigenen Handlers postdrop, der beim Versand von E-Mails gestartet wird. $ mkdir /tmp/postfix $ cat > /tmp/postfix/main.cf < /tmp/postfix/postdrop <> /tmp/postfix/pwned EOF $ chmod -R 0755 /tmp/postfix $ apparmor_parser -K -o sudo.pf < /sys/kernel/security/apparmor/.replace Password: $ env -i MAIL_CONFIG=/tmp/postfix /usr/bin/sudo whatever sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted sudo: unable to open /etc/sudoers: Operation not permitted sudo: setresuid() [0, 0, 0] -> [1001, -1, -1]: Operation not permitted sudo: error initializing audit plugin sudoers_audit $ cat /tmp/postfix/pwned uid=0(root) gid=1001(jane) groups=1001(jane),100(users)
Als andere Methoden zur Privilegieneskalation werden Schwachstellen im AppArmor-Code erwähnt, der auf der Ebene des Linux-Kernels arbeitet. Es wird gezeigt, wie man root-Rechte durch Schwachstellen erlangt, die durch doppelte Ausführung der Funktion free() und den Zugriff auf bereits freigegebenen Speicherbereich (use-after-free) im Code zum Laden und Ersetzen von AppArmor-Profilen verursacht wurden. Beispielsweise speichert AppArmor das Profil in der Struktur aa_loaddata, deren Speicher im slab-Cache kmalloc-192 zugewiesen wird. Aufgrund eines Rennbedingungen kann es vorkommen, dass auf den Speicher zugegriffen wird, den die Struktur nach ihrer Freigabe eingenommen hat. Dieses Problem kann ausgenutzt werden, um die Kontrolle über den freigegebenen Speicher zu übernehmen und die freigegebene Speicherseite neu zuzuweisen, um den Inhalt der Datei /etc/passwd zu mappen und die Zeile mit dem root-Passwort zu überschreiben.
Quelle: opennet.ru
