News Zero-Day-Exploit: PwnKit-Schwachstelle erlaubt Root-Rechte unter Linux

[luckyfreddy]

Ich möchte hier @ComputerBase, @SV3N und auch die Community mal wirklich loben!
ComputerBase - insbesondere SV3N - für die Berichterstattung für Linux. Aber auch die Community, da diese sich - anders als in den Foren bei Heise und Golem - wirklich auf die Themen fokussiert und nicht damit anfängt die jeweils andere Plattform ("Windows ist besser", "Linux ist besser", "Unix/MAC ist besser", ...) nur runterzuputzen.

Großes Lob daher! 👍

 

[andy_m4]

Aber doas ist unter Linux einfach noch nicht gut unterstützt, leider.

Was meinst Du? Ich hatte ja auch extra auf den Linux-Port verlinkt. Insofern frag' ich mich gerade, was Dir konkret fehlt.

 

[MountWalker]

Das klingt stark nach Fedora

Zumindest in Standardkonfiguration gibt es bei Fedora die Sitte, soviele Adminaufgaben wie möglich ins Terminal zu drücken. Ich habe es aber gerade probiert, und ich kann nautilus sowohl mit sudo als auch von einem root-Terminal (su) aus starten. (Fedora 35 Workstation in weitgehender Standardkonfiguration) Auf Mandriva war es alledings zu dessen Ende so, dass es mit sudo ging, mit "su" ohne Variable nicht, aber wenn man im Terminal statt "su" mit ich glaube "su -" angemeldet war, dann wieder schon. Es ist gut möglich, dass Mageia diese Besonderheit weiterführt.

P.S.
Bei Fedora ist das Update auch verfügbar.

 

[Drewkev]

Was meinst Du? Ich hatte ja auch extra auf den Linux-Port verlinkt. Insofern frag' ich mich gerade, was Dir konkret fehlt.

opendoas ist halt das, was in Arch in den Repos ist. Und das Problem bei doas: Bei sudo gibt es dieses Ding, wo man eine Zeit lang in der gleichen Shell kein Passwort mehr eingeben muss.

 

[andy_m4]

Bei sudo gibt es dieses Ding, wo man eine Zeit lang in der gleichen Shell kein Passwort mehr eingeben muss.

Wobei man sich fragen muss, inwieweit das tatsächlich ein relevantes Problem ist. Wenn ich weiß, das ich mehrere Befehle als root ausführen muss, starte ich eine interaktive Session.

opendoas ist halt das, was in Arch in den Repos ist.

Lustigerweise passt hier Dein Argument gar nicht, da OpenDoas die persist-Option unterstützt. Siehe dazu auch:
https://github.com/Duncaen/OpenDoas

 

[Drewkev]

Wenn ich weiß, das ich mehrere Befehle als root ausführen muss, starte ich eine interaktive Session.

Ja, aber wenn ich nur zwei ausführen will und bei einer Chain von doas x && doas x zweimal ein Passwort eingeben muss, nervt das.

da OpenDoas die persist-Option unterstützt

Funktioniert aber nicht gleich. Es bleibt nicht richtig, er fragt mich trotzdem direkt nach dem Passwort.

 

[andy_m4]

Ja, aber wenn ich nur zwei ausführen will und bei einer Chain von

Ich verstehe Dein Problem nicht.
Was spricht dagegen eine Session mit doas -s aufzumachen und dann einfach x && x auszuführen?

Funktioniert aber nicht gleich.

Die Hinweise u.a. auf der verlinkten Homepage hast Du aber schon gelesen?!

 

[nirgendwer]

Ja, aber wenn ich nur zwei ausführen will und bei einer Chain von doas x && doas x zweimal ein Passwort eingeben muss, nervt das.

doas sh -c "ls /root/; ls /root/" ?

(kann ich nicht testen, hab kein doas; mit sudo funktioniert es so:
sudo -k sh -c "ls /root/; ls /root/" -- das "-k" forciert die Frage nach dem Passwort bei jedem Aufruf.)

 

[Drewkev]

Grundsätzlich hast du recht. Aber Tab-Completion etc. geht damit halt nicht.

Die Hinweise u.a. auf der verlinkten Homepage hast Du aber schon gelesen?!

Dass es persist gibt, weiß ich. Ist aber auch schon etwas her, vielleicht geht das mittlerweile alles mit doas.

 

[Donnerkind]

Immer wieder schön und passend: https://xkcd.com/149/

 

[SVΞN]

Artikel-Update: Sicherheitsupdates schließen Lücke
In der Zwischenzeit haben alle relevanten Linux-Distributionen, wie Arch, Debian, Ubuntu, Fedora und SUSE, sowie deren Derivate ein entsprechendes Sicherheitsupdate erhalten, welches der Bedrohung durch PwnKit den Schrecken nimmt.

Wie die Rückmeldungen aus dem ComputerBase-Forum bestätigen, haben alle relevanten Distributionen entsprechende Patches über die Systemaktualisierung erhalten.

Die Websites ZDNet und TechRepublic haben die Geschehnisse rund um die seit mehr als 12 Jahren bekannte Sicherheitslücke noch einmal im Detail beleuchtet.

Die Redaktion dankt den zahlreichen Hinweisen aus der Community, die auf entsprechende Updates hingewiesen haben.

 

[Enigma]

Und was lernen wir daraus? Nutze niemals eine andere Distribution als die, die das jetzt schon gefixt haben.
Bei den kürzlich in den News vorgestellten LinuxFX (https://sourceforge.net/projects/linuxfxdevil/files/) ist nix da und auch bei Neptune (https://neptuneos.com/en/download.html) is nix da.

 

[Sebbi]

warum lese ich hier kein "mit Window wäre das nicht passiert" Trollpost ? oder wurde hier schon nass durchgefeudelt XD ?

ne aber in ernst, schön das ihr auch über Linux Lücken berichtet, wäre auch mal schön zu sehen eine Statistik Sicherheitslücken vs. Verbreitung, um solchen Leuten einfach mal alle Argumenteationsgrundlagen zu entziehen, das z.B. Windows wesentlich lückenhafter ist als Linux etc. was nur Aufgrund der Verbreitung ja der Fall ist.

Nutze niemals eine andere Distribution als die, die das jetzt schon gefixt haben.

und was machste wenn es mal anderrum ist? Deine Distri sofort wechseln?
sry aber wenn der Fix 2-3 Tage länger da dauert ist kein Argument. Erst wenn der wirklich uber lange zeit ungefixt bleibt, dann kannste drüber nachdenken.

 

[GrumpyCat]

Man muss allerdings festhalten, dass den Leuten bei Polkit das Thema Environment als Sicherheitsproblem schon bekannt war (und sie es im Verlauf der Ausführung leeren), aber zwischendrin iconv_open aufgerufen wird, das über eine eigene Variable beliebigen Code nachladen kann. Voll gute Idee! Da sollte man mal nachschauen, ob dieses iconv-"Feature" JEMALS von anderen Leuten als Blackhats benutzt wurde. https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
Ich würde als Programmierer auch nicht erwarten, dass eine kleine allgegenwärtige Charset-Funktion dynamisch Code aus beliebigen Quellen nachladen kann. :/

 

[andy_m4]

Sicherheitsupdates schließen Lücke

Wobei man sagen muss, bei PolKit/pkexec kommen Dinge zusammen die weitere Fragen aufwerfen wenn man sich mal die auch im Artikel verlinkte Quelle anschaut:
https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

Zum Beispiel ist ja ein Stolperstein das man execve aufrufen kann auch wenn das Array argv[] die Länge 0 hat. Das ist ein Problem in dem Sinne, das man sich als Programm keinesfalls darauf verlassen sollte das argv[0] mit dem Programmnamen belegt ist. Ich könnte mir gut vorstellen, das es noch mehr Programme gibt die darüber stolpern.

Der zweite (und wirklich kritische) Punkt ist das Zeichensatzhandling (via gconv-Modules) welches den eigentlichen Exploit erst ermöglicht.

Kurzum: Nur weil jetzt pkexec gefixt ist, sind die darunterliegenden Probleme nicht weg und es ist gut möglich, das die uns an anderer Stelle noch mal auf die Füße fallen.

Wobei die größte Gefahr sicherlich von SUID-Programmen ausgeht (auch hier bei pkexec war ja der Workaround pkexec das suid-Bit wegzunehmen).
Wer mal gucken will, welche Dateien auf dem eigenen System so das SUID-Bit gesetzt haben kann mal mit
find / -xdev -type f -perm -u=s
danach suchen lassen.
Ähnlich in der Problematik ist auch das SGID-Bit (sozusagen das SUID-Bit für Gruppen):
find / -xdev -type f -perm -g=s

Das SUID-Programme grundsätzlich sicherheitstechnisch problematisch sind, ist übrigens eine relativ alte Erkenntnis. Dementsprechend gibts auch Mechanismen die Notwendigkeit von SUID zu reduzieren. Zum Beispiel über POSIX-Capabilities. Nützt einem für pkexec jetzt nicht so viel, aber umso weniger SUID-Programme bei eurem System auftauchen, umso mehr ist es dafür ein Zeichen das sich eure Distribution bemüht solche grundlegenden Sicherheitsprobleme zu lösen. Wenn da selbst Programme wie ping auftauchen, weißt Du direkt, das die nen schlechten Job machen.

 

[LuckyMagnum]

12 Jahre. Uff

 

[germoney]

Das polkit package update für Arch kam übrigens direkt am 25.01, zwei Stunden nach der Veröffentlichung des Patches.

Build Date: 2022-01-25 20:04 UTC

https://archlinux.org/packages/extra/x86_64/polkit/
https://github.com/archlinux/svntogit-packages/commit/7169fe6d16beb7a23d2650c9e5ea282c2c82bcbc

Mit folgendem polkit Patch, der die Lücke schließt, vom 2022-01-25T17:21:46Z:
https://gitlab.freedesktop.org/polkit/polkit/-/commit/a2bf5c9c83b6ae46cbd5c779d3055bff81ded683

 

[andy_m4]

Früher war ja mal ein Argument für Open-Source, das ja jeder in den Quelltext reingucken konnte und es herrschte die Annahme, das dies auch im großen Stil geschieht. Solche Bugs sollten dann daraus folgend allenfalls eine kurze Halbwertszeit haben.
In den letzten Jahren wurde aber deutlich, das "niemand" in den Quelltext reinguckt und proaktiv nach Lücken sucht. Zumindest niemand von den good-guys. Weil solche Quelltextanalysen nämlich relativ aufwendig sind. Wer sich das leisten kann sind tendenziell eher die bad-guys die dann u.a. solche Sicherheitslücken verkaufen (weshalb sich das rentiert). Und denen kommt natürlich ein offener Quelltext entgegen.

Was mich an solchen Vorfällen immer nervt ist, das der Bug gefixt wird aber kaum einer wirklich Konsequenzen daraus zieht. Denn solche Bugs sind ja häufig nur Resultate. Von zu komplexen Programmen/Systemen. Von mangelhafter Architektur. Von suboptimalen Software-Engineering.

Gibt natürlich auch Ausnahmen wie z.B. die OpenBSD-Leute, die nicht nur Bugs fixen, sondern auch versuchen an darunter liegenden Ursachen ranzugehen und die zu beseitigen. Aber das ist immer noch viel zu wenig diskutiert.

 

[Locutus2002]

@SV3N Eine Formulierung im Artikel solltest du dringend überarbeiten: Die Sicherheitslücke ist zwar seit 12+ Jahren vorhanden, aber nicht seit 12 Jahren bekannt!! Denn wenn man sich ansieht wie schnell sie jetzt von den Distris gefixt wurde und wie simpel der Workaround via chmod ist, dürfte es kaum so lange gedauert haben sie zu beheben. ;-)

 

[SVΞN]

@Locutus2002 die Sicherheitslücke wurde bereits 2013 von Ryan Mallon in seinem Blog beschrieben, das war aber nicht das erste Mal, dass das Thema aufkam.

Interestingly, Michael Kerrisk opened an issue about this in 2008,
but there was no consensus to support fixing this issue then.

Quelle: https://lore.kernel.org/lkml/20220126043947.10058-1-ariadne@dereferenced.org/T/

Also bekannt ist die Sicherheitslücke wohl tatsächlich seit über 10 Jahren, nur ließ sich lange keine Binärdatei finden, die sich für einen erfolgreichen Angriff geeignet hätte.