am gestrigen Nachmittag hat ELO das ursprüngliche Statement revidiert, dass ELO nicht von der Log4j Sicherheitslücke betroffen ist.
Dennoch ist dies kein Grund zur direkten Sorge: Aktuell verwendet ELO in den ElasticSearch-Versionen sowie in den ELO Java Clients ab Version 10 log4j2. ELO geht davon aus, ungeachtet dessen, ob eine neue Java Version das Ausführen fremden Codes verhindert, dass die Schwachstelle nur von authentifizierten ELO-Benutzern im System ausgenutzt werden könnte. Somit ist der Einschätzung von ELO nach zum gegenwärtigen Zeitpunkt, auf Basis des bisherigen Kenntnisstandes, ein korrekt konfiguriertes und gesichertes ELO System, welches in einer DMZ steht, von externen Dritten über die Schwachstelle in log4j2 nicht angreifbar, da öffentliche APIs (bspw. im Index Server) u.a. hiervon nicht betroffen sind.
Nachfolgend finden Sie von ELO bereitgestellte Handlungsempfehlungen, welche Sie bei ihrer individuellen Nutzen-/Kosten-Risikoabwägung unterstützen und seitens ELO konkrete Handlungsempfehlungen gibt, um die Lücke in allen Modulen zu schließen welche log4j2 einsetzen.
Sollten Sie hierbei Unterstützung benötigen, so stehen Ihnen unsere Kollegen der Technik zur Verfügung. Sie erreichen die Kollegen unter technik@vario.ag .
ELO Versionen 21, 20, 12 als auch die neueren Java Clients von ELO 11 und ELO 10 setzen aktuelle Java Versionen ein, bei denen eine Remote Code Execution für RMI und ldap deaktiviert ist.
Die meisten ELO Module, bspw. ELO Indexserver, ELO WF oder der ELO Web Client setzen keine log4j2-Versionen ein und sind unabhängig der eingesetzten Java Version nicht betroffen.
Aktuell verwenden die von uns eingesetzten ElasticSearch-Versionen sowie ELO Java Clients ab Version 10 log4j2. Wir gehen davon aus, ungeachtet dessen, ob eine neue Java Version das Ausführen fremden Codes verhindert, dass die Schwachstelle nur von authentifizierten ELO-Benutzern im System ausgenutzt werden könnte.
Somit ist unserer Einschätzung nach zum gegenwärtigen Zeitpunkt, auf Basis des bisherigen Kenntnisstandes, ein korrekt konfiguriertes und gesichertes ELO System, welches in der Cloud oder einer DMZ steht, von externen Dritten über die Schwachstelle in log4j2 nicht angreifbar, da öffentliche APIs (bspw. im Index Server) u.a. hiervon nicht betroffen sind.
Aufgrund der dynamischen Entwicklung werden nachfolgend Module mit aktuellen Java Versionen getrennt gelistet, sodass eine bessere Risikoabwägung stattfinden kann. Da es nicht auszuschließen ist, dass in Zukunft weitere Schwachstellen durch den Einsatz von JNDI im Rahmen von log4j2 auftauchen, empfehlen wir generell durch einige Maßnahmen die Lücke in allen Modulen zu schließen welche log4j2 einsetzen.
Wir haben hierzu eine Liste mit akuten Handlungsempfehlungen sowie Handlungsempfehlungen zusammengestellt. Folgende ELO Versionen enthalten generell ein Update verwendeter log4j2-Bibliotheken auf Version 2.15.0 oder ein Schließen die Lücke:
Server Setup(aktualisiertElasticSearch,Flows, Indexserver)
21 (in Arbeit, geplant bis 15.12.2021)
20 (in Arbeit, geplant bis 15.12.2021)
12 (in Arbeit, geplant bis 15.12.2021)
11 (in Arbeit, geplant bis 15.12.2021)
Folgende Komponenten sind von CVE-2021-44228 betroffen, setzen eine ältere Java Version ein (welche eine Remote Code Execution zulässt) und sollten umgehend aktualisiert werden:
Java Clients <=10.10 oder <=11.05
sollten schnellstmöglich auf die aktuell neusten Versionen aktualisiert werden oder durch den bereitgestellten Registry-Key gepatched werden.
ELO ElasticSearch-Installationen (Serversetup 10, 11)
Es ist ein Austausch der log4j2-Bibliothek auf 2.15.0 in der ElasticSearch erforderlich.
ELO BLP 5.2
Setzen eines Konfigurationsparameters notwendig.
Wir empfehlen darüber hinaus die von uns bereitgestellten Indexserver Versionen einzuspielen, welche, unabhängig des CVE-2021-44228, einige aktuelle Sicherheitsupdates zum Schutz der ELO Systeme enthalten.
ELO IX 11.05.003
ELO IX 12.07.005
ELO IX 20.05.000
ELO IX 21.01.001
Handlungsempfehlungen
Folgende Module setzen log4j2 mit aktuellen Java Versionen ein oder besitzen Abhängigkeiten zu betroffenen Bibliotheken. Wir empfehlen die entsprechende Lücke durch Konfigurationseinstellungen oder Austauschen von aktuellen log4j2-Versionen endgültig zu schließen. Dies betrifft u.a. folgende Module
Java Client
Neue ELO Java Client Versionen stehen zur Verfügung.
Die Lücke kann alternativ über einen Registry-Key geschlossen werden, welcher per AD-Policy an alle Rechner verteilt werden kann.
ElasticSearch
Updaten der log4j-Bibliothek auf Version 2.15.0
Flows
Konfigurationseinstellung für den Flows-Worker (Karaf)
Einschätzung und Analyse von ELO Diensten und Applikationen
Allgemeine ELO Dienste
Grundlegend sind unsere Kern-Dienste von der Schwachstelle nicht betroffen, da log4j 2.x in unseren zentralen Diensten, welche u.a. eine öffentliche API zur Verfügung stellen, keine Anwendung findet. Dies betrifft u.a.:
ELO Indexserver
ELO Web Client
ELO WF
ELO Admin Console
ELO Automation Services
ELO Fulltext und Textreader
ELO Teamroom
ELO Replikation
ELO Importer
Einige ELO Dienste enthalten eine log4j2API-Bibliothek und sind als unkritisch einzustufen. Betroffen ist nur die eigentliche Implementierung des Logging-Frameworks aus der log4j2-Core-Bibliothek welche in den folgenden Diensten nicht enthalten ist.
ELO IMO
ELO Rest
ELO Smart Input
ELO Java Client
Der Java Client verwendet für das Logging ab ELO 10 Log4j2. Kunden die noch Java Clients kleiner gleich 11.05 oder 10.10 einsetzen sollten auf die aktuellen Versionen upgraden und den bereitgestellten Registry Patch einspielen.
Akut betroffene Versionen sind u.a.
Java Client bis einschließlich 11.05, enthält ein Java 8u172
Java Client bis einschließlich 10.10, enthält ein Java 8u172
ElasticSearch setzt standardmäßig log4j2 für das Logging ein und stellt somit ein potentielles Risko dar. Uns war es bisher nicht möglich die Schwachstelle über gezielte Angriffe, bspw. die ELO Suche oder direkte Authentifizierung über SearchGuard zu nutzen. Es werden bspw. keine Queries protokolliert, sodass Sucheingaben im Client nicht im Log ausgegeben werden.
Wir empfehlen die log4j2-Bibliotheken durch Version 2.15.0 auszutauschen.
Akut betroffene Versionen sind u.a.
ElasticSearch Installationen durch das Serversetup ELO 10
ElasticSearch Installationen durch das Serversetup ELO 11
Einsatz von log4j2 mit neuer Java Version in
ElasticSearch Installationen in ELO >=21.00: Mindestens Java 15
ElasticSearch Installationen in ELO >=20.00: Mindestens Java 14
ElasticSearch Installationen in ELO >=12.00: Mindestens Java 11.0.1
ELO Flows
ELO Flows Worker Instanzen basieren auf Apache Karaf wo standardmäßig log4j2 als Logging-Framework eingesetzt wird. Um eine Einheitlichkeit der Logging-Konzepte auf der Serverseite zu gewährleisten haben wir eine Umstellung der von ELO bereitgestellten Karaf-Installationen auf Logback vorgenommen. Log-Ausgaben der Flows-Komponenten oder des Flows-Workers werden somit nicht über log4j2 sondern Logback ausgegeben. Ab ELO 21 wird zudem mindestens Java 15 ausgeliefert. Wir schätzen das Risiko hier daher als gering ein.
Die Log4j2-Bibliotheken sind dennoch nach wie vor Bestandteil von Apache Karaf und können nicht ohne weiteres entfernt werden. Um sicher zu gehen, empfehlen wir eine Konfigurationseinstellung zu setzen.
ELO Business Solutions
Die Business Solutions sowie das ELO Job Portal von ELO HR Recruiting sind hiervon nicht betroffen da log4j2 nicht zum Einsatz kommt.
ELO BLP
Betroffen ist der ELO BLP >=5.2 durch den Einsatz von Apache Solr. Frühere Versionen des BLP sind nicht betroffen.
Da Angriffsmöglichkeiten zum gegenwärtigen Zeitpunkt nicht ausgeschlossen werden können, empfehlen wir dringend Konfigurationseinstellungen zu setzen, um die Lücke zu schließen.
Apache Solr in Version 8.11.1 steht noch nicht zur Verfügung.
Wir stellen schnellstmöglich Java Client Versionen für ELO 11, 12, 20 und 21 zur Verfügung. Diese enthalten eine aktuelle Version von log4j 2.15.0.
Alternativ können in der Windows-Registry die folgenden Einträge angepasst werden.
Am einfachsten ist es die aktuellen Werte der Einträge per Skript auszulesen und das Flag „-Dlog4j2.formatMsgNoLookups=true” an das erste vorkommen von .exe“ an zu hängen. In einem Powershell Script sieht das für die beiden Stellen in der Registry (CLSID und WOW6432Node\CLSID) in etwa so aus:
Die ElasticSearch nutzt log4j in Version 2.9.1 was insbesondere in Kombination mit alten Java Versionen (ELO 9, ELO 10, ELO 11) ein Sicherheitsrisiko darstellen kann. Wir empfehlen die verwendeten log4j-Bibliotheken durch aktuelle der Version 2.15.0 auszutauschen.
Update der Libraries unter Windows
Für Windows kann die folgende Anleitung durchgearbeitet werden:
Dienst ELO-servername-iSearch stoppen
Löschen der 3 Dateien im Verzeichnis /instdir/servers/ELO-servername-iSearch/lib
Ersetze alte log4j-jars im Java class path der Konfiguration des iSearch-Services (3 Dateien)
Dienst ELO-servername-iSearch starten
Update der Libraries unter Linux
Speziell für Linux haben wir ein Bash-Script erstellt, welches den Austausch der Bibliotheken vornimmt (ELO 20). Das Skript fragt nach dem Installationsverzeichnis von ELO und anschließend nach dem Service-Namen der iSearch.
Prüfen Sie im Anschluss ggf. die Berechtigungen auf die neu heruntergeladenen Dateien, hier müssen Sie ggf. entsprechend Ihrer Konfiguration noch eine Anpassung vornehmen.
Handlungsempfehlungen für Flows-Worker
Es steht eine aktualisierte Version des Flows Workers (21.01.001.000) zur verfügung..
Alternativ kann die Lücke generell über das Setzen der Eigenschaft formatMsgNoLookups in Karaf geschlossen werden. Diese findet sich in der Datei system.properties.
Anzupassende Datei:
%elo%/servers/%worker%/etc/system.properties
Zu ergänzende Zeile:
log4j2.formatMsgNoLookups=true
Handlungsempfehlungen für BLP 5.2
Über die Java Options in Apache Solr lässt sich die Lücke schließen, hierzu muss die Startdatei angepasst werden.
Anzupassende Datei:
solr.in.cmd
Zu ergänzende Zeile am Ende der Datei:
set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
Dieser Artikel wird laufend mit neuen Erkenntnissen aktualisiert.
Update 1: CVE-2021-44228 erwähnt Java 8u121. ldap JNDI-Aufrufe werden erst ab Java 8u191 deaktiviert. ELO Versionen 10 und 11 sind ebenfalls von der Remote Code Execution betroffen. Hinweise zu verfügbaren Java Client Versionen ergänzt.
Update 2: Flows Version ergänzt.
Update 3: Hinweise zu kommenden Server Setup-Versionen 11-21 ergänzt.
.png.cc87a7fb990ef43f342d243f86b40d7d.png)
Frage
Hendrik Schneider
Sehr geehrte Kundinnen und Kunden,
am gestrigen Nachmittag hat ELO das ursprüngliche Statement revidiert, dass ELO nicht von der Log4j Sicherheitslücke betroffen ist.
Dennoch ist dies kein Grund zur direkten Sorge: Aktuell verwendet ELO in den ElasticSearch-Versionen sowie in den ELO Java Clients ab Version 10 log4j2. ELO geht davon aus, ungeachtet dessen, ob eine neue Java Version das Ausführen fremden Codes verhindert, dass die Schwachstelle nur von authentifizierten ELO-Benutzern im System ausgenutzt werden könnte. Somit ist der Einschätzung von ELO nach zum gegenwärtigen Zeitpunkt, auf Basis des bisherigen Kenntnisstandes, ein korrekt konfiguriertes und gesichertes ELO System, welches in einer DMZ steht, von externen Dritten über die Schwachstelle in log4j2 nicht angreifbar, da öffentliche APIs (bspw. im Index Server) u.a. hiervon nicht betroffen sind.
Nachfolgend finden Sie von ELO bereitgestellte Handlungsempfehlungen, welche Sie bei ihrer individuellen Nutzen-/Kosten-Risikoabwägung unterstützen und seitens ELO konkrete Handlungsempfehlungen gibt, um die Lücke in allen Modulen zu schließen welche log4j2 einsetzen.
Sollten Sie hierbei Unterstützung benötigen, so stehen Ihnen unsere Kollegen der Technik zur Verfügung. Sie erreichen die Kollegen unter technik@vario.ag .
______________________________________________________________
Handlungsempfehlungen von ELO:
ELO Versionen 21, 20, 12 als auch die neueren Java Clients von ELO 11 und ELO 10 setzen aktuelle Java Versionen ein, bei denen eine Remote Code Execution für RMI und ldap deaktiviert ist.
Die meisten ELO Module, bspw. ELO Indexserver, ELO WF oder der ELO Web Client setzen keine log4j2-Versionen ein und sind unabhängig der eingesetzten Java Version nicht betroffen.
Aktuell verwenden die von uns eingesetzten ElasticSearch-Versionen sowie ELO Java Clients ab Version 10 log4j2. Wir gehen davon aus, ungeachtet dessen, ob eine neue Java Version das Ausführen fremden Codes verhindert, dass die Schwachstelle nur von authentifizierten ELO-Benutzern im System ausgenutzt werden könnte.
Somit ist unserer Einschätzung nach zum gegenwärtigen Zeitpunkt, auf Basis des bisherigen Kenntnisstandes, ein korrekt konfiguriertes und gesichertes ELO System, welches in der Cloud oder einer DMZ steht, von externen Dritten über die Schwachstelle in log4j2 nicht angreifbar, da öffentliche APIs (bspw. im Index Server) u.a. hiervon nicht betroffen sind.
Aufgrund der dynamischen Entwicklung werden nachfolgend Module mit aktuellen Java Versionen getrennt gelistet, sodass eine bessere Risikoabwägung stattfinden kann. Da es nicht auszuschließen ist, dass in Zukunft weitere Schwachstellen durch den Einsatz von JNDI im Rahmen von log4j2 auftauchen, empfehlen wir generell durch einige Maßnahmen die Lücke in allen Modulen zu schließen welche log4j2 einsetzen.
Wir haben hierzu eine Liste mit akuten Handlungsempfehlungen sowie Handlungsempfehlungen zusammengestellt. Folgende ELO Versionen enthalten generell ein Update verwendeter log4j2-Bibliotheken auf Version 2.15.0 oder ein Schließen die Lücke:
20.07.001 (verfügbar),
21.01.001 (verfügbar),
12.11.000 (verfügbar),
11.13.001 (verfügbar)
21 (in Arbeit, geplant bis 15.12.2021)
20 (in Arbeit, geplant bis 15.12.2021)
12 (in Arbeit, geplant bis 15.12.2021)
11 (in Arbeit, geplant bis 15.12.2021)
(Siehe auch CVE-2021-44228, https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
Weiterführende Hinweise:
Akute Handlungsempfehlungen
Folgende Komponenten sind von CVE-2021-44228 betroffen, setzen eine ältere Java Version ein (welche eine Remote Code Execution zulässt) und sollten umgehend aktualisiert werden:
sollten schnellstmöglich auf die aktuell neusten Versionen aktualisiert werden oder durch den bereitgestellten Registry-Key gepatched werden.
Es ist ein Austausch der log4j2-Bibliothek auf 2.15.0 in der ElasticSearch erforderlich.
Setzen eines Konfigurationsparameters notwendig.
Wir empfehlen darüber hinaus die von uns bereitgestellten Indexserver Versionen einzuspielen, welche, unabhängig des CVE-2021-44228, einige aktuelle Sicherheitsupdates zum Schutz der ELO Systeme enthalten.
Handlungsempfehlungen
Folgende Module setzen log4j2 mit aktuellen Java Versionen ein oder besitzen Abhängigkeiten zu betroffenen Bibliotheken. Wir empfehlen die entsprechende Lücke durch Konfigurationseinstellungen oder Austauschen von aktuellen log4j2-Versionen endgültig zu schließen. Dies betrifft u.a. folgende Module
Neue ELO Java Client Versionen stehen zur Verfügung.
Die Lücke kann alternativ über einen Registry-Key geschlossen werden, welcher per AD-Policy an alle Rechner verteilt werden kann.
Updaten der log4j-Bibliothek auf Version 2.15.0
Konfigurationseinstellung für den Flows-Worker (Karaf)
Einschätzung und Analyse von ELO Diensten und Applikationen
Allgemeine ELO Dienste
Grundlegend sind unsere Kern-Dienste von der Schwachstelle nicht betroffen, da log4j 2.x in unseren zentralen Diensten, welche u.a. eine öffentliche API zur Verfügung stellen, keine Anwendung findet. Dies betrifft u.a.:
Einige ELO Dienste enthalten eine log4j2 API-Bibliothek und sind als unkritisch einzustufen. Betroffen ist nur die eigentliche Implementierung des Logging-Frameworks aus der log4j2-Core-Bibliothek welche in den folgenden Diensten nicht enthalten ist.
ELO Java Client
Der Java Client verwendet für das Logging ab ELO 10 Log4j2. Kunden die noch Java Clients kleiner gleich 11.05 oder 10.10 einsetzen sollten auf die aktuellen Versionen upgraden und den bereitgestellten Registry Patch einspielen.
Akut betroffene Versionen sind u.a.
Einsatz von log4j2 mit neuer Java Version in
Java Client 11.13: Java 8u222b10 (Zulu 8.40.0.25)
Nicht betroffen, kein Einsatz von log4j2
Search
ElasticSearch setzt standardmäßig log4j2 für das Logging ein und stellt somit ein potentielles Risko dar. Uns war es bisher nicht möglich die Schwachstelle über gezielte Angriffe, bspw. die ELO Suche oder direkte Authentifizierung über SearchGuard zu nutzen. Es werden bspw. keine Queries protokolliert, sodass Sucheingaben im Client nicht im Log ausgegeben werden.
Wir empfehlen die log4j2-Bibliotheken durch Version 2.15.0 auszutauschen.
Akut betroffene Versionen sind u.a.
ElasticSearch Installationen durch das Serversetup ELO 11
Einsatz von log4j2 mit neuer Java Version in
ELO Flows
ELO Flows Worker Instanzen basieren auf Apache Karaf wo standardmäßig log4j2 als Logging-Framework eingesetzt wird. Um eine Einheitlichkeit der Logging-Konzepte auf der Serverseite zu gewährleisten haben wir eine Umstellung der von ELO bereitgestellten Karaf-Installationen auf Logback vorgenommen. Log-Ausgaben der Flows-Komponenten oder des Flows-Workers werden somit nicht über log4j2 sondern Logback ausgegeben. Ab ELO 21 wird zudem mindestens Java 15 ausgeliefert. Wir schätzen das Risiko hier daher als gering ein.
Die Log4j2-Bibliotheken sind dennoch nach wie vor Bestandteil von Apache Karaf und können nicht ohne weiteres entfernt werden. Um sicher zu gehen, empfehlen wir eine Konfigurationseinstellung zu setzen.
ELO Business Solutions
Die Business Solutions sowie das ELO Job Portal von ELO HR Recruiting sind hiervon nicht betroffen da log4j2 nicht zum Einsatz kommt.
ELO BLP
Betroffen ist der ELO BLP >=5.2 durch den Einsatz von Apache Solr. Frühere Versionen des BLP sind nicht betroffen.
Da Angriffsmöglichkeiten zum gegenwärtigen Zeitpunkt nicht ausgeschlossen werden können, empfehlen wir dringend Konfigurationseinstellungen zu setzen, um die Lücke zu schließen.
Apache Solr in Version 8.11.1 steht noch nicht zur Verfügung.
https://solr.apache.org/downloads.html
Handlungsempfehlungen
Handlungsempfehlungen für Java Clients
Wir stellen schnellstmöglich Java Client Versionen für ELO 11, 12, 20 und 21 zur Verfügung. Diese enthalten eine aktuelle Version von log4j 2.15.0.
Alternativ können in der Windows-Registry die folgenden Einträge angepasst werden.
Am einfachsten ist es die aktuellen Werte der Einträge per Skript auszulesen und das Flag „-Dlog4j2.formatMsgNoLookups=true” an das erste vorkommen von .exe“ an zu hängen. In einem Powershell Script sieht das für die beiden Stellen in der Registry (CLSID und WOW6432Node\CLSID) in etwa so aus:
Powershell
$jc1 = (Get-Item -Path 'Registry::HKEY_CLASSES_ROOT\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32').GetValue("") if (!($jc1 -like '*-Dlog4j2.formatMsgNoLookups=true*')){ $jc1 = $jc1 -replace '(?=\.exe\")\.exe\"(.*)', '.exe" -Dlog4j2.formatMsgNoLookups=true$1' #echo $jc1 Set-ItemProperty -Path 'Registry::HKEY_CLASSES_ROOT\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32' -Name ‘(Default)’ -Value $jc1 } $jc2 = (Get-Item -Path 'Registry::HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32').GetValue("") if (!($jc2 -like '*-Dlog4j2.formatMsgNoLookups=true*')){ $jc2 = $jc2 -replace '(?=\.exe\")\.exe\"(.*)', '.exe" -Dlog4j2.formatMsgNoLookups=true$1' #echo $jc2 Set-ItemProperty -Path 'Registry::HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32' -Name ‘(Default)’ -Value $jc2 }Zur Kontrolle, oder für einen Alternativen Ansatz, sollten die Einträge in etwa so aussehen:
(ggf. als .reg speichern und ausführen)
ELO 11
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32] @="\"C:\\Program Files\\ELO Java Client\\jre\\bin\\ELOJavaClientw.exe\" -Dlog4j2.formatMsgNoLookups=true -Djava.library.path=\"C:\\Program Files\\ELO Java Client\\bin\" -DShutdownTimeout=2147483647 -Djava.util.Arrays.useLegacyMergeSort=true -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Xms200m -Xmx1000m -cp \"C:\\Program Files\\ELO Java Client\\EloClient.jar;C:\\Program Files\\ELO Java Client\\manifest.jar\" com.jniwrapper.win32.com.DispatchComServerFactory de.elo.client.compatibility.EloAutomationServerImpl"Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32] @="\"C:\\Program Files\\ELO Java Client\\jre\\bin\\ELOJavaClientw.exe\" -Dlog4j2.formatMsgNoLookups=true -Djava.library.path=\"C:\\Program Files\\ELO Java Client\\bin\" -DShutdownTimeout=2147483647 -Djava.util.Arrays.useLegacyMergeSort=true -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Xms200m -Xmx1000m -cp \"C:\\Program Files\\ELO Java Client\\EloClient.jar;C:\\Program Files\\ELO Java Client\\manifest.jar\" com.jniwrapper.win32.com.DispatchComServerFactory de.elo.client.compatibility.EloAutomationServerImpl"Die Verzeichnisse müssen zuvor ggf. oben angepasst werden
ELO 12 und neuer
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32] @="\"C:\\Program Files\\ELO Java Client\\jre\\bin\\ELOJavaClientw.exe\" -Dlog4j2.formatMsgNoLookups=true -Djava.library.path=\"C:\\Program Files\\ELO Java Client\\bin\" -DShutdownTimeout=2147483647 -Djava.util.Arrays.useLegacyMergeSort=true -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -XX:+ShowCodeDetailsInExceptionMessages --add-opens=java.desktop/java.awt=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.desktop/java.awt.event=ALL-UNNAMED --add-opens=java.desktop/javax.swing=ALL-UNNAMED --add-opens=java.desktop/javax.swing.event=ALL-UNNAMED --add-opens=java.desktop/javax.swing.table=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --illegal-access=permit -Xms200m -Xmx1000m -cp \"C:\\Program Files\\ELO Java Client\\EloClient.jar;C:\\Program Files\\ELO Java Client\\manifest.jar\" com.jniwrapper.win32.com.DispatchComServerFactory de.elo.client.compatibility.EloAutomationServerImpl -individualJVM "Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{1CC9C4CB-BCF7-422D-AFD5-BF72A7FA5ABE}\LocalServer32] @="\"C:\\Program Files\\ELO Java Client\\jre\\bin\\ELOJavaClientw.exe\" -Dlog4j2.formatMsgNoLookups=true -Djava.library.path=\"C:\\Program Files\\ELO Java Client\\bin\" -DShutdownTimeout=2147483647 -Djava.util.Arrays.useLegacyMergeSort=true -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -XX:+ShowCodeDetailsInExceptionMessages --add-opens=java.desktop/java.awt=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.desktop/java.awt.event=ALL-UNNAMED --add-opens=java.desktop/javax.swing=ALL-UNNAMED --add-opens=java.desktop/javax.swing.event=ALL-UNNAMED --add-opens=java.desktop/javax.swing.table=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --illegal-access=permit -Xms200m -Xmx1000m -cp \"C:\\Program Files\\ELO Java Client\\EloClient.jar;C:\\Program Files\\ELO Java Client\\manifest.jar\" com.jniwrapper.win32.com.DispatchComServerFactory de.elo.client.compatibility.EloAutomationServerImpl -individualJVM "Die Verzeichnisse müssen zuvor ggf. oben angepasst werden
Handlungsempfehlungen für die ElasticSearch
Die ElasticSearch nutzt log4j in Version 2.9.1 was insbesondere in Kombination mit alten Java Versionen (ELO 9, ELO 10, ELO 11) ein Sicherheitsrisiko darstellen kann. Wir empfehlen die verwendeten log4j-Bibliotheken durch aktuelle der Version 2.15.0 auszutauschen.
Update der Libraries unter Windows
Für Windows kann die folgende Anleitung durchgearbeitet werden:
Update der Libraries unter Linux
Speziell für Linux haben wir ein Bash-Script erstellt, welches den Austausch der Bibliotheken vornimmt (ELO 20). Das Skript fragt nach dem Installationsverzeichnis von ELO und anschließend nach dem Service-Namen der iSearch.
update-log4j
Prüfen Sie im Anschluss ggf. die Berechtigungen auf die neu heruntergeladenen Dateien, hier müssen Sie ggf. entsprechend Ihrer Konfiguration noch eine Anpassung vornehmen.
Handlungsempfehlungen für Flows-Worker
Es steht eine aktualisierte Version des Flows Workers (21.01.001.000) zur verfügung..
Alternativ kann die Lücke generell über das Setzen der Eigenschaft formatMsgNoLookups in Karaf geschlossen werden. Diese findet sich in der Datei system.properties.
Anzupassende Datei:
Zu ergänzende Zeile:
Handlungsempfehlungen für BLP 5.2
Über die Java Options in Apache Solr lässt sich die Lücke schließen, hierzu muss die Startdatei angepasst werden.
Anzupassende Datei:
Zu ergänzende Zeile am Ende der Datei:
Dieser Artikel wird laufend mit neuen Erkenntnissen aktualisiert.
Update 1: CVE-2021-44228 erwähnt Java 8u121. ldap JNDI-Aufrufe werden erst ab Java 8u191 deaktiviert. ELO Versionen 10 und 11 sind ebenfalls von der Remote Code Execution betroffen. Hinweise zu verfügbaren Java Client Versionen ergänzt.
Update 2: Flows Version ergänzt.
Update 3: Hinweise zu kommenden Server Setup-Versionen 11-21 ergänzt.
Link zu diesem Kommentar
Auf anderen Seiten teilen
0 Antworten auf diese Frage
Empfohlene Beiträge