[English]Die Qualys Threat Research Unit (TRU) hat vor kurzem vier signifikante Schwachstellen in der GNU C Library (glibc) aufgedeckt. Diese Bibliothek wird in unzähligen Linux-Anwendungen der gängigen Linux-Distributionen verwendet. Die Schwachstellen ermöglichen Angreifern root-Rechte auf den Linux-Systemen zu erlangen.
Anzeige
Die GNU C Library, oder glibc, ist eine wesentliche Komponente von praktisch jedem Linux-basierten System und dient als zentrale Schnittstelle zwischen Anwendungen und dem Linux-Kernel. Schwachstellen in dieser Bibliothek wirken sich auf die Sicherheit der Linux-Distributionen aus.
Schwachstelle in GNU C Library (glibc)
Ich bin über nachfolgenden Tweet auf den Sachverhalt, der von Qualsys im Beitrag Qualys TRU Discovers Important Vulnerabilities in GNU C Library's syslog() dokumentiert wurde, aufmerksam geworden.
Es handelt sich um insgesamt vier Schwachstellen CVE-2023-6246, CVE-2023-6246, CVE-2023-6779 und CVE-2023-6780. Bei CVE-2023-6246 handelt es sich um einen Heap-Based Buffer Overflow in der __vsyslog_internal()-Funktion.
- CVE-2023-6779 (glibc): Diese Sicherheitslücke beinhaltet einen Heap-basierten Pufferüberlauf in der Funktion __vsyslog_internal().
- CVE-2023-6780 (glibc): Es handelt sich um ein Integer-Überlauf-Problem in der Funktion __vsyslog_internal().
Die Schwachstelle (CVE-2023-6246) in der Funktion __vsyslog_internal() der GNU C Library betrifft syslog() und vsyslog(). Diese Heap-basierte Pufferüberlauf-Schwachstelle wurde versehentlich in glibc 2.37 (August 2022) eingeführt und anschließend in glibc 2.36 zurückportiert, während eine andere, weniger schwerwiegende Schwachstelle (CVE-2022-39046) behoben wurde.
Die Schwachstellen in den glibc-Funktionen syslog und qsort verdeutlichen laut Qualsys, dass selbst die grundlegendsten und vertrauenswürdigsten Komponenten nicht vor Fehlern gefeit sind. Die Auswirkungen dieser Schwachstellen gehen weit über einzelne Systeme hinaus und betreffen viele Anwendungen und potenziell Millionen von Benutzern weltweit.
Große Linux-Distributionen wie Debian (Versionen 12 und 13), Ubuntu (23.04 und 23.10) und Fedora (37 bis 39) sind nachweislich verwundbar. Dieser Fehler ermöglicht eine lokale Privilegienerweiterung, die es einem unprivilegierten Benutzer ermöglicht, vollen Root-Zugriff zu erlangen, wie in Fedora 38 demonstriert. Die Schwachstellen wurden im Dezember 2023 entdeckt und gemeldet, im Januar 2024 gab es Patches, so das Qualsys den Sachverhalt jetzt offen gelegt hat.
2015
Immerhin scheinbar nur lokal ausnutzbar, nicht übers Netz. Aber ein Wunder, dass es in Linux überhaupt solche Fehler gibt.
Vorsicht mit dem "nur lokal"….
Man kann sich das Ei auch selbst legen.
Nö, kein Wunder.
In Linux gibt es kaum weniger Lücken als in Windows, nur liest man davon in der Presse etc. kaum etwas.
Linux zieht seinen Sicherheitsvorteil primär aus der Tatsache, das es weniger verbreitet ist als Windows und daher deutlich seltener Ziel von Angriffen wird.
Zudem benutzen deutlich weniger DAUs Linux als Windows.
Im Übrigen dürften diese Lücken auch in MacOS vorhanden sein, denn das verwendet ja seit ein paar Jahren Linux als Unterbau.
Auch Android verwendet Linux als Unterbau und müsste ebenso betroffen sein.
Nein, Mac-OS nutzt den Mach-Kernel, der wiederum von einem der zweidrei BSD-Geschmacksrichtungen abstammt.
>>Linux zieht seinen Sicherheitsvorteil primär aus der Tatsache,
>> das es weniger verbreitet ist als Windows und daher deutlich
>> seltener Ziel von Angriffen wird.
Man kann mit Fug und Recht sagen, dass eher das genaue Gegenteil der Fall ist – die überwiegende Mehrheit der "dem Internet exponierten" Geräte (Server, Firewalls, Router, Switches, usw.) basieren auf Unix / Linux bzw. sind ein entsprechendes Derivat. Und das ist nicht erst seit gestern der Fall sondern das war schon vor 20 Jahren so.
In der heuten "vernetzten IOT-Welt" trifft dies noch viel mehr zu wo Linux-Derivate in Waschmaschinen, TV-Geräten, Fahrzeugen, Staubsaugern, uvm. eingesetzt wird.
Linux zieht seinen "Sicherheitsvorteil" (wenn man das in dem Kontext überhaupt so nennen kann) also definitiv *nicht* aus der geringen Verbreitung sondern aus der Tatsache, dass es Open Source ist und der Quellcode – inklusive eventueller Fehler – frei einsehbar ist und somit von einer Vielzahl von Menschen unabhängig voneinander geprüft werden kann. Und da lautet die Weisheit bekanntlich "viele Augen sehen viel" – jedenfalls viel mehr als ein paar Hundert Microsoft-Mitarbeiter / eine Microsoft-AI wo dann nachher ein Management entscheidet was aus eventuell intern gefundenen Problemen gemacht wird.
"wo Linux-Derivate in Waschmaschinen, TV-Geräten, Fahrzeugen, Staubsaugern, uvm. eingesetzt wird."
Das sind keine lohnende Ziele.
Das ist nachweislich falsch. Wenn diese Geräte erreichbar sind und entdeckt werden, werden bekannte Schwachstellen ausgenutzt und die Geräte in Botnetze integriert, um dann damit weitere Angriffe zu starten.
Naja, IoT-Geräte mit Linux sind aber eher weniger das Ziel von Ransomware o.Ä.
Nun ja … ich stelle meine Gedanken hier nicht öffentlich, recherchiere, wo Botnetze drauf laufen und schau meinen aktuellen Beitrag zu Volt Thypoon an. Denke, da läuft ein Linux-Unterbau als Firmware mit. Aber die ganze Diskussion "Linux ist besser, nein Windows ist zuverlässiger" hier in den Kommentaren ist irgendwie Kindergarten.
Vielleicht braucht es mal wieder einen gescheiten Browser-War zum Ablenken ;)
Aus persönlicher Sicht empfinde ich unsere Linux-Installationen in der Familie immer noch als viel sicherer als Windows, da Klickibunti-Anklicken sicher nicht so schnell zur Katastrophe führt. Und dies ist sicherlich *auch* der geringen Verbreitung zu verdanken.
Und für die Schule der Kleinen hat bisher immer noch LibreOffice ausgereicht, das "Killerargument MS-Office only" zieht hier nicht – zumindest noch nicht.
** In Linux gibt es kaum weniger Lücken als in Windows, nur liest man davon in der Presse etc. kaum etwas. **
Wohl kaum:
Vielmehr daraus, das das Problem bereits auf diversen Distros bereits gefixt ist – und solche Sicherheitslücken nicht wochenlang offen wie bei Windows üblich rumstehen.
Vielmehr daraus, das auf GNU/Linux Systemen oft nur Software von vertrauenswürdiger Repositories installiert wird, welche im "gesamten" gepatcht sind.
Vielmehr daraus, das unter Windows oftmals Software ihren "Binary-Verzeichnissen" unter C:/Programe volle User-Schreibrechte samt Subdirectorys geben.
Vielmehr daraus, das unter Windows jeder noch so windige Thirdparty Softwareanbieter sich Kernelrechte erheischt.
" und solche Sicherheitslücken nicht wochenlang offen wie bei Windows üblich rumstehen."
Du glaubst tatsächlich, dass eine Sicherheitslücke erst dann existiert, wenn ein "ehrlicher Finder" entdeckt und meldet?
Süß.
Microsoft hat strukturelle Sicherheitsprobleme aus o.g. Gründen.
Bei den meisten erfolgreichen Ransomware-Angriffen handelt es sich im übrigen nicht um unbekannte Zeroday-Bugs – sondern um längst bekannte, und nicht zeitnah gefixte Probleme.
"Heartbleed" (CVSS 11/10) blieb 2 Jahre lang "unentdeckt", "log4shell" 8 Jahre. Kein Wunder, warum sollte eine Heerschar an fähigen Programmierern und Sicherheitsforschern in der Freizeit Billionen Zeilen Code prüfen? Open Source-Sicherheit ist eine Illusion. Eher im Gegenteil: Open Souce vereinfacht auch böswilligen Akteuren die professionelle und zielgerichtete Suche nach Exploits und langfristige Verwendung dieser – die nutzen ganz andere Ressourcen als D3struct0r in Mamas Einliegerwohnung.
Dennoch bin ich von der These "Linux ist sicherer als Windows" mittlerweile auch überzeugt. Die katastrophalen Fehler Microsofts in jüngster Zeit sprengen jede Vorstellungskraft.
Und wieviele erfolgreiche Ransomeware-Angriffe auf Basis von "Hearblead" und "log4shell" gabs in den Jahren?
Und wielange dauerte es bis die Probleme Weltweit in den Distros gefixt waren? 1Woche?
Wenn es um erfolgreiche Ransomeware Angriffe geht les ich meistens von Windows/Active Directory, Exchange, Emailanhänge, Office/PDF etc. Und das inzwischen mehrfach wöchentlich.
Die Windows-Infrastruktur hat offensichtliche strukturelle Sicherheitsschwächen die es Angreifern leichter macht in die Systeme einzudringen, als unter GNU/Linux.
Neid und Missgunst des MS Fanboys sprechen wieder für sich…
Was soll dieser Kommentar?
Ich bin weder MS Fanboy noch Linux Fanboy.
Es ist nun einmal statistischer Fakt, das Linux nicht weniger Sicherheitslücken hat als Windows.
Schau dir die CVE-Statistiken an!
Am Schlimmsten bzgl. Sicherheitslücken ist übrigens Android.
Beispielsweise 2017 gefundene Sicherheitslücken mit CVE-Eintrag:
Android = 841
Linux Kernel = 453
iOS = 387
MacOS = 299
Windows 10 = 268
Winows 7 = 229
Und 2022:
Fedora = 944
Android = 897
Debian = 884
Windows Server 2019 = 553
Windows 10 = 524
Windows 11 = 501
Windows Server 2022 = 422
Windows Server 2012 = 414
MacOS = 379
Generell: Jeder, der in der Thematik drin ist, wird das nicht bestreiten. Nur: Es nützt dir nichts, wenn die eine unentdeckte Schwachstelle ausgenutzt wird, dass dein Betriebssystem nur ganz wenige Schwachstellen hat.
Der Ausdruck "Fanboy" kam, weil einige Leute, u.a. 1ST1, wieder mit der unendlichen Leier "mein rotes Förmchen ist hübscher" anfingen. Ich saß heute Nacht schon an der Tastatur und hab überlegt "löschst Du hier eine Reihe Kommentare", aber da war der Gedanke "das ist dir die Zeit nicht wert". Ich hege ja immer noch die Hoffnung, dass einzelne Leute irgendwann "über diesem Klein-Klein" stehen.
Der Zweck des Beitrags war, über die Schwachstelle zu informieren, in der Hoffnung, dass die Betroffenen unter der Leserschaft dann schauen, wo sie updaten oder absichern müssen. Stattdessen fühlen sich eine Menge Leute hier bemüßigt, den Nebenkriegsschauplatz "wo sind die meisten Sicherheitslücken" zu bepflügen. Denkt einfach beim nächsten Kommentar darüber nach – danke!
1ST1 scheint ja weder hier zu bremsen zu sein noch im Artikel über LibreOffice.
Man muss sich echt fragen, was das für eine Lebenseinstellung ist bzw welchen Zweck man verfolgt, wenn man neben einigen wenigen sinnhaften Kommentaren fast ausschließlich Neid und Häme hier verbreitet.
@ R.S:
Der Kommentar von Ottilius ging gar nicht an dich, sondern an "1ST1", der ist hier ein bekannter Microsoft-Fanboy und reagiert auf Linux sarkastisch.
Die vielen gefundenen Fehler bei Debian liegen auch an Google, weil die das intern einsetzen und mit ihrem Project-Zero alles durchtesten und jede Funktion mit fuzzing etc quälen.
Findet man dann in Debian einen Fehler, dann gilt der auch fast immer für Fedora etc ebenso.
Ist doch gut, wenn so viele Fehler gefunden und beseitigt werden.
Wenn bei diesen Tests von Preoject-Zero nichts gefunden wird, dann wird es auch für Hacker sehr schwierig, noch Fehler zu entdecken, denn vermutlich sind dann keine mehr drin.
Microsoft führt solche Tests in diesem Umfang im eigenen OS nicht durch.
was ist daran ein wunder? warum sollten die bei Linux besser programmieren können als bei Microsoft, Google oder Apple. Alles nur eine Frage der Verbreitung.
In Fedora 39 wurde schon auf glibc 2.38 gefixt, ob das auch die Schwachstellen beseitigt weiß ich allerdings nicht 😃
Open Source – viele prüfen angeblich den Code und alles ist wesentlich sicherer – ist das so? Zweifel sind angebracht.
@TBR – Zweifel sind immer angebracht: trau, schau, wem …
Jedoch traue ich denen – und seh kaum "Absicht". Sehe dies eher im enormen "Druck" der Entwicklung. Gebackportete Fehler waren schon neulich in Diskussion hier beim Filesystem als critical ein Thema.
Lass uns doch unsere Zweifel einbringen in die OSS-Community. Jede Mail-List von Kernel bis zu Packages lädt dazu ein …
… und dann versuch solches "Einbringen" mal bei Microsoft ;-)
p.s.: Kernelentwicklung mit Linus Torvalds ist letztens sogar ausgefallen laut lkml hier wegen Schneesturm
Eine Googlesuche (oder auch jede andere) nach "opensource sicherer" offenbart alles zu diesem Thema.
Nein nein alles sicher! Ganz bestimmt! Bin da völlig überzeugt davon. Komisch, wo sind die Kommentator-Kollegen, die das immer behaupten gerade? Mal drüben in Heise gucken…
Herrlich, wie die MS Trolle es mal wieder nicht verstehen und sich hier zum … machen :-)
Das läuft doch in der Regel so ab:
Sicherheitslücke unter Linux gefunden, Fix erstellt, eingespielt, fertig.
Sicherheitslücke unter Windows gefunden, erstmal nichts von MS, irgendwann dann vielleicht ein Fix. Der kommt dann mit Windows-Update und zerstört Teile oder auch mal das ganze System. Dann kommt vielleicht der Rückruf dieses Updates und (nicht unbedingt zeitnah) der Fix zum Fix und wenn dann auch noch die Sonne scheint und die MS Jünger brav ihren Teller leer gegessen haben, funktioniert dieser sogar – meistens, nicht immer
Drum merke, während die Windowser noch frickeln und sie im Hamsterrad rennen, um das System irgendwie am Laufen zu halten, sind Limuxer, BSDler, MacOSler usw schon längst produktiv :-D
Kann man das testen? Die Versionsnummern durchzugucken kann ja zu langweilig sein :-) Test geht zB (bitte nicht auf operativen Systemen und mit Sorgfalt) so:
– Als normaler User
– Auf der Shell mit:
(exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null)
1. Es sollte kurz (ca 1s) die Eingabaufforderung nach Passwort erscheinen
2. dann liefert "printf" weitere 128.000 Nullen auf der Konsole
3a.Verwundbar? Dann Error zB "Segmentation fault", core dumped
3b. OK? Dann "nur" Error "Fehler bei Authentifizierung"
Nein! … Doch! … Uhh ;-P
Nein, wirklich nicht, alles gut! Ist Opensource, jeder Anwender hat den Code selbst geprüft und für fehlerfrei befunden. Das Grundprinzip von OS funktioniert!
Der Quellcode wurde ohne Anlass (es gab keinen Hackerangriff) überprüft und der Fehler gefunden.
Bei closed Source wie bei Windows wäre sowas nicht möglich gewesen.
Dank open Source und dank freier Software konnte der Fehler auch behoben werden, ohne erst auf einen Konzern warten zu müssen, bis der einen Patch veröffentlicht.
In Windows müsstest du Fehler in den Dateien msvcrt*.dll, mfc*.dll, msvcp*.dll, vcruntime*dll etc suchen, finden und beheben.
Dazu kommt noch, dass bei Windows oftmals ein Programm seine eigenen c-Libraries in älteren ungepatchten Versionen im eigenen Programmordner benutzt anstelle der Version im Windows-Ordner.
Ich gehe sogar die Wette ein, dass genau das bei dir aktuell der Fall ist. Du hast in deinen Programm-Ordnern ältere ungepatchte Versionen der c-Libraries und vielleicht sogar nichtmal im Windows-Ordner die aktuellen Versionen, denn die kommen nicht immer über Windows-Update.
Updates für die Visual-C-Runtimes werden oft nicht an die große Glocke gehängt und man übersieht leicht, die manuell zu installieren.
Aber selbst wenn, bleiben die älteren unsicheren Versionen weiterhin in den Programmordnern, wenn die einzelnen Software-Hersteller kein eigenes Update liefern.
Wenn ich bei mir mit Total Commander nach den c-Libraries in den Programm-Ordnern suche, dann finde ich eine lange Liste mit älteren Versionen.
Wäre man bösartig, dann könnte man das bestimmt ausnutzen.
Es kann sogar sein, dass ein paar Programm die c-Libraries statisch reingelinkt haben, so dass man die mit einer Dateisuche gar nicht mehr entdecken kann und auch nicht so einfach durch Austausch der c-Libraries updatebar sind, ohne alles neu zu kompilieren.
Offene freie Software hat also wirklich Vorteile.
CVE-2023-6246: This issue affects glibc 2.36 and newer
CVE-2023-6779: This issue affects glibc 2.37 and newer
CVE-2023-6780: This issue affects glibc 2.37 and newer
www[.]suse[.]com/security/cve/
Bei Debian 12 (bookworm) ist die gefixte glibc Version: "2.36-9+deb12u4"
(auf das "u4" am Ende achten, Update 4).
Bei Debian 11 (bullseye) ist die gefixte Version: 2.31-13+deb11u7
(auf das "u7" am Ende achten, Update 7)
Bei Debian SID ist die gefixte Verison: 2.37-15
security-tracker[.]debian[.]org/tracker/CVE-2023-6779
Bei Fedora ist die gefixte Version "glibc-2.38-16.fc39".
bodhi[.]fedoraproject[.]org/updates/FEDORA-2024-aec80d6e8a
In Gentoo wird die gefixte Version "glibc-2.38-r10" sein.
Linux Mint ist nicht betroffen, weil es auf Ubuntu LTS 22.04 basiert und da ist die glibc zu alt (vor August 2022).
Red Hat und SUSE Enterprise Linux sind nicht von dem Fehler betroffen, weil beide OS eine ältere Version benutzen.
access[.]redhat[.]com/security/cve/cve-2023-6779
www[.]suse[.]com/security/cve/CVE-2023-6779.html
—
openSUSE Tumbleweed benutzt aktuell glibc 2.38-8.1 vom 9.Januar 2024
CVE-2023-6246
glibc 2.36 gefixt seit: 2024-01-31T14:15Z
glibc 2.39 gefixt seit: 2024-01-31T18:15Z
repology[.]org/project/glibc/cves?version=2.38
repology[.]org/project/glibc/packages
CVE-2023-6779 und CVE-2023-6780 sind in dieser Liste noch gar nicht eingetragen.
Die bash stürzt ab, wenn man den Test-Befehl eingibt.
openSUSE Tumbleweed ist also noch betroffen.
Soweit ich inzwischen informiert bin, muss hier wieder mal ein Angreifer physischen Zugriff haben und als User angemeldet sein… gähn.
"unprivileged user to full root" klingt schon nicht gut, weil das doch die user-namspaces sind oder? Und das verwendet dann z.B. der Firefox, Flatpak und ggf. andere Programme.
Oder liege ich da ganz falsch?