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

Da noch nicht aufgelöst wurde, ldd --version zeigt (etwas) Informationen zur libc an. Ist jetzt nicht super viel, aber das notwenigste – wer Zeit und Lust hat kann die ldd man page lesen um zu sehen wofür das Programm noch nützlich sein kann.
 
  • Gefällt mir
Reaktionen: Muntermacher
Das ist nicht das Problem, sondern dass Anwendersoftware geschrieben wird, die diesen Bug ausnutzt.

Experten haben dafür den Begriff Malware erfunden.
 
  • Gefällt mir
Reaktionen: cbtestarossa
Ranayna schrieb:
Aber auch wir haben noch alte Maschinen im Einsatz, bei der aeltestens laeuft Windows 2000 auf dem Steuerrechner. Die sind aber auch vollisoliert.
Eben, der CentOS5 war aber ein FTP Server in Vietnam und öffentlich erreichbar. Der wurde sogar schon gehackt und war dann immer noch ein halbes Jahr online weil die Pappnasen den wieder eingeschaltet haben :D

Alte System dürfen ruhig weiterlaufen, wenn sie entsprechend gesichert sind, nur sowas mit den CentOS5 was die da gemacht haben geht halt nicht. Die haben den aufgesetzt und genauso lief der einfach die letzten Jahre, die haben das System quasi vergessen und das ist schlimme. Will nicht wissen was in anderen Firmen noch so von außen erreichbar ist.
 
  • Gefällt mir
Reaktionen: Skysnake und MountWalker
sedot schrieb:
Da noch nicht aufgelöst wurde, ldd --version zeigt (etwas) Informationen zur libc an. Ist jetzt nicht super viel, aber das notwenigste
Stimmt. Guter Hinweis. Zumindest wenn man die GNU-Variante von ldd benutzt, funktioniert das.
 
FrAGgi schrieb:
Bei Linux sind solche Lücken dann für diese Nutzer wieder "halb so wild" und eigentlich ja gar nicht mal berichtenswert.
:rolleyes:
Wer sowas behauptet hat keine Ahnung.
Natürlich ist auch Linux nicht Fehlerfrei, und dementsprechend ist es wichtig zu berichten.
Aber es hat halt noch einige andere Gründe warum ICH es zu mindestens bevorzuge.

floTTes schrieb:
Viel wichtiger als die News über die glibc-Sicherheitslücke finde ich die Sub-Nachricht: kein Betriebssystem ist sicher.
...
Für die Linux-ist-SICHERER-als-Windows-Fraktion: Ja, gerne! Aber auch da kann es hier und da passieren, dass es mal nicht läuft. Soll man das verschweigen? :freak:

Ist angebrachte Kritik gleich Nestbeschmutzung? Da kann ich nur meinen Kopf schütteln ...
Linux ist sicherer als Windows NICHT weil es keine Fehler hat, sondern weil diese schnell gefixt werden als bei MS und Co., sobald sie gefunden werden.
Wie ja auch andere hier schon geschrieben haben.

Und ja natürlich gibt es die Fanboys unter Linux, die sowas als "Verunglimpfung" empfinden. :rolleyes:
Aber die gibt es bei MS und Apple Produkten genauso.
Das sind meistens die, die von der Technik dahinter meist keine Schimmer haben, und auch nicht haben wollen.
 
  • Gefällt mir
Reaktionen: floTTes
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.
Macht man ja bewusst oft so. Das Sicherheitslücken erst offen kommuniziert werden, wenn Patches verfügbar sind. Gerade bei kritischen Lücken - da sonst die Gefahr das sie in freier Wildbahn ausgenutzt werden imens grösser ist.
andy_m4 schrieb:
Wie stelle ich fest, welche libc ich auf dem System überhaupt rumliegen habe? Also obs jetzt die GNU libc ist oder irgendwas anderes.

Unter Linux würde ich das mit LDD und einem Linux Basis Programm das so gut wie immer installiert ist (z.b. "ls") prüfen:

Bash:
ldd /bin/ls

Der Befehl zeigt die Shared Libraries von "ls" an.

Bei Ubuntu (23.10) bekomme ich dabei diese Ausgabe:


Bash:
linux-vdso.so.1 (0x00007ffd5e7db000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f89623e8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8962000000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f896234d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f896244e000)

Spannend ist hier der Punkt "libc.so.6" steht klar für GNU Lib C.

Wenn man das selbe z.b. bei einem aktiven Alpine Linux macht bekommt man als Rückgabewert:

Bash:
/lib/ld-musl-x86_64.so.1

Das zeigt zwei Sachen. 1. Alpine Linux nutzt "musl libc" als systemweite C Bibliothek und 2. ldd ist ein guter Weg um das herauszufinden ;)
 
  • Gefällt mir
Reaktionen: floTTes und sikarr
kim88 schrieb:
Spannend ist hier der Punkt "libc.so.6" steht klar für GNU Lib C.
Nein. Das ist eben nicht klar. Auch Nicht-GNU-LIBCs heißen durchaus lib.c.#
Man sieht es hier am Verzeichnisnamen. Der aber auch nicht zwangsläufig so sein muss.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: KitKat::new()
Das wäre ja meine Frage. :-)
Ich selbst hab dazu auch keine konkrete Idee.
Hab da so den ein oder anderen Ansatz den man vielleicht verfolgen könnte, aber noch keine wirklich gute Lösung.
Idealerweise, in dem man - wie immer man das auch macht - die libc direkt "befragt", damit man eben nicht allein von Indizien abhängig ist.
 
floTTes schrieb:
@blackiwid
Es wäre wahrnehmungsverzerrend, wenn man nicht über Linux-Sicherheitslücken berichten würde.
Sollte CB diese Informationen zurückhalten, nur weil die Forum-User daraus einen Win-Linux-Krieg machen?
:freak:
"Zurückhalten" impliziert geheim halten, das wird ja anderswo auf Spezialseiten berichtet, und ich habe ja gesagt wenn es für Nutzer hilfreich sein könnte weil sie irgendwas machen müssen um einen Schaden zu haben, z.B. keine Updates machen weil der PC sonst nimmer bootet.

CB berichtet ja nicht über alle Sicherheitslöcher die Frage ist also was ist das Kriterium, Langeweile des Autors oder wenn man gut ne Überschrift daraus machen kann wie "30 Jahre blabla" da Linux nicht häufiger mal wieder bei fast 0 anfängt wie Windows sondern alles mehr Evolution statt Revolution ist, ist das nicht verwunderlich das viele Bugs sehr alt sind.

Und ja ich halte es selbst bei ähnlichen Bugs fair nur über den Windows BUG zu berichten, 1. zahlt man bei Linux in der Regel nichts, also woher kommt das Anspruchsdenken 2. hat Windows höheren Marktanteil, wenn Windows extrem teuer nunmal ist, und dort schafft es dieser Milliardenkonzern nicht Dinge auf die Reihe zu kriegen und selbst die Fixes kommen oft lahm ist das eher ein Skandal wenn das bei Linux passiert.

Ich mein wenn ein Tabakkonzern irgendwo seine Mitarbeiter schlecht behandelt wird das auch mehr berichtet wie wenns Greenpeace tut... Bias ist in Journalismus ganz normal ist halt die Frage in welche Richtung.
 
Es geht hier doch nicht um Skandale oder, dass man den Underdog schützen sollte. Es geht um die Information, dass auch Linux kein Freifahrtschein ist.
Und mal Hand auf's Herz. Wie viele User sind selber in der sudo-group? Anständig wäre es, sich einen zweiten Account zuzulegen. Und auch darum müssen solche News immer wieder sein. Denn selbst Linux-User könnten noch das ein oder andere lernen. :freak:

Man würde doch Unrecht nicht mit Unrecht versuchen wollen zu erklären. Oder Inkompetenz mit Inkompetenz. Oder Faulheit mit Faulheit, oder, oder, oder.
Linux mit der "Schrottigkeit" von Windows schönzureden, fiele in genau diese Kategorie.

blackiwid schrieb:
[...] Evolution statt Revolution [...]
Diesen Satz nehme ich Linus immer noch übel. Das ist kein Feature, sondern eine Krankheit, an der so ziemlich jedes OS krankt.

Mehrfach in der Geschichte des Linux-Kernels hat man die Chance auf Refactoring/-design verschlafen, weil's ja auch so teuer und/oder zeitaufwendig gewesen wäre. Dumm nur, dass es immer schwieriger wird. Man hat sich selbst 'ne Einbahnstraße geschaffen. Das haben die von MS auch hinbekommen. Also mal ganz ruhig mit den Pferden. :freak:
 
Zuletzt bearbeitet:
Blöde Frage, unter Fedora 39 WS, ist die Libc schon gepatcht worden?
Da muss ich wohl yum für verwenden, um mir die Update History anzeigen zu lassen?
Am 1. Februar 2024 wurde laut: yum history info 103 ua. die glibc-2.38-16.fc39.i686; glibc-2.38-14.fc39.x86_64 updated.
Da ist die ibc.so.6 enthalten oder?
 
Hab mal getestet ob der Patch funktioniert, mit:

Code:
(exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null)

Und außer ein Fehlerhafter Anmeldeversuch passierte nichts. Den Befehl solltet ihr nicht in produktiv Umgebungen testen. Immer gut wenn eine Lücke mehr geschlossen wird.
 
Zurück
Oben