Firefox 73.0 für FC30 und FC31 verfügbar

Es ist mal wieder soweit, eine Sicherheitslücke in Firefox und Thunderbird ( da nicht dramatisch mangels Scripting ) zwingt Euch zu einem Update. Ja, „Euch“, weil ich habe schon 😉

Firefox <73.0 mit Sicherheitslücken

Memory Corruption, Sicherheitslücke, wenn Firefox PDF Reader spielt(ARGS!) und eine RCE Schwachstelle, bei der ein Angreifer Code in Firefox ausführen kann ( und nicht nur in der Webseite im Firefox 😉 ) sind nur einige der Löcher die damit gestopft werden. Kleine Liste:

Mozilla Foundation Security Advisory 2020-05
Security Vulnerabilities fixed in Firefox 73

Announced February 11, 2020
Impact high
Products Firefox
Fixed in Firefox 73

#CVE-2020-6796: Missing bounds check on shared memory read in the parent process

A content process could have modified shared memory relating to crash reporting information, crash itself, and cause an out-of-bound write. This could have caused memory corruption and a potentially exploitable crash.
References

#CVE-2020-6797: Extensions granted downloads.open permission could open arbitrary applications on Mac OSX

By downloading a file with the .fileloc extension, a semi-privileged extension could launch an arbitrary application on the user’s computer. The attacker is restricted as they are unable to download non-quarantined files or supply command line arguments to the application, limiting the impact.
Note: this issue only occurs on Mac OSX. Other operating systems are unaffected.
References

#CVE-2020-6798: Incorrect parsing of template tag could result in JavaScript injection

If a <template> tag was used in a <select%gt; tag, the parser could be confused and allow JavaScript parsing and execution when it should not be allowed. A site that relied on the browser behaving correctly could suffer a cross-site scripting vulnerability as a result.
References

#CVE-2020-6799: Arbitrary code execution when opening pdf links from other applications, when Firefox is configured as default pdf reader

Command line arguments could have been injected during Firefox invocation as a shell handler for certain unsupported file types. This required Firefox to be configured as the default handler for a given file type and for a file downloaded to be opened in a third party application that insufficiently sanitized URL data. In that situation, clicking a link in the third party application could have been used to retrieve and execute files whose location was supplied through command line arguments.
Note: This issue only affects Windows operating systems and when Firefox is configured as the default handler for non-default filetypes. Other operating systems are unaffected.
References

#CVE-2020-6800: Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Mozilla developers and community members Raul Gurzau, Tyson Smith, Bob Clary, Liz Henry, and Christian Holler reported memory safety bugs present in Firefox 72 and Firefox ESR 68.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.
References

# Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Wenn Ihr Euch die Update holen wollt, bevor die automatisch kommen, hier kann man Sie passend runterladen:

FC30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459513

FC31: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459512

 

Update: Fedora: Probleme mit hwdata und Asus Mainboards

Wie bereits vor zwei Tagen mitgeteilt, gibt es bei Fedora ein Problem mit dem Paket hwdata. Darin sind die PCI Ids der Geräte und Hersteller enthalten. Die Quelle der Daten wird bei Github gepflegt und damit betrifft es nicht nur Fedora, sondern alle Distributionen, die Ihre Daten von dort beziehen.

Die Datei oui.txt (Organisational Unit Ids) verursacht dies, offensichtlich sind dort Kennungen falsch eingetragen  oder verloren gegangen, so das Wechselmedien nicht sauber erkannt werden.

Kuriose an der Sache: Der eingesteckte USB Stick war für Root gemountet und nicht für den angemeldeten User.

Wie eine falsche OUI das auslösen kann, wird derzeit geprüft. Ich meine, da liegt ein ziemlich dicker Bug kurz vor seiner Entdeckung.

Update: Fedora 29 bootet nicht nach Upgrade

Kleines Follow-Up auf Warnung: Libreswan kann Ihren Bootprozess stören. Nachdem der Rechner gestern wieder lief, wie man im Beitrag auch nachlesen kann, dachte ich mir, probier das System mal mit allen wichtigen Sachen aus. Keine Fehler, die nicht zu erwarten gewesen wären. Mehrfaches Rebooten lief auch ohne Probleme durch, bis… ja, bis heute morgen.

„Der Morgen danach“ Ein Roman von B.Soffski

Der Reihe nach: Wir verließen unseren Helden, als er sich zur Nachtruhe zurückzog und den Rechner ausschaltete. Ja, ausschaltete. Die Art von Ausschalten, die Veränderungen an so einem Computer unmöglich macht. Die Art, wo das Wort stromlos drin vorkommt. Wir erinnern uns, daß der Computer vor diesem Ausschalten 3x neu gestartet wurde, nur um zu sehen, ob das mit dem Reboot auch wirklich klappt.

„Der Vormittag kam, sah und ihm klappten alle Regentropfen runter!“

Anders ausgedrückt, dieses Fedora 29 bootet schon wieder nicht. Es blieb „wieder“ beim NetworkManagereinsatz hängen 🙁 Das kann einfach nicht wahr sein, der hat doch gestern 3x neu gebootet, wie kann das sein?

„Karma is a Bitch“ ein Buch von L.Eben

Na gut. „Challenge accepted“ Eine gewisse Wut im Bauch ist ja nicht wirklich falsch bei so was, es spornt den Wüterich zu Leistungen an. Was machen? Das gleiche wie Gestern? Einen Versuch ist es wert, aber diesmal nicht in eine Rootshell booten, sondern in Runlevel 1 auch bekannt als Emergency.target von Systemd. Ja, also an sich eine gute Idee, NUR GEHTS NICHT! Was für eine verf******* S******* ist das denn?

Ok, also dem Kernel wieder erzählt „1 init=/bin/bash“, Netzwerk gestartet, dnf update und siehe, wieder ein Update. Aber total irrelevant. Das wars also nicht. /var/log/messages und systemd-journal gesichtet, nichts. Der Bootvorgang ging bis NetworkManager, aber das wars dann. Nicht mal mehr ein Crash, der etwas erklären könnte. Nada!

Auf Verdacht wurde dann „dnf reinstall NetworkManager* systemd*“ durchgeführt und “ systemd.debug-level=1 “ an die Kernelzeile angefügt, damit eine Rootshell bereitsteht, wenn man sie braucht ( ALT+F9 )  und was soll ich sagen, der Rechner bootete wieder in GDM. Was fürn Sch….. was ist das denn? Man kann nicht mehr in den Desktop einloggen ?!?!?! Root-Konsole mit ALT+F3 ( F9 hatte ich im Moment vergessen ), will mit Root einloggen und … sofortiger Logout. Und dann stehst Du da!

F9! Stimmt, einloggen nicht nötig, bin ja schon drin, also ab ins Logfile und ..

The Execution of /usr/lib/systemd/systemd resulted in „Permission denied!“

Äh.. den habe ich doch gerade erst frisch reinstalliert und wieso wird der beim Konsolenlogin aufgerufen?Wird er gar nicht, weil /bin/sh konnte man auch nicht mehr starten, gleicher Fehler „Permission denied!“  … und wenn Du jetzt F*** sagst, sag auch gleich SELINUX! NNNNNNEEEEEEEIIIIIINNNNNNNNNNNN!!!!!!!!!!!!! Nicht schon wieder SELinux! Ich fange an es zu hassen !

Einen Reboot mit dem Kernelparameter „enforcing=0“ später, fährt das System hoch, als wenn nie was gewesen wäre!

Aber was ist jetzt schon wieder mit SELinux und wieso hat das System denn überhaupt nach dem Upgrade gestartet? Das dürfte es doch gar nicht. Antwort: SELinux  ist halt auch nur eine von Menschen gemachte Software 😉

„Die Auflösung“ Ein Film von D.Itrich

Das Problem nahm seinen Lauf im Jahre 2018. Damals gab es ein Problem unter F27 mit den SEL Policies. Nach einem Update der SEL Policypacks startete das System nicht mehr, aber mit der Version davon lief es noch. Also trägt der Linuxer natürlich nach dem Downgrade den Updateinhibiter für das Paket ein und weil alles ein Jahr lang läuft, vergißt man es. Dann kommt das Systemupgrade auf F28 und es läuft auch mit der alten Policy, was blöd ist, weil man so beim Update auf F29 gar nicht mehr an diese Sperre denkt 🙂

Update sperre für die Pakete raus und „dnf update -y“ ausgeführt. Eine Ewigkeit später, weil gleich mal umgelabelt wird, dann die Probe: reboot !  Scheiße, geht!

Ob die Geschichte diesmal zu ende ist, oder ob morgen neuer Ärger auf mich wartet, könnt Ihr leider erst morgen lesen 😉

TPM2 Update zerlegt Fedorainstallation

Ihr habt einen TPM Chip im System ? Ihr setzt Fedora ein und habt deswegen den TPM Chip im Bios abgeschaltet ? Dann jetzt bloß nicht updaten!

Was passiert, wenn SEL auf TPM trifft

Ich fürchte ja, daß es dafür schon zu spät ist, aber sei es drum: NICHT UPDATEN! Sperrt das Paket in /etc/dnf/dnf.conf mit => „exclude=tpm2*“

Ok, das wird jetzt kompliziert, also langsam lesen.

Q: Wen betrifft das ?
A: Rechnerhardware mit einem TPM Chip auf dem Mainboard.

Q: Was ist TPM ?
A: Der Trusted Platform Modul – Chip signiert und prüft im Bootprozess, ob am System rumgespielt wurde und verweigert dann ggf. den Boot. Das macht in der Theorie den Rechner sicherer. Davon ab, kann man in dem Chip auch Digitale Signaturen und andere Kryptografische Informationen speichern und prüfen.

Q: Woher weiß ich, daß ich reinen TPM Chip habe?
A: Schaut ins Bios, der Chip wird da eine Option zum Ein- und Ausschalten haben.

Q: Was verursacht das Problem ?
A: Das Paket tpm2-abrmd-policies in der Version ( tpm2-abrmd-selinux-2.0.0-3.fc29 )  aktiviert beim Update wohl den TPM Chip und/oder setzt falsche SEL Policies im System, so daß der Rechner nicht mehr sauber bootet.

Q: Passiert das immer ?
A: Wissen wir noch nicht, ich war der einzige mit Fedora und TPM Chip.

Q: Sind spezielle Kernel im Spiel ?
A: Nein, wir haben 5.0.3, 4.19.23 und 4.20.5 ausprobiert => spielt keine Rolle.

Q: Wie wirkt sich das aus ?
A: Während des Bootprozesses stürzt der Kernel mit diversen Kernel-OOPS Meldungen ab. Mit Glück bootet er durch, bei mir war vor GDM Schluß mit lustig => System halt.
Wenn er durchbootet, dann bekommt man vom ABRT laufend Meldungen über Kernel-Abstürze, die automatisch behoben werden, teilweise 4x pro Minute.

Gegenmaßnahmen

als Root: systemctl stop tpm2-abrmd;systemctl disable tpm2-abrmd;

Dann rebooten und im BIOS den TPM Chip abschalten. Das hat bei mir dazu geführt, daß der vorherige Kernel 4.19.23 ( zu 4.20.5 ) sauber gestartet ist und im Bootprozess die SEL-Policies neu gesetzt wurden, im ganzen System, was ein Weilchen dauern kann. Danach lief jeder Kernel wieder normal, auch 5.0.3 .

Ein Bugreport wurde bei Red Hat abgesetzt. Ich wette, daß auch die TPM Maintainer vor einem Rätsel stehen, aber ich habe Augen- und Ohrenzeugen, da es mitten in unserer wöchentlichen LUG Sitzung passierte 😉

Update: Beitragstitel geändert, war zu reißerisch.

 

Aus der Schmunzelecke von Bugzilla

Für Euch mal was zum Schmunzeln, das erlebt man auch nicht so oft, daß sich der Maintainer bei den Bugreportern dafür entschuldigt, in den Urlaub gefahren zu sein 😉

--- Comment #3 from Zdenek Dohnal <zdohnal@redhat.com> ---
Hi,

thank you for reporting the issue! I'm deeply sorry for inconvenience, I pushed
the update without cross checking if new net-snmp is already in the stable (I
wasn't able to add hplip to net-snmp update) and I went on vacation after that.
You can install previous version from koji for now
https://koji.fedoraproject.org/koji/buildinfo?buildID=1163784 .

Der Fall stellt sich so dar:

Der Maintainer von hplip, hat als Abhängigkeit net-snmp drin und haut sein Update ins Stable Repo, ohne zu checken, ob den auch die Version von net-snmp im Stable ist, die er braucht. Wars nicht, also hat DNF zu Recht rumgeheult, daß es nicht updaten kann, weil gibt es nicht ja nicht im Repo, was das Paket so braucht. Das kommt übrigens öfters vor, als man denkt. Sind halt alles nur Menschen 😀 Aber die Entschuldigung im Bugtracker ist ein Unikum 😀

Falls Euch das auch mal unterkommen sollte, ich hab die neue Version von net-snmp dann im UPDATES-TESTING Repo von Fedora vorgefunden und ein : dnf –enablerepo=updates-testing update net-snmp* hats dann gelöst. Da müßt Ihr dann natürlich die Euch fehlende Abhängigkeit benutzen, nicht net-snmp 😉