News Ubuntu, Debian & Co.: Schwachstelle in glibc gewährt Root-Zugriff unter Linux

coffee4free

Lt. Junior Grade
Registriert
Okt. 2015
Beiträge
269
  • Gefällt mir
Reaktionen: netzgestaltung, aid0nex, Schäfchen und 7 andere
Das wäre mit Linux nicht passiert.
 
  • Gefällt mir
Reaktionen: bullit1, Dominicus1165, Kaulin und 41 andere
Wollte ich auch gerade schreiben aber es liegt natürlich auch an C.
Wenn eine Lib ausgehebelt werden kann, egal wie, dann hat man eben den Salat.
 
  • Gefällt mir
Reaktionen: aragorn92 und sh.
Was ist das denn für eine hanebüchen Argumentation der glibc Gruppe?

Wenn ein einfacher Vergleichsaufruf in deiner Lib einen Pufferoverflow mit Rechteskalation ermöglicht, dann ist das verdammt nochmal das Problem der Library selbst und nicht der Entwickler.

Ja, Entwickler die die App benutzen sollten sich aus Stabilitätsgründen an die Standards halten.
Die Library hingegen muss aus Sicherheitsgründen sicher stellen, dass unkonforme Aufrufe nicht zweckentfremdet werden können. Entwickler, die aus Versehen (schlechtes coding) ein System einfrieren lassen, tragen natürlich Mitschuld am Absturz des System, sind hier aber nur eine Seite.

Angreifer die aber über "getarnte" Programme (solche, die erstmal legit aussehen) die Lib nutzen um eine Rechteeskalation zu bewirken sind hier aber die viel relevantere Gruppe und nur der Verwalter/ Ersteller der Lib ist hier in der Pflicht und niemand sonst.

Wenn ich im Winter mit Sommerreifen fahre, stellt VW trotzdem sicher, dass die Airbags funktionieren....
 
  • Gefällt mir
Reaktionen: Kaulin, Jarhead91, aid0nex und 15 andere
Bin ja die Sorte Nutzer, welche sich über Sicherheitslücken in Linux freut, zu lesen, weil es zeigt, dass jedes System verwundbar ist.

Nur dann sollte so etwas auch schnell geflickt werden :D
 
  • Gefällt mir
Reaktionen: Postman, Legalev und aragorn92
@Hörbört Schon richtig dass glibc nicht von einem einzelnen Typen in Nebraska maintained wird, aber der andere Aspekt passt schon, finde ich.
Sollte es in der glibc mal wirklich knallen, kann das noch uebler als zB bei Log4J werden.
 
Randnotiz schrieb:
Bin ja die Sorte Nutzer, welche sich über Sicherheitslücken in Linux freut, zu lesen, weil es zeigt, dass jedes System verwundbar ist.
Und ich als Linux-Nutzer freue mich dann immer, dass die Distributionen oft schon einen Fix ausgerollt haben noch bevor ich von der Schwachstelle in den Medien lese.

Edit: weniger zu lachen haben freilich die, die mit unveränderlichen Systemen zu tun haben wie embedded und IoT, oder auch Android.
 
  • Gefällt mir
Reaktionen: netzgestaltung, Mondgesang, Elektrolyt und 10 andere
Donnerkind schrieb:
Und ich als Linux-Nutzer freue mich dann immer, dass die Distributionen oft schon einen Fix ausgerollt haben noch bevor ich von der Schwachstelle in den Medien lese.

Exakt, Gentoo hatte heute morgen auch schon die aktualisierung von glibc parat <3
 
  • Gefällt mir
Reaktionen: xman00, nkler, konkretor und 2 andere
Dennoch erkenne man an, dass es sich um ein Problem der Implementierungsqualität handle. Dieses sei aber ohnehin im Rahmen eines Refactorings der qsort-Funktion durch ein kürzlich veröffentlichtes Update beseitigt worden.
also gefixt!?
 
Donnerkind schrieb:
Edit: weniger zu lachen haben freilich die, die mit unveränderlichen Systemen zu tun haben wie embedded und IoT, oder auch Android.
Ich bin mir nicht sicher ob Android syslog benutzt, es ist kein GNU/Linux daher weiß ich das wie gesagt nicht. Steht nicht umsonst in der News Debian/ Ubuntu und co und nix von Android?

Android ist eher ein BSD/Linux als ein GNU/Linux, ich weiß nicht mal ob man glibc benutzt vermutlich nicht, da das gegen die GPL verstoesst vermutlich.
 
  • Gefällt mir
Reaktionen: Kaulin, JustAnotherTux, MountWalker und eine weitere Person
  • Gefällt mir
Reaktionen: netzgestaltung, MalWiederIch, Feuerbiber und 2 andere
Wie es zu einer Rechteausweitung kommen kann, wuerde ich gerne wissen.

Und ob der Address-Sanitizer Alarm schlaegt, gegen solche Fehler gibt es wirksame Mittel im Compiler fuer C und C++. Dazu muss man allerdings die passenden Codepfade testen, zur Run-Time (Unittests also).

Trotzdem wuerde ich mir wuenschen, dass sich die Ideen aus CPP2 im C++ Standard wiederfinden:


Speichersicherheit in C++ per Compiler garantieren. Woher kennen wir das? Rust. Inzwischen koennen Compiler das zur Compile-Time und wir haben laengst auch die Rechenkapazitaet dafuer. Fuer C erwarte ich kaum, weil dort Rueckwarteskompatiblitaet und Einfachheit der Sprache hoch gewichtet werden. Und so koennte man dann von C auf C++ umstellen, sich die Speichersicherheit holen mit "#safe" und abschalten mit "#unsafe" wenn erforderlich. Ich wuerde es mir allerdings auch fuer C wuenschen.


Ein Grossteil unsere Infrastruktur laeuft mit COBOL. Warum? Weil man den Umfang des Codes nicht ersetzt bekommt. Vor allem bekommt man den Code nicht einfach "sicher" ersetzt und hat mit restlichen Logikfehlern weiterhin alle Probleme Was passiert, wenn man meint man waere besser hat hier ein mahnendes Beispiel.

Das ist der fleissige Weg mit viel kleinen Schritten fuehrt darueber die vorhanden Technik in den Compiler auf bisherige Sprachen auszudehnen. Dann profitieren alle. Ist halt keine Wunderheilung mit Hypetrain, sondern Arbeit.
 
  • Gefällt mir
Reaktionen: ReignInBlo0d
Ganz ehrlich ich halte den Sinn solch einer News für ziemlich begrenzt, wäre es ein Remote ausnutzbarer Bug würde ich es noch mehr verstehen, aber Sysadmins werden wohl nicht auf CB gehen um dort sich schlau zu machen über Bugs und der Bug wird bei jedem der updates macht ohne eigenes Zutun gefixt werden.

Es ist also eher dazu da Clicks und Traffic zu generieren und das man halt was zu reden hat. Und das der Bug schon 30 Jahre alt ist reicht um vielleicht irgendwie zu suggerieren das Linux scheiße ist, oder so, aber zeigt eigentlich mehr wie unwichtig dieser Bug ist wenn in bisher niemand fand und daher zu 99,9999% sicher auch von niemandem ausgenutzt wurde.

Mag Artikel nicht die an sich Sachlich zu sein scheinen aber man mit Implikationen die Leute dazu hinleitet zu den gewünschten "eigenen" Schlüssen zu kommen, sowas ist relativ manipulativ da wenn Leute glauben sie seien selbst auf einen Schluss gekommen sie es mehr glauben wie wenn man es ihnen direkt sagt. Ob das Absicht ist kann ich natürlich nicht 100% sicher sagen, da ich keine Gedanken lesen kann, aber der Verdacht drängt sich schon auf.

Ich verstehe das man Geld verdienen muss, aber die News wird nicht so viel Traffic generieren daher wirklich nötig? Mein man könnte auch einfach ne Einschätzung dazu geben, wie relevant das ist, dann zeigt man wenigstens Farbe, und macht sich eventuell nicht dem Skandalisierungs-journalismusses mit schuldig.

Andere news wo ein Update verhindern helfen kann das Windows nicht mehr geht und man dort alarm schreit z.B. finde ich angemessener, da hier die Information Leuten nutzen kann, hier seh ich da keinerlei zeitlicher Druck nur fuer ganz wenige hochsichereits-admins / firmen die fuer die Informationen sicher nicht auf CB angewiesen sind.
 
  • Gefällt mir
Reaktionen: Eier-Salat, ErbarmeHesse, Feuerbiber und 3 andere
Bei Linux melden Forscher Sicherheitslücken, bei Windows die User 🫣

Ich kann damit Leben, wird sicher schnell ein Update raus kommen.
Und es handelt sich um Lücken die schwerer auszunutzen sind.

Aber wenn ich mir diese Grafik hier ansehe bin ich beruhigt:
Screenshot_20240201_161547.png

Quelle: https://www.borncity.com/blog/2022/...llen-werden-am-schnellsten-gepatcht-feb-2022/
 
  • Gefällt mir
Reaktionen: netzgestaltung, MalWiederIch, Eier-Salat und 14 andere
blackiwid schrieb:
Ganz ehrlich ich halte den Sinn solch einer News für ziemlich begrenzt, wäre es ein Remote ausnutzbarer Bug würde ich es noch mehr verstehen, aber Sysadmins werden wohl nicht auf CB gehen um dort sich schlau zu machen über Bugs und der Bug wird bei jedem der updates macht ohne eigenes Zutun gefixt werden.

...
Andere news wo ein Update verhindern helfen kann das Windows nicht mehr geht und man dort alarm schreit z.B. finde ich angemessener, da hier die Information Leuten nutzen kann, hier seh ich da keinerlei zeitlicher Druck nur fuer ganz wenige hochsichereits-admins / firmen die fuer die Informationen sicher nicht auf CB angewiesen sind.

Ja.
Mich wuerde es nicht wundern, wenn jede Woche kritischere Luecken an gleicher und anderer Stelle gefixt und neu eingebaut werden. Der Nachrichtenwert ist niedrig, die Nummer hintem am Release wird angehoben um Bugfixes zu signalisieren. Kaputtes SSL oder Remote-Code Execution sind relevant.
Ergänzung ()

https://www.computerbase.de/forum/t...oot-zugriff-unter-linux.2182122/post-29084267

Das wäre mit Linux Rust nicht passiert.


Solche Kommentare sind so "Internet".
Nutzlos und irrefuehrend.

Es waere etwas anderes passiert. Deswegen auch das bedauerliche Beispiel mit der SSL-Implementierung mit Java fuer Java. Da kommt ein neuer Programmierer der es mit der Programmiersprache noch nie umgesetzt und es faellt dann hin. Und wenn es doof laeuft, faellt es nicht mit exit(1) hin sondern heimlich.

Was macht man dagegen? Mit Unittest und AddressSanitizer abpruefen. Letzteres wurde bei der SSL Geschichte fuer Java wohl nicht gemacht. Die Rustentwickler hegen keine Ambitionen die GLIBC, LIBSTDC++ und den GCC neu zu implemetieren. Vermutlich weil sie wissen, dass das Zeug wichtig fuer Rust ist und sie sich da Leben nicht schwer machen wollen.
 
Zuletzt bearbeitet:
Ich danke CB (Computer Bild) für die seriöse Meldung. :heilig:

Ich danke den Entwicklern für das schnelle fixen der Schwachstelle. :daumen:

updateLinux.png
 
  • Gefällt mir
Reaktionen: netzgestaltung, Lora, Muntermacher und eine weitere Person
Zurück
Oben