PwnKit, oder wie 12 Jahre alter Code unberechtigten Benutzern Root-Rechte verschaffen kann

Es sieht so aus, als gäbe es für IT-Teams keine Atempause. Nach all den Problemen, die durch log4j (und seine Varianten) verursacht wurden, macht eine neue hochkarätige und risikoreiche Sicherheitslücke die Runde. CVE-2021-4034, oder PwnKit, wenn Sie auf ausgefallene CVE-Spitznamen stehen, ist eine Polkit-Schwachstelle, die es nicht privilegierten Benutzern ermöglicht, Root-Rechte auf praktisch jedem Linux-System zu erlangen, auf dem Polkit installiert ist.

Das Extended Lifecycle Support-Team von TuxCare bereitet Patches für alle unterstützten Distributionen vor, die in Kürze zur Verfügung stehen werden. Dieser Beitrag wird aktualisiert, um die tatsächliche Verfügbarkeit für jede Distribution wiederzugeben, sobald dies geschieht.

[HINWEIS: Patches sind jetzt für Centos6, Oracle6, CL6, Ubuntu16 und Centos8.4 verfügbar. Weitere werden folgen. Sie können die aktuelle Unterstützung der Distributionen über das CVE-Dashboard hier verfolgen: https://cve.tuxcare.com/cve/CVE-2021-4034.]

Diese Schwachstelle wurde vonden Forschern von Qualys identifiziertund den Distributionsanbietern Ende letzten Jahres bekannt gegeben, aber erst am 25. Januar 2022 öffentlich zugänglich gemacht.

Die Lücke ist extrem leicht auszunutzen, und obwohl in der ersten Ankündigung davon die Rede war, dass in den nächsten Tagen ein Exploit erscheinen würde, dauerte es tatsächlich nur etwa 3 Stunden, bis öffentlich verfügbarer Exploit-Code entdeckt und als funktionierend bestätigt wurde. Betroffen sind die wichtigsten Linux-Distributionen wie Ubuntu, RHEL, CentOS und ihre Derivate. Da der betroffene Code Teil des ersten Code-Commits von polkit aus dem Jahr 2009 war, ist es sehr wahrscheinlich, dass jede Distribution, auf der polkit läuft, verwundbar sein wird.

Was ist polkit (und pkexec)?

Polkit ist ein Paket, das eine Privilegienkontrolle für die Verwaltung der Kommunikation zwischen Prozessen bietet, wenn Prozesse unterschiedliche Privilegien haben. Durch pkexec (eine Polkit-Komponente) kann ein Benutzer Befehle mit höheren Berechtigungen als normal ausführen. So kann beispielsweise einem bestimmten Benutzer der Zugriff auf eine systemweite Aufgabe gewährt werden, ohne dass dieser Benutzer vollen Root-Zugriff erhält.

Ein genauerer Blick auf die Schwachstelle

Pkexec akzeptiert Argumente, die ihm in der Befehlszeile übergeben werden und die sein Verhalten steuern (was ausgeführt werden soll, in welchem Umfang und so weiter). Die Forscher fanden heraus, dass es möglich ist, einen Null-Parameter zu übergeben und den Code, der den Parameter validiert, so zum Scheitern zu bringen, dass der Speicher mit einem vom Angreifer kontrollierten Wert beschädigt wird, der in die pkexec-Ausführungsumgebung geschrieben wird. Dies kann dann so erweitert werden, dass pkexec einen beliebigen Befehl als Root ausführt, was auf triviale Weise ausgenutzt werden kann, um einem unprivilegierten Benutzer vollen Root-Zugriff zu gewähren.

Die eigentliche Code-Analyse ist in der ursprünglichen Ankündigung von Qualys enthalten, die oben verlinkt ist.

Abhilfe, bevor ein Patch verfügbar ist

Es ist möglich, das Risiko zu mindern, indem das SUID-Bit mit dem Befehl aus pkexec entfernt wird:

Beachten Sie, dass dies den regulären Betrieb von pkexec beeinträchtigt. Testen Sie diese Änderung daher gründlich in einer Testumgebung, bevor Sie sie in großem Umfang in Ihrer Infrastruktur einsetzen, da sie zu unerwünschten Nebeneffekten führen kann. Ein Patching ist immer noch die beste Option.

Schlussbemerkungen

Diese Sicherheitslücke erfordert Zugriff auf ein System, um ausgenutzt zu werden, da sie keinen bekannten Remote-Angriffsvektor hat. Dennoch kann sie von einem Angreifer, der sich Zugang zu einem System verschafft hat, genutzt werden, um seine Privilegien zu erweitern. Die weite Verbreitung von Polkit macht dies zu einer sehr ernsten Sicherheitsbedrohung, die so schnell wie möglich gepatcht werden sollte, um unangenehme Überraschungen zu vermeiden.

Diese Sicherheitslücke ist ein weiteres Beispiel für ein seit langem bestehendes Problem bei Open-Source-Software: Nur weil der Quellcode offen ist, heißt das nicht, dass die richtigen Leute danach suchen. Der Fehler war in 12 Jahre altem Code vorhanden, und niemand hat ihn in dieser Zeit entdeckt - zumindest hat ihn niemand öffentlich bekannt gegeben. Grundlegenden Projekten fehlen in der Regel die Ressourcen (und der Anreiz), um ihren Code ordnungsgemäß zu prüfen und abzusichern, aber unzählige andere Projekte und Distributionen verlassen sich in unverhältnismäßigem Maße darauf. Um dies in die richtige Perspektive zu rücken, ist eine Sicherheitslücke in 12 Jahre altem Code nicht einmal der "älteste" Fehler, der in den letzten Monaten gefunden wurde. Je mehr Code geprüft wird, desto mehr Schwachstellen werden wahrscheinlich gefunden, was dafür spricht, dass neue Sicherheitslücken schneller geschlossen werden, sobald sie auftauchen.

Patches für alle unterstützten Distributionen, die von TuxCare's Extended Lifecycle Support Service abgedeckt werden, sind in Vorbereitung und werden in Kürze zur Verfügung gestellt - schauen Sie hier für Updates vorbei, da dieser Beitrag die Verfügbarkeit von Patches für die verschiedenen Distributionen widerspiegeln wird, sobald sie für den Einsatz bereit sind.