Fedora All: Root-Exploit in der glibc

Heute, händische Updates sind angesagt, wenn Ihr z.b. Server betreibt, weil in allen Glibc Versionen in Fedora & Anderen Distros ein Root-Exploit ist.

Fedora All: Root-Exploit in der glibc

Die Updates sind erst gestern auf den Testserver gekommen und nicht als CritPathupdate markiert worden, was meint, ohne Karma von Betatestern werden die Updates erst in 2 Wochen eingespielt, wenn sie automatisch ins Stable gepusht werden.

Tue Jan 30 2024 Patsy Griffin <patsy@redhat.com> – 2.37-18

  • Auto-sync with upstream branch release/2.37/master,commit 2b58cba076e912961ceaa5fa58588e4b10f791c0:

  • syslog: Fix integer overflow in __vsyslog_internal (CVE-2023-6780)

  • syslog: Fix heap buffer overflow in __vsyslog_internal (CVE-2023-6779)

  • syslog: Fix heap buffer overflow in __vsyslog_internal (CVE-2023-6246)

  • sunrpc: Fix netname build with older gcc

Golem war so freundlich das mal auszuformulieren:

„Sicherheitsforscher von Qualys haben mehrere Schwachstellen in der weitverbreiteten Gnu-C-Bibliothek (glibc) entdeckt. Eine davon, registriert als CVE-2023-6246, bezieht sich auf die Funktion __vsyslog_internal() und ermöglicht es Angreifern, in der Standardkonfiguration mehrerer gängiger Linux-Distributionen einen Root-Zugriff zu erlangen, indem sie einen Heap-Pufferüberlauf auslösen. Der Angriff erfolgt über die häufig genutzten Logging-Funktionen syslog() und vsyslog().“
Quelle: https://www.golem.de/news/debian-ubuntu-und-mehr-glibc-schwachstelle-ermoeglicht-root-zugriff-unter-linux-2401-181724.html

Was Fedoranutzer jetzt machen müssen sieht so aus:

dnf -y update –enablerepo=updates-testing glibc

Und was ist mit Dockerimages?

Glückwunsch! Die dürft Ihr ALLE updaten und wenn es keine Updates gibt, dann empfehle ich erst mal abschalten, prüfen, ob es eine Möglichkeit gibt, das EXTERNE den Exploit in den Container befördern können und wenn Ihr das bejaht, dann  dürft Ihr in löschen, oder warten bis sich jemand erbarmt und ein Update für das Baseimage verteilt, wo der glibc Fix dann hoffentlich drin ist.

Die gängigen Containerkonstrukte sind ja soooooo eine gute Idee, das man vor Freude kotzen könnte.

Unsere Server-VMs sind jedenfalls alle save mit einem zentralen Updatebefehl, denkt mal drüber nach 😉

Fedora: GlibC Update zerdängelt „Deutsch“

Das neueste Glibc Update zerlegt leider bei Fedora die Umlaute in allen neu gestarteten Programmen.

glibc-2.29.29 – Update mit Problemen

Das neueste ( 25.3. ) glibc Update, daß nach 14 Tagen ohne Karma gestern ins Stable gepusht wurde, weil es mal wieder keiner getestet hat, hätte mal lieber von Leuten getestet werden sollen : Es ist leider defekt  🙁

Im Thunderbird zeigt sich das Problem mit Ordnernamen, die deutsche Umlaute enthalten:

Außerdem kann Thunderbird keine Nachrichten mehr speichern, wofür ich noch keine Erklärung habe, da dort gar keine Umlaute im Spiel sein sollten.

Lösung:

Ihr laded Euch für FC30 folgende Pakete im Koji runter:

glibc-2.29-28.fc30.i686
glibc-2.29-28.fc30.x86_64
glibc-common-2.29-28.fc30.x86_64
glibc-devel-2.29-28.fc30.x86_64
glibc-headers-2.29-28.fc30.x86_64
glibc-langpack-de-2.29-28.fc30.x86_64  (siehe Unten)
glibc-langpack-en-2.29-28.fc30.x86_64
libnsl-2.29-28.fc30.x86_64
nscd-2.29-28.fc30.x86_64

Den Link dazu gibt es hier:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1431046

Aber Vorsicht, nicht die falschen Pakete runterziehen, sonst geht nichts mehr. I686 und X86_64 sollten es schon sein.

Als Root führt Ihr dann das Downgrade aus im Downloadverzeichnis aus:

dnf downgrade ./nscd-2.29-28.fc30.x86_64.rpm ./libnsl-2.29-28.fc30.x86_64.rpm ./glibc-*rpm

Idealerweise beendet Ihr Thunderbird und alle anderen betroffenen Programme vorher und started es danach wieder.

Hinweis: Ihr habt ggf. nicht die langpack’s „de“ und „en“ installiert, sondern denn „glibc-all-langpacks“. Also braucht Ihr dann folglich auch „glibc-all-langpacks-2.29-28.fc30.x86_64.rpm“.

dann noch verhindern, daß es Updates gibt, bis das Problem gelöst wurde:

echo „exclude=glibc* nscd* libnsl*“ >> /etc/dnf/dnf.conf

Danach die Datei prüfen, ob da jetzt nicht zwei Zeilen Exclude drin sind und ggf. anpassen.

Fedora 28 und das Upgradeaftermatch

„Hey, Fedora 27 ist Geschichte, freu Dich auf Fedora 28, User!“ Ich habe ihn nicht gehört, aber der MCP hat das bestimmt vorhin beim Upgrade gesagt oder gedacht. Leider hat es nicht funktioniert.

Keine Friends in Sicht…

Ja, heute war es soweit: das obligatorische Sechsmonatsupgrade auf Fedora 28 war dran. Auf dem Laptop läuft es seit letzter Woche, also sollte das ja jetzt kein Problem werden. Flugs den Desktop stoppen, in eine Root-Shell und DNF mit Arbeitsanweisung versorgen. Gesagt, getan. 15 Minuten später waren alle 3800 Pakete geladen und bereit. Zwei unwichtige Downgrades und 3 unwesentliche Altpaketentfernungen waren abgesegnet. Schritt 1/7550 kam in Sicht und …. hey… (nanü? Was ist mit der Absatzüberschrift los?)… ging 🙂

7550 Schritte später, wartet mein Cursor, meine Root-Shell und mein neues Fedora auf mich, also „reboot“ getippt, beide Daumen zerquetscht und gewartet. Bios .. Grub \o/ … die seit Jahren vertraute Meldung, daß die Kernel-Module vom Systemd nicht geladen werden konnten…( Anm.d.R „auch diesmal“ wieder nicht 🙁 ) .. Fedora Bootlogo… wird weiß… Login! … DESKTOP! … P.R.O.G.R.A.M.M.E !.! … was ist das denn?

„Wollen Sie die Default Ordner rename to die lokal gewählte Sprache…“

Was zum Geier… wie kommt Cinnamon darauf, daß ich bei einem Deutschen Desktop englische Verzeichnisnamen haben können wollte? Könnten die Spracheinstellungen defekt sein? Nachguck.. Nö. Deutsch/Deutsch. Sieht ok aus. „Da hat bestimmt Gnome beim Update was zerlegt.“ war der Gedanke, also ins Gnome gewechselt… was ein schwerer Fehler war, den GNOME ist nicht mehr .. DAS hat es tatsächlich beim Upgrade zerlegt, denn die Gnome-Shell kommt nicht an den Start. Die Programme schon, aber ohne Windowmanager nützt das nicht viel 😀 … Hmm.. Programme melden sich aber in Deutsch, das ja komisch.

Mit STRG+ALT+F3 ab in die Root-Shell, anmelden …. was ist das denn? „setlocale: Konnte LC_TIME nicht setzen“ (War natürlich auf english, aber zum besseren Verständnis wird es hier eingedeutscht). Wie kann das denn sein?

Kurz mal die Umgebungsvariablen checken:

# strings /proc/self/environ 
...
LANG=de_DE.UTF-8
...
_=/usr/bin/strings


# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Alles ok, Deutsch ist eingestellt. Übersetzungen gingen ja in den Programmen, aber tatsächlich war die Zeit in English mit 12H+AM/PM .. schauen wir doch mal mit strace auf welche Locale will das Programm eigentlich zugreifen: also „strace -f locale de_DE.UTF-8“ eingegeben und es würde gern diese Datei benutzen „/usr/lib/locale/de_DE.utf8/LC_TIME“ … ist ja merkwürdig, die ist gar nicht vorhanden…. hey! den ganzen Ordnerbaum gibt es gar nicht! HIER FEHLT DEUTSCH!

Und so behebt man das

Die Sachelage ist klar: Keine Deutsche Locale vorhanden, also nachinstallieren. Da wir den Pfad kennen, fragen wir dnf wer das bereitstellen könnte:

# dnf provides „/usr/lib/locale/de_DE.utf8/LC_TIME“

glibc-langpack-de-2.27-32.fc28.x86_64 : Locale data for de
….

also installieren wir das und rebooten kurz ( damit auch die Bootprozesse in Deutsch melden können, wenn Sie das wünschen):

# dnf install glibc-langpack-de

und da merkt man dann, daß das kein Witz war, weil der jetzt „j“ nicht mehr als „ja“ => „yes“ erkennt .. muß man also wirklich „y“ drücken 🙂

Nach dem Reboot war es dann in Ordnung. Warum der den Language-pack nicht installiert hat, werden wir nicht erfahren. Um GNOME werde ich mich wohl mit „rm -rf .config/gnome-session“ kümmern müssen.

Update Tag 2:

Die WetterApp geht nicht. Libmozjs crasht beim Start extrem hart, incl. Coredump. Autsch. Mal sehen was von den HinterbänklerApps noch so nicht geht.