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

[rgbs]

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.

Es steht Dir frei, es besser zu machen.
Es ist open source, Du kannst auch Deine optimierte Distribution nebst optimierten Programmen raus bringen.

Gruß
R.G.

 

[GrumpyCat]

In den letzten Jahren wurde aber deutlich, das "niemand" in den Quelltext reinguckt und proaktiv nach Lücken sucht.

Das ist völlig falsch. Es gibt diverse Projekte, die sogar automatisiert in Open Source nach Sicherheitslücken suchen, nur finden die natürlich nicht sofort alle Fehler.
Dann gibt es da noch z.B. Project Zero, die (auch) manuell in einigen Projekten nach Bugs suchen.
Oder z.B. die automatisierten Funktionen in GitHub und Konsorten. Sobald Du da was hochlädst, wirst Du auf wenigstens einige Klassen von Fehlern (z.B. veraltete Abhängigkeiten) hingewiesen.

 

[rgbs]

Eben,
es gibt auch Leute welche nicht nur meckern, sondern auch etwas tun.

Gruß
R.G.

 

[MountWalker]

[...]
In den letzten Jahren wurde aber deutlich, das "niemand" in den Quelltext reinguckt [...]

Ich würde das einschränken, weil seit der OpenSSL-Heartbleed-Lücke schon ein gewisses Umdenken eingesetzt hat. Wenn große kommerzielle Unternehmen mit milliardenschwerem Support-Umsatz nach so einer Lücke behaupten, sie könnten ja nichts dafür, wenn das von ihnen verwendete OpenSSL eine solche Lücke aufweist, sagen die Kunden eben doch: Natürlich könnt ihr was dafür, ihr sucht das ja aus und niemand hindert euch daran, ein Projekt, das in 17% der gesamten Internet-Infrastruktur verwendet wird, auch finanzielll zu unterstützen. OpenSSL ist heute viel besser aufgestellt als 2014.

 

[FrAGgi]

Es steht Dir frei, es besser zu machen.

Wieso muss immer jemand den Spruch bringen wenn man Kritik äußert?
Ja es ist Open Source und ja theoretisch kann da jeder mitwirken. Nur ist nicht jeder Programmierer oder gut genug um sich bei sowas zu beteiligen. Dennoch darf man dann doch Kritik äußern.

 

[foo_1337]

OpenBSD z.B. hat vor vielen Jahren die Konsequenzen daraus gezogen und erlaubt kein execve wenn argc==0. Das ist zwar nicht POSIX konform, hat aber in der Realität keine funktionalen Einschränkungen. Es gibt hier auch einen Patch für linux, der hier ein EFAULT zurück gibt: https://lore.kernel.org/lkml/20220126043947.10058-1-ariadne@dereferenced.org/T/
Patch für FreeBSD: https://github.com/freebsd/freebsd-src/commit/773fa8cd136a5775241c3e3a70f1997633ebeedf hier ist es EINVAL, aus meiner Sicht passender.

 

[Cool Master]

Dennoch darf man dann doch Kritik äußern.

Im Prinzip ja, aber wenn man nicht Programmierer ist oder von der Materie kaum Ahnung hat ist das halt immer recht leicht gemacht, da man nicht alle Punkte versteht. Vor allem weil die Leute alles auf freiwilliger Basis, in der Regel in der Freizeit, machen. Kritik ist durchaus ok aber man sollte auch entsprechend Vorschläge mit einbringen.

Die Systeme sind mittlerweile so komplex, dass es mit einfach nur drüber schauen schon lange nicht mehr getan ist. Will man wirklich Sicherheit brauch es ein Code-Review der nicht in 2 Tagen abgeschlossen ist. Man schaue sich einfach mal das Review von Veracrypt an:

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Veracrypt/Veracrypt.pdf

Das größte Problem welches ich gerade sehe ist, dass Bibliotheken eher Stiefmütterlich behandelt werden oder man sich nicht mehr die Mühe macht alles selber zu schreiben. Damit kommt man zu Software Kombinationen die im Prinzip so zusammen gesetzt sind wie 10 Reiniger in ein Topf zu schütten - kann gut gehen aber wehe es kommt noch ein weiterer Reiniger dazu.

Aber B2T:

Meine Server waren auch nicht betroffen da nichts mit GUI läuft und immer via Debian Minimal installiert wird und nur das drauf kommt was ich benötige.

 

[andy_m4]

Ich würde das einschränken, weil seit der OpenSSL-Heartbleed-Lücke schon ein gewisses Umdenken eingesetzt hat.

Das stimmt. Ich würde auch nicht so weit gehen, das überhaupt nix in dem Bereich passiert. Aber es ist immer noch zu wenig.

Es steht Dir frei, es besser zu machen.

Das ist immer das Argument was gebracht wird wenn man etwas kritisiert. Dann wird halt läppisch gesagt, das man es doch besser machen solle.
Anstatt sich einfach mal die Kritik zu Herzen zu nehmen und tatsächlich zu gucken, ob da nicht was dran ist. (Im übrigen sind da viele Entwickler durchaus auch offen für bzw. stimmen dem sogar grundsätzlich zu. Es sind da häufig eher praktische Zwänge die dem teilweise entgegen stehen.)

Insofern ist das natürlich kein Argument.

Das ist völlig falsch. Es gibt diverse Projekte, die sogar automatisiert in Open Source nach Sicherheitslücken suchen, nur finden die natürlich nicht sofort alle Fehler.

Wie man ja an pkexec auch wunderbar sehen konnte. :-)

Dann gibt es da noch z.B. Project Zero, die (auch) manuell in einigen Projekten nach Bugs suchen.

Ja. Ich bin auch ein großer Fan von Project Zero. Wobei auch hier primär der Ansatz ist, Lücken zu finden und nicht Konzepte oder Komplexität zu hinterfragen. Und darum geht es mir doch. Das wir nicht nur mehr an den Symptomen herumdoktern, sondern viel stärker auf die Ursachen gehen.

Oder z.B. die automatisierten Funktionen in GitHub und Konsorten. Sobald Du da was hochlädst, wirst Du auf wenigstens einige Klassen von Fehlern (z.B. veraltete Abhängigkeiten) hingewiesen.

Das Problem ist doch nicht, das es hier und da veraltete Abhängigkeiten gibt, sondern das wir überhaupt solche Abhängigkeiten haben.
Gerade so bei node.js und Co fängst Du Dir halt schnell ne Abhängigkeitshölle ein. Und dann hast Du vielleicht an einer Stelle das Problem aber kannst es eigentlich gar nicht so ohne weiteres fixen ohne das droht alles zusammenzufallen.
Auch das sind wieder lediglich Auswirkungen von darunter liegenden Problemen.

Das alles sind nette Werkzeuge, wenn ich ein solides Fundament hab und dann das Hilfen sind einzelne kleinere Probleme zu identifizieren. Es darf aber kein Ersatz dafür sein grundlegende Dinge nicht zu tun.

 

[Lora]

Die Patches kamen relativ Zeitnah raus, wenigstens gibts dann keine Drucker Probleme 🤪

 

[FrAGgi]

Im Prinzip ja, aber wenn man nicht Programmierer ist oder von der Materie kaum Ahnung hat ist das halt immer recht leicht gemacht, da man nicht alle Punkte versteht.

Stimme dir da natürlich grundsätzlich zu. Trotzdem gibt es ja durchaus auch berechtigte und kosntruktive Kritik die man nicht immer einfach mit diesem Standardsatz abtun sollte.

 

[andy_m4]

OpenBSD z.B. hat vor vielen Jahren die Konsequenzen daraus gezogen und erlaubt kein execve wenn argc==0.

Zu OpenBSD passt das :-)
Aber generell stellt sich natürlich, ob man im Kernel Vorsichtsmaßnahmen für mangelhaften Userland-Code treffen sollte. Im Einzelfall kann das natürlich gerechtfertigt sein. Aber generell will man ja lieber weniger Code haben als mehr.

Ich bin mir jedenfalls noch unschlüssig, ob ich das gut finden soll oder nicht.

 

[RalphS]

@andy_m4 Es muß halt alles schnell schnell gehen. Da wird schon beim Entwurf nicht überlegt und man kriegt am Ende ne Batchdatei mit .c als Endung.

Grad die Woche erst nen Regex vorgelegt bekommen, welcher eine Zeichenfolge von sowas wie 15 Zeichen identifizieren sollte.

War gut 100 Zeilen lang. Ich denke nicht, daß das Teil tut, was es soll, sondern nur zufällig bei der richtigen Eingabe auch ein okay aussehendes Ergebnis liefert.

 

[kiffmet]

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.

NeptuneOS und LinuxFX sollten die Updates automatisch bekommen, da sie auf Debian 11, respektive Ubuntu aufbauen, und deren Repos nutzen.

Ergänzung (29. Januar 2022)

thread: Eigentlich sollte Fuzzing mitterweile ein Standardvorgang in der Entwicklung von sicherheitskritischen Programmen sein. Der Fehler wäre sofort aufgefallen.

 

[andy_m4]

Ich denke nicht, daß das Teil tut, was es soll, sondern nur zufällig bei der richtigen Eingabe auch ein okay aussehendes Ergebnis liefert.

Das hast Du aber bei RegExps häufig. Vor allem wenn versucht wird damit Dinge zu erschlagen, die damit eigentlich nicht gut behandelt werden können.
Umso länger ein RegExp wird, umso höher wird die Wahrscheinlichkeit das hier RegExp eigentlich der falsche Lösungsansatz war. :-)

 

[RalphS]

Das hast Du aber bei RegExps häufig.

Du hast es leider "überall" häufig. Jeder hat seinen eigenen "spezialisierten" Ansatz für buchstäblich jedes Problem, egal was es ist -- ich kenn mich mit X gut aus, also mache ich X zur Problemlösung von Y (was damit aber nicht viel zu tun hat).

setuid() oder setgid() und warum soll ich nach permissions fragen? Ist doch einfach.

 

[Quonux]

Mein Gott der Linux Kernel besteht aus Millionen von Zeilen, da finden sich ZeroDays für jeden, vor allen Dingen in den Gerätetreibern...

Software wächst genauso wie Hardware nicht auf Bäumen, fehlerfreie schon gar nicht und schon gar nicht in C.

 

[RalphS]

Doch, sie wächst. Und das ist genau das Problem, am Ende hast nur noch ein Patchwork aus "hier mal dran geknippert und dort mal dran gepatcht" und egal was das ursprüngliche Konzept war, nach fünf Releases oder so ist der Quellcode im Arsch und müßte neu gemacht werden.

 

[madmax2010]

Ich bin leicht begeistert, dass reddit die mitigation direkt als fire and forget playbook bereitstellt
https://access.redhat.com/sites/default/files/cve-2021-4034_stap_mitigate--2022-01-28-1236.yml

 

[rgbs]

nach fünf Releases oder so ist der Quellcode im Arsch und müßte neu gemacht werden.

Genauso wie man beim Bauen von Autos oder der Herstellung von Halbleitern nicht bei "Null" anfängt, ist es ein dummer Plan, den Quellcode neu zu machen.

Gruß
R.G.

 

[AW4]

thread: Eigentlich sollte Fuzzing mitterweile ein Standardvorgang in der Entwicklung von sicherheitskritischen Programmen sein. Der Fehler wäre sofort aufgefallen.

Das ist Humbug.
Klar kannst du Fuzzen und klar sollte man das bei Projekten bestimmter größe machen.
Aber Fuzzing ist kein Allheilmittel und vor allem kein Garant dafür, alle Bugs und Sicherheitsrelevanten Probleme zu finden, die in einem Projekt drinstecken.

Mit Fuzzing schmeißt du Datenmüll gegen deine Funktionen/Methoden/APIs und schaust was passiert.
Das hat hauptsächlich zwei große Probleme:

1. Die einzelnen Funtionsparameter, und noch mehr die Kombination aller Funktionsparameter, mit denen Funktionen/Methoden/APIs aufgerufen werden können, haben i.d.R. eine so immens große Definitionsmenge, dass es selbst mit enormer Rechenpower nicht machbar ist alle möglichen Kombinationen innerhalb brauchbarer Zeit durchzuprobieren.
   Man muss bei sowas also Annahmen zugrundelegen und den Definitionsbereich auf eine handhabbare Größe schmälern.
   Damit ist faktisch ausgeschlossen, dass man alle Probleme mit dem zugrunde liegenden Code per Fuzzing ausmachen kann.
2. False-Positives: Ganz nach dem Motto "Wer misst, misst Mist" existiert auch bei Fuzzing eine gewisse Bandbreite in der Qualität der verwertbaren Ergebnisse.
   Im Zweifel muss manuell bewertet werden, was bestimmte Ergebnisse in Abhängigkeit ihrer Input tatsächlich aussagen.
   Es ist bei wortwörtlichem Datenmüll als Input für Parameter, je nach Anwendungsfall, nämlich nicht immer eindeutig, ob die Funktion/Methode/API das auffällige Ergebnis zu verantworten hat, oder irgend ein anderer Nebeneffekt.
   Das kostet zum einen wieder Zeit und schmälert den realistisch anwendbaren Definitionsbereich noch einmal mehr ein und zum anderen eröffnet es die Möglichkeit, dass ein tatsächlicher Bug als das Gegenteil klassifiziert wird.

Fuzzing ist lediglich ein weiteres Werkzeug im Werkzeugkasten, um das Qualitätsniveau von Code potentiell anzuheben.