Release-Warnung zur kritischen Zero-Day-Lücke in Log4j (CVE-2021-44228)

​​Diese Meldung wird laufend aktualisiert, sobald neue Informationen aus unseren Analysen hervorgehen. Bitte informieren Sie sich regelmäßig.

Letzte Aktualisierung: 12.01.2022, 14:50 Uhr MEZ

Zusammenfassung:

Eine schwerwiegende Schwachstelle (CVE-2021-44228) mit Auswirkungen auf verschiedene Versionen von  Apache Log4j 2 wurde über das GitHub des Projekts am 9.12.2021 öffentlich gemacht. Diese Schwachstelle hat Auswirkungen auf die Versionen 2.0 bis 2.14.1 von Apache Log4j 2.

Diese Meldung beinhaltet alle zurzeit bekannten potentiellen Auswirkungen auf all unsere Produkte (enaio®, yuuvis® RAD und yuuvis® Momentum) und verwandte Meldungen zur Behebung dieses Problems. Unsere Teams arbeiten weiter aktiv an einer Analyse und den Maßnahmen, die unsere Benutzer durchführen sollten.

Eine weitere Schwachstelle (CVE-2021-45046) wurde am 10.12.2021 bekanntgegeben, nachdem sich herausgestellt hat, dass der Fix für CVE-2021-44228 in Apache Log4j 2.15.0 in bestimmten vom Standard abweichenden Konfigurationen nicht vollständig war. 

Am 18.12.2021 wurde bekanntgegeben, dass auch der Fix mit Version 2.16 nicht ausreichend war (CVE-2021-45105), um die Schwachstelle zu beheben. Daher hat Apache Log4j Version 2.17 veröffentlicht. Bitte beachten Sie weiterhin den Sicherheitshinweis auf dieser Seite. Die Anleitungen zum manuellen Update von Log4j wurden entsprechend angepasst.

Für Anwender der Signaturdienste von Governikus wurden am 21.12.2021 Updates unseres enaio® client veröffentlicht. Bitte entnehmen Sie die aktuellen Versionsnummern dem folgenden Sicherheitshinweis.

Am 28.12.2021 hat Apache Log4j Version 2.17.1 veröffentlicht und behebt damit die Schwachstelle CVE-2021-44832. Unsere Untersuchungen haben ergeben, dass unsere Produkte nicht von dieser Schwachstelle betroffen sind, da diese auf die Verwendung von JDBCAppender zurückgeht, der in keiner unserer Komponenten und Konfigurationen im Einsatz ist. Als Vorsichtsmaßnahme haben wir dennoch Hotfixes für abhängige Komponenten veröffentlicht und empfehlen ein Update. Bitte entnehmen Sie die aktuellen Versionsnummern dem Sicherheitshinweis auf dieser Seite. Die Anleitungen zum manuellen Update von Log4j und wurden entsprechend angepasst.

Sicherheitshinweis – log4j (CVE-2021-44228)

Elasticsearch (alle Versionen von enaio®, yuuvis® RAD und yuuvis® Momentum)

Aussage von Elasticsearch (https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476):

Unterstützte Versionen von Elasticsearch (6.8.9+, 7.8+), die mit aktuellen Versionen von JDK (JDK9+) verwendet werden, sind nicht anfällig für die Remote-Ausführung von Code oder Informationslecks. Dies liegt an der Verwendung von Java Security Manager durch Elasticsearch. Die meisten anderen Versionen (5.6.11+, 6.4.0+ und 7.0.0+) können durch eine einfache JVM-Property-Änderung geschützt werden. Die Informationsleck-Schwachstelle erlaubt keinen Zugriff auf Daten innerhalb des Elasticsearch-Clusters. Wir haben Elasticsearch 7.16.1 und 6.8.21 veröffentlicht. Diese Versionen beinhalten die JVM-Property standardmäßig und entfernen aus reiner Vorsicht bestimmte Komponenten von Log4j. Dies gilt sowohl für CVE-2021-44228 als auch CVE-2021-45046.

Wir verwenden das Linguistik Plug-in von IntraFind für Elasticsearch in all unseren Produkten. IntraFind hat folgende Warnung veröffentlicht (https://intrafind.com/en/apache-log4j-updates):

Das IntraFind Linguistik Plug-in läuft innerhalb der Elasticsearch-Infrastruktur und greift auf das Protokollierungs-Framework zurück. Seit der Version 5.0 verwendet Elasticsearch Log4j2. Benutzerdefinierte Konfigurationen des Java Security Managers, die für das Plug-in erforderlich sind, wirken sich negativ auf die Schwachstelle aus.   Zum Schutz Ihrer Elasticsearch-Installation, ersetzen Sie entweder die log4j jars mit der aktuellen Versionen oder fügen Sie eine entsprechende Option hinzu mit der die log4j-Funktion deaktiviert werden kann.

 

Obwohl es nicht eindeutig geklärt ist, ob es eine bestätigte und tatsächliche Angriffsfläche auf Basis dieser besonderen Konfiguration gibt, vertrauen wir auf die Einschätzung von IntraFind und empfehlen die folgenden Schritte zur vollständigen Abwehr der Schwachstelle in Elasticsearch-Installationen. Da wir lediglich IntraFind Plug-ins einsetzen und nicht das komplette IntraFind-Produkt, können die Tools, die auf der Webseite von IntraFind verfügbar sind, nicht direkt verwendet werden.

Schritte, mit denen Sie dieses Update manuell durchführen:

  • Die präferierte Lösung zum Schutz von Elasticsearch-Installationen ist die Log4j2-Bibliotheken durch die neueste Version zu ersetzen

    1. Laden Sie die Datei https://archive.apache.org/dist/logging/log4j/2.17.1/apache-log4j-2.17.1-bin.zip herunter.

    2. Entpacken Sie die beiden Dateien log4j-api-2.17.1.jar und log4j-core-2.17.1.jar aus der Zip-Datei (Unterverzeichnis apache-log4j-2.17.1-bin).

    3. Stoppen Sie Ihre Elasticsearch-Anwendung.

    4. Löschen Sie im Verzeichnis <elasticsearch-install-dir>\lib die Dateien log4j-api-2.11.1.jar und log4j-core-2.11.1.jar (oder verschieben Sie die Dateien in ein Verzeichnis außerhalb von Elasticsearch).

    5. Kopieren Sie die beiden neuen Dateien in das Verzeichnis \lib.

    6. Im Verzeichnis <elasticsearch-install-dir>\bin finden Sie das Kommandozeilentool elasticsearch-sql-cli-xx.yy.zz.jar (abhängig von der genauen Elasticsearch-Version). Es enthält eine eingebettete Version von log4j-2.14. Es ist Teil der Standardinstallation von Elasticsearch. Das Tool wird nicht aktiv verwendet und wir für den einwandfreien Betrieb eines Elasticsearch-Clusters nicht benötigt.  Das bedeutet, dass es gelöscht werden kann und sollte.

    7. Starten Sie Elasticsearch und denken Sie daran, diesen Prozess für alle Knoten von Elasticsearch zu wiederholen.

  • Alternativlösung, laut Empfehlung von IntraFind: Deaktivierung der Funktion in der Log4j-Konfiguration. Wie wir schon in unserer letzten Release-Warnung erwähnt haben, kann dies erreicht werden, indem das folgende Flag gesetzt wird (wird als Vorsichtsmaßnahme ebenfalls von Elasticsearch empfohlen):
    -Dlog4j2.formatMsgNoLookups=true
    (z. B. für Elasticsearch 7.12 https://www.elastic.co/guide/en/elasticsearch/reference/7.12/advanced-configuration.html#set-jvm-option).

 

Die oben beschriebenen Schritte sind nur zum Schutz von bestehenden Elasticsearch-Installationen erforderlich. Für neue Installationen in allen Produktlinien haben wir neue Installer veröffentlicht, in denen diese Änderungen bereits implementiert sind.

enaio® (alle Versionen)

 

yuuvis® RAD (alle Versionen)

Bis auf den bereits beschriebenen Sachverhalt angehend Elasticsearch (siehe oben), sind unsere restlichen Komponenten von dieser CVE-Schwachstelle nicht betroffen.

Hinweis vom 12.01.2022:

Unsere neuesten Untersuchungen haben ergeben, dass yuuvis® metrics-manager unter Umständen angreifbar ist, wenn als Protokollierungslevel debug verwendet wird. Daher empfehlen wir nun zwingend ein Update von yuuvis® metrics-manager für die Versionen 7.16 LTS und 6.16 LTS von yuuvis® RAD. Bitte entnehmen Sie die aktuelle Versionsnummer aus den Versionsinformationen weiter unten, die wir am 12.01.2022 aktualisiert haben.

Alle unsere Kerndienste, die im Service Manager laufen, basieren auf Spring Boot. Dort verwenden wir SLF4J, LOG4J-TO-SLF4J und Logback Librarys, die nicht von dieser CVE-Schwachstelle betroffen sind. Das betroffene LOG4J-CORE ist nicht im Einsatz. Alle Meldungen und Informationen der Spring-Boot-Entwickler sind hier verfügbar: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

Allerdings ist log4j-core indirekt in manchen erstellten Artefakten der älteren Versionen von yuuvis® RAD als vorübergehende Abhängigkeit des Elasticsearch-Clients SDK enthalten, wird aber weder initialisiert noch von unseren Protokollierungsmechanismen verwendet. Nichtsdestotrotz, kann dieses .jar durch Scans erkannt werden und einen Alarm auslösen.

Obwohl es sich um einen False-Positive-Alarm handelt, werden wir als Vorsichtsmaßnahme die anfällige Log4j-Komponente durch einen Hotfix entfernen.

yuuvis® Momentum (alle Versionen)

Bis auf den bereits beschriebenen Sachverhalt angehend Elasticsearch (siehe oben), sind unsere restlichen Komponenten von dieser CVE-Schwachstelle nicht betroffen, da wir keine Version von Log4j in diesem Produkt verwenden.

Das aktualisierte Docker-Image für Elasticsearch ist in unserem Repository mit dem Tag docker.yuuvis.org/yuuvis/elasticsearch:2022-01-11 verfügbar, wie bereits weiter oben beschrieben.

Installieren Sie dieses Update auf Ihren Clustern, wenn Sie yuuvis® Momentum selbst hosten. Unsere Lösung yuuvis® Ultimate enthält diese Änderungen bereits.

 

Mit freundlichen Grüßen

Ihr OPTIMAL-SYSTEMS-Team

 

Für weitere Informationen und eine Historie finden Sie ältere Release-Warnungen über die Navigation auf der linken Seite.