RCE Schwachstelle in Thunderbird < 91.1/78.14 und Firefox <= 91.1

Wären wir auf einem Raumschiff namens Mozilla, gäbe es jetzt roten Alarm.

RCE Schwachstelle in Thunderbird < 91.1/78.14 und Firefox <= 91.1

Ungefähr 8 Lücken wurden in Firefox und Thunderbird behoben, davon viele mit Schweregrade „hoch“ z.B.

CVE-2021-38495: Memory safety bugs fixed in Thunderbird 91.1

Reporter: Mozilla developers and community
Impact: high
Description: Mozilla developers Tyson Smith and Gabriele Svelto reported memory safety bugs present in Thunderbird 78.13.0 .

und

CVE-2021-38493: Memory safety bugs fixed in Thunderbird 78.14 and Thunderbird 91.1

Reporter: Mozilla developers and community
Impact: high
Description: Mozilla developers Tyson Smith and Gabriele Svelto reported memory safety bugs present in Thunderbird 78.13. 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.

In Deutsch zusammengefasst:

  • Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla Firefox, Mozilla Firefox ESR und Mozilla Thunderbird ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsmaßnahmen zu umgehen und beliebigen Code zur Ausführung zu bringen.

  •    Mitteilung vom CERT-BUND 8.9.2021

das heißt für Euch: „Updaten! Updaten! Updaten!“ und wo wir bei Raumschiffen waren: „Dies ist keine Übung!

Für Fedora gibt es die noch nicht im Stable befindlichen Versionen hier:

Firefox: https://koji.fedoraproject.org/koji/packageinfo?packageID=37

Thunderbird: https://koji.fedoraproject.org/koji/packageinfo?packageID=39

Quellen:

https://www.mozilla.org/en-US/security/advisories/mfsa2021-38/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-39/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-40/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-41/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-42/

 

WIFI: Die FRAGATTACK Apokalypse

Ja, der Titel wäre Click-Bait, wenn es nicht wirklich so schlimm wäre, wie es ist: praktisch jeder Wifi-Stack der bis heute produziert wurde, ist für die FragAttack anfällig.

WIFI: Die FRAGATTACK Apokalypse

Der Name FragAttack ist hier nicht wie sonst üblich ein Akronym für irgendwas langes, sondern bezieht sich ausnahmsweise mal auf die Grundlage des Angriffs: Fehler bei Zusammenfügen von Paketfragmenten.

„Fragmentierung“ meint, daß einzelne große Datenpakete, die nicht durch das Netz/Kanal passen, in kleinere Pakete aufgeteilt und beim Empfänger wieder zusammen gesetzt werden. Das passiert bei IP-Datenpaketen im normalen Netz auch laufend, ist an sich nicht besonderes.

Die Schwachstellen sind in praktisch jeder Implementierung von WEP bis WPA3 enthalten, wobei nicht jede davon überall sein muß.

12 Fehler sollt Ihr sein

Insgesamt wurden 12 Schwachstellen in verschiedenen Implementierungen bzw. dem Wifi-Protokoll an sich gefunden;

CVE-2020-24588: Akzeptieren von nicht-SPP A-MSDU-Frames
CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden
CVE-2020-24586: Fragmente werden nicht aus dem Speicher gelöscht, wenn eine (erneute) Verbindung zu einem Netzwerk hergestellt wird
CVE-2020-26145: Akzeptieren von Klartext-Broadcast-Fragmenten als vollständige Frames (in einem verschlüsselten Netzwerk)
CVE-2020-26144: Akzeptieren von Klartext-A-MSDU-Frames, die mit einem RFC1042-Header mit EtherType EAPOL beginnen (in einem verschlüsselten Netzwerk)
CVE-2020-26140: Akzeptieren von Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26143: Akzeptieren von fragmentierten Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26139: Weiterleitung von EAPOL-Frames, obwohl der Absender noch nicht authentifiziert ist
CVE-2020-26146: Wiederzusammensetzen von verschlüsselten Fragmenten mit nicht-fortlaufenden Paketnummern
CVE-2020-26147: Wiederzusammensetzen von gemischten verschlüsselten/Klartext-Fragmenten
CVE-2020-26142: Verarbeitung von fragmentierten Frames als vollständige Frames
CVE-2020-26141: Keine Verifizierung des TKIP-MIC von fragmentierten Frames

„CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden“ Ist ein Paradebeispiel dafür, daß ganz schlicht jemand einfach mal eine kleine „if ( oldkey == actualkey)“ Abfrage im Code vergessen hat. Wenn man den Testfall nicht dabei hat, weil man nur ein Netz mit nur einem Schlüssel hat, dann kann das schon einmal passieren.

Die Hacker News schreiben dazu, daß Mathy Vanhoef, ein Sicherheitsforscher der New York University Abu Dhabi, die Probleme auf weit verbreitete Programmierfehler zurückführt.

„Ein böser Akteur kann diese Schwachstellen ausnutzen, um beliebige Netzwerkpakete zu injizieren, Benutzerdaten abzufangen und zu exfiltrieren, Denial-of-Service-Angriffe zu starten und möglicherweise sogar Pakete in WPA- oder WPA2-Netzwerken zu entschlüsseln.“

Es sind sogar Angriffe denkbar bei denen  in das Netz oder am Netz beteiligte Rechner eingebrochen werden kann. Dabei wären dann Geräte interessant die keine Updates mehr bekommen haben, wie z.B. so ziemlich jedes Androidgerät älter als 2 Jahre, Windows XP/7 oder Macs.

Die Wifi-Allianz hat in einer mehr als neunmonatigen konspirativen Aktion sukzessive die Gerätehersteller kontaktiert und Updates verteilen lassen. Wohl dem, der die noch bekommt.

Für Windows wurden die Updates schon eingespielt, bei Linux sind auch bereits Patche in den Kernel eingeflossen, müssen aber noch etwas reifen. Da die Lücken nicht ganz so leicht auszunutzen sind, wie das vielleicht klingen mag, ist das „erst einmal“ kein Problem… bis es dann zum Problem wird 😉

Exploits sind nicht auszuschließen, also kümmert Euch am besten auch um Eure ganzen IoT Geräte, DSL-Router, Access-Points und Uralt-Androids.. wenn Ihr noch könnt.

Quelle: https://thehackernews.com/2021/05/nearly-all-wifi-devices-are-vulnerable.html

Docker – Genauso schlimm wie befürchtet

Jetzt ist es also endlich soweit, jemand hat man genauer hingeschaut und Dockerimages auf Schwachstellen untersucht. Das Ergebnis: Es ist genauso schlimm wie das von den Skeptikern erwartet wurde!

Kaum Sicherheitsupdates

Zunächst mal zur Quelle der Daten:

https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

Da ist eine schöne Grafik über die Anzahl der gefundenen Schwachstellen per speziellem Dockercontainer. Das NODE dabei übelst abgeschnitten hat, wundert mich seit meinen Kontakten damit nicht im geringsten. Ohne darauf groß einzugehen, eine Repoumgebung, die zig Versionen der gleichen Erweiterung bereithält, anstatt nur die mit den wenigsten Löchern drin, kann man nicht ernsthaft als Basis für irgendwas benutzen.

Jetzt zur Analyse oben

Die Skeptiker, Altbackenden, Konservativen, die Im-Weg-Steher hatten es von Anfang an gesagt:

Wenn man Apps in Container packt und eine für diese App gangbare Umgebung dazu legt, dann wird man am Ende jede Menge Container mit Sicherheitslücken haben. Und genau das ist dabei rausgekommen. Weil sie keiner updated, obwohl das möglich ist, dümmpelt eine Sicherheitslücke neben der anderen rum.

Der sicherere Ansatz ist und bleibt, daß jemand das OS vorgibt und sich die Apps an die Umgebung anpassen müssen. Damit sind die gezwungen Updates zu machen und das dient dann der allgemeinen Sicherheit.

QED. Und es wurde gerade demonstriert!

Abzulehnen ist also alles, was eine App installiert, die mit eigener Umgebung kommt, sowas wie FlatPak, Docker und Snap.