Der bei GitHub angestellte Sicherheitsforscher Kevin Backhouse hat zwei Lücken in Ubuntu 20.04 LTS entdeckt, deren Kombination es einem lokalen Angreifer mit einfachen Mitteln erlaubte, einen Root-Account zu erlangen. Die Lücken sind mittlerweile gepatched.
Ohne eine Zeile Code
Backhouse schrieb, es sei ungewöhnlich, dass eine Schwachstelle in einem modernen Betriebssystem so leicht ausgenutzt werden kann wie hier. Zur Ausnutzung der von ihm gefundenen Lücken muss keine einzige Zeile Code geschrieben werden. Die Lücke zur Ausweitung der Rechte ist zweigeteilt. Der erste Teil des Angriffs nutzt einen Fehler im Accountsservice aus, einem Daemon zur Verwaltung von Userkonten. Dieser Daemon stammt eigentlich aus dem freedesktop-Projekt, wurde aber von den Ubuntu-Entwicklern modifiziert, um eine Datei im Home-Verzeichnis des Benutzers zu lesen.
Backhouse hat zunächst die Datei namens .pam_environment über einen symbolischen Link an die virtuelle Gerätedatei /dev/zero geschickt. Der anschließende Versuch, die Sprache des Desktops zu ändern lässt die entsprechende Dialogbox einfrieren. Im Terminal stellt er fest, dass Accountsservice nun einen CPU-Kern zu 100% auslastet. Nun löscht Backhouse den Symlink, um sich nicht selbst auszusperren.
Der Daemon wird gecrashed
Als Nächstes sendet er das Signal SIGSTOP zum Unterbrechen von Programmprozessen an den Accountsservice. Jetzt folgt der einzig kritische Punkt des Exploits: Bevor sich Backhaus von seinem Konto abmeldet, setzt er zunächst per nohup einen Timer, der ihm das Ausloggen ermöglicht bevor er den Konten-Dämons crasht. Ohne diesen Schritt würde er einfach ausgesperrt und der Exploit wäre fehlgeschlagen.
GDM3 erlaubt Root-Account
Nun stellt beim Login per GDM3 dieser fest, dass kein User-Konto besteht und schaltet das Setup ein, als wäre die eine Neuinstallation. Nun kann ein Root-Account angelegt werden und das System gehört dem Angreifer. Beide Lücken, die Ubuntu-Ausgaben von 16.04 LTS bis zu 20.10 betrafen, sind mittlerweile geschlossen.
Gemeldet und sofort gepatcht! Läuft nicht überall so gut. So what!
¯\_(ツ)_/¯
Schreibe heute das erste mal hier auf der Webseite. Danke für diesen Artikel. Gut, dass ich dadurch (mal wieder) etwas “wachgerüttelt” wurde, und meine Erkenntnis, dass es so etwas wie “Sicherheit” in “der digitalen Welt” (wie auch in der realen Welt) nicht gibt, wieder bestätigt wurde. Manchmal packt einen das Gefühl, dass man diese Kisten einfach für immer aus der Wohnung schmeissen möchte und nie wieder etwas mit Rechnern zu tun haben möchte…
Ich war seit 1986 Commodore / Microsoft / Windows 95 – 7 -Nutzer und bin dann erstmalig im Okt. 2017 neu auf Linux umgestiegen mit Ubuntu 17.10 und bis heute bei (K)ubuntu geblieben. Wird wohl Zeit für was Neues …? Weg von Canonical? Mal sehen. Habe auch schon mal Debian, Manjaro und Mint Debian Edition angetestet und war damit auch recht zufrieden.
Es ist zwar schön, dass o.g. Lücke “nun schon geflickt” wurde – und die Frage stellt sich, ob diese bei Microschrott überhaupt “aufgefallen” wäre, oder vielleicht bewusst noch ein paar Jährchen als Hintertür offen gelassen wäre…?
Werde aber natürlich Linux weiterhin treu bleiben 😉
Windows ist für mich definitiv kein Thema mehr, seit ich auf Linux umgestiegen bin.
Bugs wird es immer und überall geben. Das Schlimme an der Sache ist, das Ubuntu eine Software genommen hat und dann diese Lücke selbst hineinverschlimmbessert hat.
Das passiert da häufiger. Siehe Xscreensaver.
Ernsthaft? Ein im wahrsten Sinne uraltes und zu Lebzeiten wertloses Programm, taugt nicht als Argument.
Das mögen die Nutzer entscheiden. Tipp: viele.
Das war beim Debian openSSL-Bug ähnlich.
Nein war es nicht. Denn der damalige Maintainer Kurt Roekx, hat im Rahmen seiner Tätigkeit streng genommen nichts falsch gemacht. Die damalige Problematik stellte sich wie folgt dar, dass der Maintainer das Paket wie üblich regelmäßig mittels Valgrind geprüft hat, worauf ein Fehler betreffend einer nicht initialisierten Variable identifiziert und korrekt behoben wurde. Was der Maintainer hingegen nicht wusste war, dass genau dieses programmiertechnisch fragile Konstrukt in OpenSSL, einer kritischen Funktion zugrunde lag, was so nie hätte existieren dürfen und als eklatanter Fehler OpenSSL anzukreiden ist. Und darüber hinaus sollte so etwas auch dahingehend zu denken geben, dass es im Bezug auf Kryptographie nicht ausreicht lediglich programmieren zu können, da man letztlich auch die kryptographischen Funktionen verstehen können muss, was im Grunde nicht die Aufgabe von Maintainern diverser Linux-Distributionen ist. Nicht umsonst gab es damals den Audit samt großem ausmisten bei OpenSSL, was spürbar Früchte getragen und den Support für OpenSSL bis heute merklich erweitert hat.
Dieses Märchen wird uns von den Debian-Fans wieder und wieder erzählt. Wie kommt es denn, daß alle anderen Distributionen diesen Fehler nicht hatten? Hatten damals die Maintainer aller anderen Distributionen etwas falsch gemacht?
Nur hatten “diverse Linux-Distributionen” diesen Fehler nicht, sonder ausschließlich und alleine Debian. Wenn ich also deiner “Argumentation” folge, dann sind die Maintainer “diverser Linux-Distributionen” also allesamt überqualifiziert? 😉
Viel sicherer als Windows.
Dieser Fehler ist einfach nur peinliches Gemurkse. Mit snap, dass das Maintainment systematisch ausschaltet bekommen wir dann immer mehr Software die ausschließlich von Canonical kontrolliert wird.
Das gute alte Security by Obscurity Modell wie wir es von Microsoft gewohnt sind.
Ich denke nicht, dass dich das glücklicher macht.
Doch, natürlich. Je häufiger das passiert, desto weniger laufe ich Menschen über den Weg, die glauben, ein Betriebssystem ersetze ein Sicherheitskonzept.
Der Spruch, “Mit Linux wäre das nicht passiert” ist doch schon längst aus der Mode.
Schön wär’s.
Wenn von “Mit Linux wäre das nicht passiert” gesprochen wird, dann war zu Lebzeiten noch nie die Rede von dem kommerziellen Gefrickel namens Ubuntu. Das ist weder im funktionellen noch sicherheitstechnischen Sinne, eine ernstzunehmende Referenz für die Sicherheit von Linux-Distributionen im allgemeinen. Die Problematik die dem Artikel zugrunde liegt, betraf wieder einmal kuriose und sicherheitstechnisch fragwürdige Anpassungen seitens Canonical, die es mit den jeweiligen Originalen so nicht gegeben hätte abseits von Ubuntu. Sprich, weder im regulären Gnome noch in anderen Linux-Distributionen abseits von Ubuntu existiert dieses Problem. Selbst Derivate von Ubuntu sind nicht betroffen. Und das ist nur einer der zahlreichen Missstände die bezüglich Ubuntu zutage gefördert wurden.