Alle mal Firefox updaten!

Remote-Code-Execution in Firefox < 85.0.1 … Alle mal auf Update drücken!

Alle mal Firefox updaten!

Das Cert schreibt dazu:

Zusammenfassung:
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Mozilla Firefox und Mozilla Firefox 
ESR ausnutzen, um beliebigen Programmcode auszuführen.

Übersetzung: Jede Webseite kann Euch beim Besuch hacken!

Wer es sofort braucht:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc32/x86_64/firefox-85.0.1-1.fc32.x86_64.rpm

bzw. sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc33/x86_64/firefox-85.0.1-1.fc33.x86_64.rpm

Alle anderen müßten dann mal auf Ihre Distro warten.

Pinephone: Firefox Addons wieder gangbar machen

Moin, Moin,

wer auf dem Pinephone alle Fedora Updates eingespielt hat, wird jetzt aktuell keine Addons mehr haben, weil die systemweiten Crypto-Policies dies unterbinden.

Pinephone: Firefox Addons wieder gangbar machen

Wie Ihr diesem früheren Beitrag hier entnehmen könnt:

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Hat die Einstufung von SHA-1 als unsicherer Hash-Algorithmus zur Folge, das die Zertifikate zum Signieren von Firefox Addons nicht mehr akzeptiert werden, aber viele Addons von Mozilla noch nicht mit sha256 signiert wurden. Das nss 3.59.0-3 Paket, das diese Beschränkung temporär wieder aufhebt, hat es leider nicht auf Rawhide geschafft, weswegen Firefoxaddons jetzt nicht mehr funktionieren.

Allerdings kann man da selbst Abhilfe schaffen. Einmal Root werden und folgendes eingeben:

update-crypto-policies –set DEFAULT:FEDORA32
reboot

Nun läuft das Pinephone auf einem etwas entspannteren Modus. Das darf natürlich nicht ewig so bleiben. Wir warten lediglich bis es ein Firefoxupdate gibt, daß die NO-SHA1 Policy für Firefox ignoriert, bis die ganzen Addons neu signiert wurden. In dem Augenblick können wir die DEFAULT Policy wiederherstellen ( update-crypto-policies –set DEFAULT ).

Doch noch einen weiterer Pinephone Beitrag vor Silvester geschafft 🙂

 

Fedora: nss Update 3.59 ohne SHA-1 Sperre gepushed

Kleines Follow-Up zu diesem Artikel:

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Fedora: nss Update 3.59 ohne SHA-1 Sperre gepushed

Das Fedora Team hat die SHA-1 Sperre vorläufig aus dem Paket nss zurück genommen und ins Stable Repo gepusht, damit Firefox nicht gleich zusammenbricht. Damit könnt Ihr jetzt wieder bedenkenlos die Pakete updaten.

Früher oder später wird das aber scharf geschaltet werden. Mal sehen wann Mozilla seine Entwickler mit sha-256 beglücken wird.

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Kleine Warnung, falls Ihr auf Eurem System nss zur kryptografischen Absicherung einsetzt, und das werden einige von Euch sein: Eure Firefox Addons werden nicht mehr funktionieren.

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Wer auf seinem System nss drauf hat, sollte sich auf einige gefasst machen. Wenigstens für Fedora wurde die Policy von nss mit der Version 3.59 so verschärft, daß keine Checksummen mehr mit SHA-1 erlaubt sind. Das wirkt sich dramatisch auf Plugins von Firefox aus, da dort noch viele Addons unter Verwendung von SHA-1 signiert sind.

Fedora hat die Verteilung von nss 3.59 daher vorläufig eingestellt.

Falls bei Euch bereits nss 3.59 in der verschärften Version installiert ist und Eurer Firefox über die Addons meckert, dann gibt es leider nur einen Weg: alle Addons löschen und frisch installieren.

Ein Rücksichern alter Firefoxprofile und downgraden von nss ist laut Berichten auf der Fedora Mailingliste leider nicht unmittelbar von Erfolg gekrönt. Möglicherweise wird Löschen und neuinstallieren der einzige Weg bleiben.

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Nein, heute geht es nicht um Dichtung, eher um Undichtigkeiten in Betriebssystemen 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Google’s Projekt Zero hat im Oktober eine Serie von kritischen Bugs offengelegt, mit deren Hilfe iOS, Android, Windows, Macs und Linuxsysteme übernommen werden konnten. Die Lücken sind so groß, daß Apple sogar noch Iphone 5s aktualisiert und die sind seit Jahren im End-of-Live.

Ein Blick auf eine dieser Lücken zeigte, daß diese auch für Linux vorhanden war, aber unter dem Radar bliebt: FreeType < 2.10.4

„Bug #1890210 – CVE-2020-15999 freetype: heap-based buffer overflow via malformed ttf files“

Red Hat hat dazu im Bugreport geschrieben:

„A flaw was found in freetype in the way it processes PNG images embedded into fonts. A crafted TTF file can lead to heap-based buffer overflow due to integer truncation in Load_SBit_Png function.“

Wer in den letzten Tagen die Updates verfolgt hat, weiß, daß es für Chrome, FireFox, Thunderbird eine schere Sicherheitslücke beim Webseitenaufruf gab. Über den Bug im FreeType, einer Font-Rendering-Engine, die auch und gerade in Webbrowsern genutzt wird, konnte mit Hilfe eines manipulierten Fontfiles, und da zählen auch WebFonts zu, das komplette System übernommen werden.

Diese Lücke betraf uns alle, und mit alle meine ich wirklich ALLE auf dem Planeten.

Wie kann eine so simple Sache wie einen Fontrendern, zu einer Systemübernahme führen? Das liegt daran, daß es sich hierbei wohl um den ersten Schritt in einer ganzen Exploitchain handelt. Hat man erstmal den Fuß im Chrome oder Firefox, muß man nur noch dort ausbrechen können und das war bei Chrome über einen Sandbox-Escape möglich. Danach findet sich im Kernel schon eine Schwachstelle, gerade bei Handies.

Von der Tragweite der Lücke mal abgesehen, rankt sich um die Google Veröffentlichung noch einiges andere. In der Szene munkelt man von „Spionagekram“, wozu auch paßt, daß keiner der Beteiligten dazu irgendwas sagen möchte. Nachdem der Exploit verbrannt ist, dürften die früheren Nutzer ziemlich sauer auf Google sein. Das Google uns aber nicht sagen kann, woher die Exploits stammen und wie Sie darauf aufmerksam wurden, spricht dafür, daß es ein „us-heimischer“ Dienst war, sonst wären die Antworten vermutlich anders. Aber, genaueres weiß man nicht, da keiner reden will.

Also feiert, daß ein Angriff weniger auf Euch möglich ist und wer von Euch Software schreibt, denkt bitte daran, wirklich sauber zu arbeiten, weil auch die unbedeutendste Lib einen immensen Schaden anrichten kann!

Firefox & Thunderbird: neue Remote-Code-Execution Schwachstelle

Warnung vom BSI:

10.11.2020 – TW-T20-0194

Mozilla Firefox/Thunderbird: Schwachstelle ermöglicht Ausführen von beliebigem Programmcode mit Benutzerrechten

Firefox & Thunderbird: neue Remote-Code-Execution

Betroffen sind :

  • Mozilla Firefox < 82.0.3

  • Mozilla Firefox ESR < 78.4.1

  • Mozilla Thunderbird < 78.4.2

Bekannt wurde die Schwachstelle bei einem Hackingwettbewerb in China:

„CVE-2020-26950: Write side effects in MCallGetProperty opcode not accounted for

In certain circumstances, the MCallGetProperty opcode can be emitted with unmet assumptions resulting in an exploitable use-after-free condition.“

Also, Updaten, Updaten.

Mozilla: welche 250 Mitarbeiter entlassen wurden

Moin,

wenn man dem Twittergerücht ( mehr ist es imho nicht ) glaubt, wurden Teile des Security Teams von Mozilla vor die Tür gesetzt. Andere Twitteruser wiederum melden sich als „unser Gecko Team“ hats geschafft und auch andere Bestandteile hätten sich da zu Wort gemeldet.

Mozilla: welche 250 Mitarbeiter entlassen wurden

Kann irgendwer von denen beweisen, daß er dort arbeitet oder gearbeitet hat? Ich weiß es nicht.

Wenn man das so liest und es für bare Münze nimmt, wundert es nicht wirklich, was da so in den letzten Versionen von Firefox rausgekommen ist. Das ist kein einheitliches Produkt, das ist eine Ansammlung von Bestandteilen.

Und um diesem Beitrag die nötige inhaltliche Kontroverse zu geben:

Scheiße, war der FireFox gestern effektiv 😀

Das muß ich kurz erklären. Gestern Abend war Meet Jitsi VideoConf der BSLUG. Ich sahs unten mit dem Tablet und hatte mit Chromium daran teilgenommen. Nach rund 38 Minuten waren nur noch 54 % Akkuladung vorhanden, die CPU Frequenz der 4 Kerne lag dauerhaft bei 2.2 GHz, was ohne Turbo die größtmögliche Einstellung ist und mit dem größten Stromverbrauch gleichzusetzen ist. Keine 20 Minuten später waren es nur noch 15 %.

Im Top nachgesehen lief Chromium als einziger Prozess mit voller Last. Daraufhin habe ich den beendet und die VC mit Firefox weiter gemacht und siehe da, die Last ging runter. FF hat ~40% weniger Energie für die gleiche Leistung verbraucht als Chromium ( Freeworld Build von RPMFusion ).

Jetzt wärs schön rauszubekommen wieso das so war, weil der Chromium-Freeworld damit wirbt, HW Unterschützung zu haben. Das wird i.d.R. mit mehr Leistung pro Watt im der Verbindung gebracht, ergo weniger CPU Leistung und Energieverbrauch, als ohne HW Unterstützung.

Um den Schluß mit oben zu bekommen, ich hoffe nicht, daß sie die Energieoptimierungsexperten rausgeworfen haben, weil die haben nachweislich was geleistet 😉

RCE: Firefox 79.0 Update einspielen

Mojn, Moin,

bitte spielt mal Eure FireFox Updates auf 79.0 ein, da <79 leider eine RCE Schwachstelle hat ( Remote Code Execution ). Also das Schlimmste vom Schlimmen.

RCE: Firefox 79.0 Update einspielen

Das BSI-Bürger-Cert schreibt dazu:

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla Firefox und Mozilla
Thunderbird ausnutzen, um Schadcode auszuführen, einen Absturz zu verursachen, vertrauliche
Informationen auszuspähen oder Sicherheitsvorkehrungen zu umgehen. Zur Ausnutzung genügt es, eine bösartige E-Mail, Webseite oder einen Link dorthin zu öffnen.

so spielt Ihr das Update für Fedora ein:

sudo dnf -y update –enablerepo=updates-testing firefox

Einfach noch das Rootpasswort bestätigen, fertig.

Cato der Ältere meinte dazu übrigens: Ave RPM!

Wer wissen will, was das jetzt sollte, die BS LUG trifft sich einmal die Woche zu einem VideoChat, da löse ich das auf 😉

Netflix, Firefox und die 1080p – Teil 2

Moin,

wer heute früh schon Netflix mit seinem 1080p gepimpten Firefox sehen wollte, wird leider feststellen, daß dies nicht mehr geht. Schuld ist eine Änderung im Netflix Javascriptcode, der mit den Anpassungen für 1080p in eine Endlosschleife übergeht. Die JS-Engine in Firefox semmelt dann erwartungsgemäß ab und nichts passiert.

Abhilfe schafft das deaktivieren den 1080p Addons 🙁

Leider gibt es keine Lösung für das Problem.

Ich habe den Entwickler schon kontaktiert, aber ob der noch was macht .. ich glaubs nicht. Ich denke, es wird Zeit, daß wir uns als Netflixbenutzer vereinen und Netflix die Pistole auf die Brust setzen und endlich 1080p+ für FireFox und Linux fordern! Das es problemslos funktionieren würde, hat man ja gesehen. Vielleicht bekomme ich dann auch endlich 3k fürs Surface.

Chrome ist ja leider auch keine Hilfe, es bringt nämlich auch keine 1080p zustande.

 

Firefox 76 Security Update einspielen

Es ist mal wieder soweit, ein „Firefox Securityupdate“ muß eingespielt werden: Firefox 76

Hinweis: Alle Anweisungen beziehen sich auf Fedora.

Firefox 76 Security Update einspielen

Diesmal ist es eine Lücke in der Speicherverwaltung:

* Mozilla: Memory safety bugs fixed in Firefox 76 and Firefox ESR 68.8
(CVE-2020-12395)

Leider ist es diesmal nicht ganz so einfach mit dem Update wie sonst, da auch das NSS aktualisiert werden muß, was einiges an Paketen bedeutet, bei mir waren es:

firefox-76.0-2.fc30.x86_64.rpm
nss-3.51.1-1.fc30.i686.rpm
nss-3.51.1-1.fc30.x86_64.rpm
nss-softokn-3.51.1-1.fc30.i686.rpm
nss-softokn-3.51.1-1.fc30.x86_64.rpm
nss-softokn-freebl-3.51.1-1.fc30.i686.rpm
nss-softokn-freebl-3.51.1-1.fc30.x86_64.rpm
nss-sysinit-3.51.1-1.fc30.x86_64.rpm
nss-tools-3.51.1-1.fc30.x86_64.rpm
nss-util-3.51.1-1.fc30.i686.rpm
nss-util-3.51.1-1.fc30.x86_64.rpm

Die 686 Pakete ( 32 Bit ) sind nötig, wenn Ihr z.b. Wine32 laufen habt, ansonten werdet Ihr die nicht mehr brauchen. Um rauszubekommen, welche Pakete Ihr habt, gebt in die Konsole ein:

rpm -qa | grep ^nss | sort

und schon habt Ihr eine Liste mit Paketnamen, die Ihr nur noch abarbeiten müßt 🙂

Leider gibt es die Pakete noch nicht im Testing-Repo, sonst könntet Ihr die per DNF Update automatisch einspielen lassen, so müßt Ihr das über diesen Befehl machen:

sudo dnf update ./nss*rpm ./firefox*rpm

Daher hier für Euch die Downloadlinks zu den Paketbuilds im Koji:

Downloadlinks:

FF 76 FC30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1503483

FF 76 FC31 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1503481

FF 76 FC32: https://koji.fedoraproject.org/koji/buildinfo?buildID=1503472

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

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

NSS FC32: https://koji.fedoraproject.org/koji/buildinfo?buildID=1502814

Wer möchte kann ja im Bodhi einen positiven Test vermerken, damit die Pakete schneller ins Stable Repo kommen: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f389eab5d1