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:
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://logging.apache.org/log4j/2.x/security.html
- https://www.lunasec.io/docs/blog/log4j-zero-day
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:
- Es muss eine Java- basierte Applikation einen Dienst präsentieren, der (auch indirekt) kompromittierende Anfragen entgegen nimmt und diese Anfragen unter Nutzung von Log4j protokolliert.
- Die Java Version muss älter als die Versionen Java 6 U211, Java 7 U201 oder Java 8 U191 sein oder die standardmäßigen Einstellungen zur Verhinderung der Ausführung von nachgeladenem Code aus externen Quellen müssen deaktiviert sein.
- Es ist Log4j in Versionen 2.0-beta9 bis 2.14.1 im Einsatz.
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.
Applikationen
Zimbra Collaboration Suite
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 vSphere
VMware fasst in einem eigenen Artikel alle nötigen Informationen sowie Links zu den relevanten Sicherheitshinweisen zusammen:
- VMware Security Advisory VMSA-2021-0028 (Beschreibung der Sicherheitslücke und aktuelle Maßnamen)
- VMSA-2021-0028 Questions & Answers (FAQ)
- VMSA-2021-0028 & Log4j: What You Need to Know (Artikel im VMware Blog)
- VMware Communities Thread On CVE-2021-44228 (Forum)
- Tips for Patching VMware vSphere & Cloud Infrastructure
- VMware vSphere Security Configuration Guide
- VMware Ransomware Resource Center
- VMware Ports & Protocols Firewalling Guidance (ports.vmware.com)
Quelle: https://blogs.vmware.com/vsphere/2021/12/vmsa-2021-0028-log4j-what-you-need-to-know.html.
VMware Cloud Director
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.
Apache SOLR
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
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.
