PVA: ups … da fehlte was bei der „KI“

Benutzer, die Carola PVA per RPM installiert haben, mußten leider feststellen, daß Ihr Assistent nicht funktioniert hat.

PVA: ups … da fehlte was bei der „KI“

Der Push der „KI“ Funktion hat leider bei allen, die keine „KI“ Config hatten, und das dürften viele gewesen sein, zu einem kleinen Startproblem geführt. Wer die Githubversion benutzt hat, hatte da weniger Probleme.

Die Patche dafür sind raus, die RPM’s auch, also updated jetzt bitte und startet dann den Clienten neu.

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: Alarm – Firefox 117 händisch einspielen, weil nicht im Repo :(

Ein Fehler im Workflow der Fedora Buildfarm führt zu dem Problem, daß wir Firefox 117 jetzt händisch einspielen müssen, denn in 117 sind eine Menge kritischer Lücken gestopft worden.

Fedora: Alarm – Firefox 117 händisch einspielen, weil nicht im Repo 🙁

Wie man dem Securityreport von Mozilla für Firefox 117 entnehmen kann, gibt es 6 schwere Lücken in Firefox, die man ausnutzen kann um z.B. aus der Sandbox auszubrechen, oder Programmcode auszuführen.

Normalerweise bereitet Martin die Firefox Updates gewissenhaft vor und das seit Jahren, wofür man ihm nicht oft genug Danken kann! Diesmal ist allerdings etwas schief gegangen.

Am Montag gegen 14 Uhr wurden die BuildJobs für F37-F40 ( jaja, Leute 40!!! ) gestartet und hätten so 2-5h gebraucht. Am Mittwoch „liefen“ die Prozesse immer noch, da habe ich mal Alarm geschlagen, denn seit Dienstag waren die Bugs bekannt, da werden die Exploits bald fertig sein.

Wie Kevin Fenzi dann nach mehrmaligem Nachhaken meinerseits, feststellte, hingen die VMs fest (muß das neue Java Update drauf sein 🙁 ). Die Jobs mußten auf echte Baremetall Maschinen umgezogen werden, wo sie dann Mittwochabend gegen 21 Uhr auch fertig waren. Ich habe dann Firefox sofort getestet und für Ok gefunden, konnte aber keinen Bodhi Vorgang finden, wo man dem Build das Karma gegeben konnte, um es ins Stable zu puschen.

Stellt sich raus: Keine Jobs im Bodhi drin, was auch bedeutet, keine RPMs im Updates-Testing Repo 🙁

Und das bringt uns direkt zu den Anweisungen, wie Ihr jetzt gleich Euren Fedora PC aktualisieren könnt/solltet:

Fedora 37:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc37/x86_64/firefox-117.0-1.fc37.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc37/x86_64/firefox-langpacks-117.0-1.fc37.x86_64.rpm

Fedora 38:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc38/x86_64/firefox-langpacks-117.0-1.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc38/x86_64/firefox-117.0-1.fc38.x86_64.rpm