LCE in Apache OpenOffice <= 4.1.10

Auf sehr unrühmliche Weise wird gerade das personelle Defizit bei OpenOffice deutlich: Für eine LCE Schwachstelle gibt es keine Updates,

LCE in Apache OpenOffice <= 4.1.10

Falls Ihr OpenOffice einsetzt, solltet Ihr derzeit nicht einfach blind aus dem Netz stammende Dateien öffnen, daß könnte im Einzelfall weh tun. In OpenOffice <= 4.1.10 wurde eine Locale-Code-Execution Schwachstelle gefunden, sprich, wer ein verändertes Dokument aufmacht, könnte sich ein Schadprogramm eingefangen haben.

Ursache ist CVE-2021-33035, ein Bufferoverflow der geschickt ASLR (Speicherverwürfelung) und DEP Schutzmaßnahmen umgeht.

Das BürgerCERT des BSI hat gestern abend noch eine Warnung vor OpenOffice rausgegeben. Etwas sehr hoffnungsvoll heißt es darin:

„Das BürgerCERT empfiehlt die zeitnahe Installation der vom Hersteller bereitgestellten
Sicherheitsupdates, um die Schwachstellen zu schließen.“

Wenn es denn nur welche gäbe 🙁 Was jetzt ein bisschen verwunderlich ist, da alleine dies Jahr schon drei Updates von OpenOffice erschienen sind.

Gefunden hat diese Lücke Eugene Lim von der malaysischen Sicherheitsfirma GovTech Singapore Cyber Security Group. Am 18. September wurde die Lücke auf der HackerOne’s Hacktivity Online Conference vorgestellt, weil Ende August das Full-Disclosure-Date angelaufen ist, ohne das ein Fix verfügbar ist.
Das stimmt zwar nicht ganz, da in einer BETA Version der Fix bereits eingebaut wurde, nur wurde daraus bis jetzt keine stabile Version 🙁

Da jetzt hoffentlich der nötige Druck ausgeübt wird, wolltest Ihr die Downloadseite von OpenOffice im Auge behalten: https://sourceforge.net/projects/openofficeorg.mirror/files/

Sicherheitslücke: WordPress < 5.7.1 updaten

Liebe Kollegen und Leser des OSBN,

sofern Sie WordPress einsetzen, achten Sie heute auf Updates des WordPresscores auf 5.7.1+ . Nicht alle WordPressinstallationen updaten sich auch wirklich immer zuverlässig, daher im Zweifel einfach mal nachschauen.

Das BSI hat heute vor einer aktuellen Lücke in WordPress < 5.7.1. gewarnt. Über die geschlossene Lücke können Angreifer Daten der WordPressinstallation erbeuten. Da nicht näher erklärt wird, was das für Daten sind, darf man ruhig annehmen, daß auch Zugangsdaten erbeutet werden können.

Bei WordPress heißt es dazu:

Security Updates

Two security issues affect WordPress versions between 4.7 and 5.7. If you haven’t yet updated to 5.7, all WordPress versions since 4.7 have also been updated to fix the following security issues:

  • Thank you SonarSource for reporting an XXE vulnerability within the media library affecting PHP 8.

  • Thanks Mikael Korpela for reporting a data exposure vulnerability within the REST API.

Ich rate jedem zu einem Update, falls es nicht automatisch geklappt hat. Selbst wenn man am Ende nicht an Zugangsdaten hätte kommen können, lieber einmal mehr Updaten, als einmal zu wenig.

TLS: Timing Attacke RACCOON

Intel kennt das Problem: Laufend kommt einer an und kann an der Laufzeit von Berechnungen Daten ableiten, die er nicht sieht. Jetzt ist mal wieder TLS dran mit so einem Angriff auf den DH Schlüssel.

TLS: Timing Attacke RACCOON

Wie die Hacker News berichten, gibt es eine neue, aber sehr spezielle, Methode an einen Serverschlüssel zu kommen. Voraussetzung ist allerdings, daß der Server seine verwendeten Schlüssel erneut benutzt. Das sollte er wegen PFS sowieso nicht tun, aber nicht alle Dialekte von TLS 1.2 sind PFS fähig.

Um die Lücke ausnutzen zu können, muß der Angreifer zu dem sehr präzise Messungen zur Laufzeit machen können, daher muß er technisch sehr dicht am Server dran sein, um die Messungen akkurat vornehmen zu können. In den meisten Fällen wird der Versuch da bereits scheitern. Auch Scheitern wird der Angriff, wenn PFS zum Einsatz kommt, weil der Server den privaten DH Schlüssel dann nicht wieder verwendet.

F5, Mozilla, Microsoft und OpenSSL haben schon Updates parat, wobei M$ sich darauf beschränkt, die DHE einfach abzuschalten, statt das Problem zu lösen 😀 Auch ne Methode 😉 Wie man hier nachlesen kann: OPENSSL: https://www.openssl.org/news/secadv/20200909.txt hat OpenSSL das Problem in älteren OpenSSL Versionen bereits durch eine andere Defaulteinstellung behoben. Damit ist die Gefährlichkeit des Angriffs eher gering einzuschätzen.

Ich habe mir mal die Mühe gemacht und konnte selbst in einer 2 Jahre alten OpenSSL Version den nötigen Cipher nicht und damit ist der Webserver auch nicht anfällig. Ein Test durch SSLLabs hat das bestätigt:

Uses common DH primesNo, DHE suites not supported
DH public server param (Ys) reuseNo, DHE suites not supported
ECDH public server param reuseNo

Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.