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: Exim 4.97.1 zerbricht Munin – How To Fix

Das neue Jahr fängt ja gut an, Fedora User dürfen Ihre Mailserver einmal mehr selbst fixen 🙁

Fedora: Exim 4.97.1 zerbricht Munin – How To Fix

Heute Nacht kam das Exim 4.96 auf 4.97.1 Update ins Stabel und reihenweise sind uns die Munininstallationen um die Ohren geflogen. Grund ist ein Fehler beim Parsen der mailq Übersicht von exiqgrep .

Munin ruft exiqgrep -cz auf und wertet dann per interessanter AWK Anweisung die Ausgabe aus, aber das geht nicht mehr, weil exiqgrep einen Fehler meldet:

# exim -bpu
9h 2.2K 1rO3sE-005JbF-1D-H <> *** frozen ***
 xxxx@xxxxxx.de

# exiqgrep -cz
Line mismatch: 9h 2.2K 1rO3sE-005JbF-1D-H <> *** frozen ***

gebraucht wird das im Munin Plugin: exim_mailqueue

Ursache ist eine defekte RegExpression in exiqgrep Zeile 217:

Line 215:      if ($line =~ /^\s*(?<age>\w+)
Line 216:          \s+(?<size>(?:\d+(?:\.\d+)?[A-Z]?)?)
Line 217:          \s*(?<msgid>(?:\w{6}-\w{6}-\w{2}|\w{6}-\w{11}-\w{4})) # old, 2023 msgid formats
Line 218:          \s+(?<from><.*?>)/x) {

Die Zeile 217 muß man nur so ändern:

\s*(?<msgid>(?:\w{6}-\w{6}-\w{2}|\w{6}-\w{11}-\w{4}))(?:-H)?     # old, 2023 msgid formats

und schon ist das Problem gelöst.

Natürlich gibt es einen aktiven Fedora Bugreport dazu. Ich frage mich nur, wieso jemand einen neuen Exim baut und dann nicht alle Patche bis zu dem Stand einbaut?

Quelle: Exim Dev ML & https://bugzilla.redhat.com/show_bug.cgi?id=2258027exim_mailqueue