Auf verschiedenen Portalen wurde über eine kritische Zero-Day-Lücke in Log4j unter dem Namen Log4Shell berichtet. Die offiziellen Meldungen dazu sind den originalen Quellen zu entnehmen:
Durch die Sicherheitslücke verwundbar sind die Log4j Versionen 2.0-beta9 bis 2.14.1. Zusätzlich wird darauf verwiesen, dass alle Applikationen, die mindestens Java 8 U121 mit den
Standardeinstellungen verwenden, selbst bei verwundbarer Log4j Version nicht kompromittierbar sind, da hier die Standardeinstellungen
com.sun.jndi.rmi.object.trustURLCodebase false com.sun.jndi.cosnaming.object.trustURLCodebase false
die Ausführung von Code eines fremden Systems (Remote Code Execution) verhindern. Weitere Informationen dazu sind in den Java - Release Notes
zu finden: https://www.oracle.com/java/technologies/javase/8u121-relnotes.html.
Nach derzeitigem Kenntnisstand ist die Sicherheitslücke demnach nur ausnutzbar, wenn alle der folgenden Bedingungen zutreffend sind:
Falls es nicht ohne weiters möglich ist, die aktuelle Log4j Version 2.15.x zu verwenden, so kann die verwundbare Funktion mittels Konfigurationsparameter log4j2.formatMsgNoLookups=true deaktiviert werden.
Laut der vom Softwarehersteller Zimbra veröffentlichten Mitteilung, verwenden die aktuellen Versionen der Zimbra Collaboration Suite die Komponente Log4j in der Version 1.2.16 und sind somit nicht für Angriffe unter Ausnutzung dieser Sicherheitslücke anfällig.
Update (15.12.2021):
0-day Exploit Vulnerability for log4j (CVE-2021-44228)
After intensive review and testing, Zimbra Development determined that the 0-day exploit vulnerability for log4j (CVE-2021-44228) does not affect the current Supported Zimbra versions (9.0.0 & 8.8.15). Zimbra Collaboration Server currently uses log4j1 version 1.2.16 which doesn't contain the lookup expression feature that is found within versions 2.0 to 2.17, which is the cause of the vulnerability. Also, Redhat (CVE-2021-4104) vulnerability does not affect the Zimbra Collaboration Server version (8.8.15 & 9.0.0). For this vulnerability to affect the server, it needs JMSAppender, which the ZCS Server does not use, and the ability to append configuration files.
Quellen:
https://support.zimbra.com
https://wiki.zimbra.com/wiki/Security_Center
VMware fasst in einem eigenen Artikel alle nötigen Informationen sowie Links zu den relevanten Sicherheitshinweisen zusammen:
Quelle: https://blogs.vmware.com/vsphere/2021/12/vmsa-2021-0028-log4j-what-you-need-to-know.html.
VMware Cloud Director ist laut der Übersicht unter https://www.vmware.com/security/advisories/VMSA-2021-0028.html nicht von dieser Sicherheitslücke betroffen. Eine offizielle Bestätigung seitens VMware steht hier noch aus.
Für Apache SOLR kann die Anfälligkeit für die o.g. Sicherheitslücke durch aktivieren der Java-Option log4j2.formatMsgNoLookups=true beseitigt werden. Dazu ist folgende Option am Ende der Konfigurationsdatei /etc/default/solr.in.sh nötig:
# CVE-2021-44228 - Log4j (Log4Shell) Mitigation SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
Diese Konfiguration wurde bereits vorsorglich auf allen von managedhosting.de betriebenen Instanzen mit Managed Service Paket ausgerollt.
FileCloud ist eine PHP- basierte Anwendung und somit nicht direkt von CVE-2021-44228 - Log4j (Log4Shell) betroffen. Jedoch verwendet FileCloud zur Indizierung von Inhalten Apache SOLR, welcher wiederum Log4j benutzt. Nach jetzigem Kenntnisstand ist seitens der Applikation kein Durchgriff auf die entsprechenden Funktionen in Log4j möglich. Vorsorglich wurde jedoch die für die Härtung empfohlene SOLR - Konfiguration auf allen von managedhosting.de betriebenen FileCloud- Instanzen ausgerollt.
Update (16.12.2021): FileCloud hat inzwischen einen entsprechenden Patch für SOLOR und eine aktualisierte Version veröffentlicht.
Quelle: https://www.getfilecloud.com/supportdocs/display/cloud/Advisory+2021-12-2+Impact+of+Apache+Log4j2+Vulnerability+on+FileCloud+Customers
