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: 20.03.2023, 14:30 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
Laden Sie die Datei https://archive.apache.org/dist/logging/log4j/2.17.1/apache-log4j-2.17.1-bin.zip herunter.
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).
Stoppen Sie Ihre Elasticsearch-Anwendung.
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).
Kopieren Sie die beiden neuen Dateien in das Verzeichnis \lib.
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.
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.
Versionsinformationenenaio® 10.0 Final:
Elasticsearch 7.9.3 (Build 202112201205)
indexservice-app.jar 10.0.11
searchservice-app.jar 10.0.11
enaio® 9.10 Final
elasticsearch_setup.exe 7.2.1 (Build 202112201146)
indexservice-app.jar 9.10.0.24
searchservice-app.jar 9.10.0.24
enaio® 9.00 SP1
elasticsearch_setup.exe Elasticsearch 6.2.4 (Build 202112201137)
indexservice-app.jar 9.00.0.15
searchservice-app.jar 9.00.0.15
enaio® 8.50 und ältere Versionen
keine Änderungen erforderlich
yuuvis® RAD 7.16
Elasticsearch 7.9.3 (Build 202201061520)
yuuvis® RAD 6.16
Elasticsearch 7.2.1 (Build 202201071120)
yuuvis® Momentum
Das aktualisierte Docker-Image für Elasticsearch ist in unserem Repository mit dem Tag docker.yuuvis.org/yuuvis/elasticsearch:2022-01-11 verfügbar.
enaio® (alle Versionen)
KerndiensteAlle 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 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.
enaio® 10.0 Final
Elasticsearch 7.9.3 (Build 202112201205)
indexservice-app.jar 10.0.11
searchservice-app.jar 10.0.11
enaio® 9.10 Final
elasticsearch_setup.exe 7.2.1 (Build 202112201146)
indexservice-app.jar 9.10.0.24
searchservice-app.jar 9.10.0.24
enaio® 9.00 SP1
elasticsearch_setup.exe Elasticsearch 6.2.4 (Build 202112201137)
indexservice-app.jar 9.00.0.15
searchservice-app.jar 9.00.0.15
enaio® 8.50 und ältere Versionen
keine Änderungen erforderlich
Log4j 1.2.xIn folgenden Komponenten nutzen wir eine ältere log4j-Version (1.2.x), die durch diese CVE nicht betroffen ist, wie auch hier beschrieben ist: https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Betroffene Versionen sind 2.0.1 <= log4j < 2.15.0.
Diese Komponenten können deswegen, wenn auch nur selten, als False-Positive durch manche Anwendungen erkannt werden: OS_AppConnector, enaio® webclient (Windows service), OSR3 (alter repository-manager), OS_WebServices, OS_DocumentViewer.
Obwohl hier keine direkte Gefahr in Bezug auf CVE-2021-44228 besteht, werden wir für OS_AppConnector und OS_DocumentViewer als Vorsichtsmaßnahme zu Version 11.0 ein Update durchführen. OSR3 gibt es seit Version 10.0 nicht mehr bzw. wird diese Komponente durch den neuen enaio® repository-manager ersetzt. Die Komponente OS_WebServices (SOAP-Schnittstelle) ist bereits als veraltet gekennzeichnet und wird mit enaio® Version 10.10 nicht mehr als Bestandteil des Produkts ausgeliefert. Ebenfalls mit der Version 10.10 wird das alte Backend des enaio® webclient (oswebclient) abgelöst und durch einen neuen OSWEB-Microservice ersetzt. Bereits aktualisiert sind die Komponenten enaio® exchange und enaio® filetrigger.
Hinweis vom 20.03.2023:
Wie schon angekündigt werden die Komponenten OS_AppConnector und OS_DocumentViewer upgedatet. Diese Updates sehen wie folgt aus:
OS_AppConnector erhält für die Versionen 10.10 und 11.0 einen Hotfix.
OS_DocumentViewer wird mit Version 11.0 komplett aktualisiert.
Darüber hinaus wird es für enaio® client Version 10.10 und Version 11.0 ebenfalls einen Hotfix geben, in dem die log4net 1.2.10 mit log4net 2.0.14 ersetzt wird.
Aktuell informieren wir Sie über die Sicherheitslücke CVE-2022-23307 mit der Bewertung 8.8 HIGH. Die Sicherheitslücke bezieht sich auf Log4j 1.2.x in Verbindung mit Apache Chainsaw. Die Verbindung zwischen Log4j 1.2.x und Apache Chainsaw ist als Standard nicht aktiv, sondern muss ausdrücklich konfiguriert werden.
In unseren Komponenten ist das nicht der Fall. Deshalb sind unsere Installationen nicht von dieser Sicherheitslücke betroffen.
Governikus Signerenaio® client verwendet Governikus Signer, eine Drittanbieteranwendung, die Teil unserer Client-Installation ist. Governikus hat die folgende Meldung veröffentlicht:
Governikus Suite
Mit den von uns am Freitag kommunizierten administrativen Einstellungen der Java System Properties kann die potenzielle Schwachstelle nicht ausgenutzt werden. Ein entsprechendes Update unserer Sicherheitsinformation werden wir kurzfristig in unserem Portal zur Verfügung stellen.
Die Suite verwendet in der Standard-Einstellung für das Logging JBoss EAP. Einschätzung des Herstellers Red Hat ist JBoss EAP von der Sicherheitslücke nicht betroffen (https://access.redhat.com/security/vulnerabilities/RHSB-2021-009). Da einzelne Services der Suite dennoch log4j 2 implementiert haben, werden wir zeitnah ein Update der Governikus Suite mit der log4j 2-Version 2.15 zur Verfügung stellen.
Governikus Service Components
Governikus Service Components sind von der Schwachstelle nicht betroffen.
Obwohl keine direkte Gefahr besteht, werden wir als Vorsichtsmaßnahme aktualisierte Client-Installer für enaio® 9.10 und enaio® 10.0 veröffentlichen, sobald eine neue Version des Governikus Signer verfügbar ist (zusammen mit dem gesicherten log4j 2.16, und nicht das von der Schwachstelle betroffene 2.15).
Am 21.12.2021 wurden für enaio® 9.10 und enaio® 10.0 neue Versionen veröffentlicht, die Governikus Boreum 10.2.0 und Governikus Signer 2.9.7.0 unterstützen:
enaio® 10.0 Final
enaio_client_ansi.msi 10.0.25
enaio_client_unicode.msi 10.0.20
enaio® 9.10 Final
enaio_client.msi 9.10.0043
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.
Versionsinformationenyuuvis® RAD 7.16 LTS:
metrics-manager 7.6.22010 (verwenden Sie die Datei jdk_x64.zip, mit dem Update auf Java 1.8u312)
yuuvis® RAD 6.16 LTS:
inbox-service 6.15.1 (Teil von service-manager 6.16.32)
metrics-manager 7.6.22010 (verwenden Sie die Datei jdk_x64.zip, mit dem Update auf Java 1.8u312)
yuuvis® RAD 5.20 LTS und ältere Versionen:
Wir werden keine Hotfixes als Vorsichtsmaßnahme veröffentlichen, da diese Versionen schon vor langer Zeit das Ende ihres Produktlebenszyklus erreicht haben. Dennoch stellen wir Ihnen eine Schritt-für-Schritt-Anleitung zur Verfügung, anhand derer Sie dieses Update manuell durchführen können. Dies betrifft die folgenden Services: inbox-service, index-service, search-service und status-service.
Laden Sie die Datei https://archive.apache.org/dist/logging/log4j/2.17.1/apache-log4j-2.17.1-bin.zip herunter und entnehmen Sie die Dateien log4j-api.2.17.1.jar und log4j-core-2.17.1.jar.
Entpacken Sie die beiden .jar-Dateien in die Verzeichnisse log4j-api-2.17.1 bzw. log4j-core-2.17.1.
Öffnen Sie eine Kommandozeile (cmd) und wechseln Sie in das Verzeichnis.
Führen Sie folgenden Befehl aus:
<service-manager>\jdk\bin\jar.exe -cf0m log4j-[api|core]-2.17.1.jar META-INF\MANIFEST.MF .Die neu erstellten .jar-Dateien sind nicht komprimiert. Dies ist für die Microservices erforderlich.
Entpacken Sie jeden Microservice in ein Verzeichnis.
Navigieren Sie in dem Verzeichnis zu BOOT-INF\lib\ und löschen Sie die beiden Dateien log4j-api-2.*.jar und log4j-core-2.*.jar.
Kopieren Sie die neu erstellten nicht komprimierten .jar-Dateien log4j-api und log4j-core an diesen Standort.
Öffnen Sie eine Kommandozeile (cmd) und wechseln Sie zum Root-Verzeichnis der unkomprimierten Microservices.
Führen Sie den folgenden Befehl aus:
<service-manager>\jdk\bin\jar.exe -cf0m <microservice-name>-app.jar META-INF\MANIFEST.MF .Überschreiben Sie die ursprünglichen <microservice-name>-app.jar-Dateien mit den neu erstellten Dateien.
Ersetzen Sie <service-manager> mit dem absoluten Pfad der service-manager-Installation und führen Sie den Befehl für jede Datei aus.
Ersetzen Sie <service-manager> mit dem absoluten Pfad der service-manager-Installation. Ersetzen Sie <microservice-name> mit dem Namen des Microservices, z. B. inboxservice. Führen Sie den Befehl einmal pro Service aus.
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.
rechts temporär einblenden.
Bereiche können Sie einblenden. Alle ausgeblendeten Bereiche einer Seite blenden Sie über die Toolbar ein:
