Aktuelle Informationen zur Log4j-Lücke
Erfahren Sie, ob Ihr Storage-Systeme oder Ihre Server von der Schwachstelle betroffen sind.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) geht bei der derzeitigen Schwachstelle in der verbreiteten Java-Bibliothek Log4j (Versionen 2.0 bis 2.14.1) von einer extrem kritischen Bedrohungslage aus. Schließlich wird das betroffene Produkt in vielen Systemen verwendet. Da dieser Angriffspunkt zudem sehr einfach auszunutzen ist – ein Proof-of-Concept wurde dazu bereits veröffentlicht – sollten umgehend Sicherheitsmaßnahmen getroffen werden.
Sollte die Schwachstelle ausgeschöpft werden, ist eine vollständige Übernahme des betroffenen Systems möglich. Es gibt zwar bereits ein Sicherheits-Update für die Java-Bibliothek Log4j, allerdings müssen auch alle Produkte, die auf diese Bibliothek zugreifen, angepasst werden. (Das Programm-Modul wurde in die Architektur diverser Software-Produkte integriert.)
Unsere Techniker haben sich deshalb mit unseren Lieferanten kurzgeschlossen, um herauszufinden, welche Produkte verwundbar sind und für welche es bereits Updates gibt. Es könnten in den nächsten Tagen weitere Produkte hinzukommen. Wir werden Sie deshalb an dieser Stelle über die jeweils notwendigen Modifikationen informieren.
Lesen Sie hier, welche Systeme notwendige Updates benötigen, die es umgehend einzuspielen gilt, und welche Produkte davon nicht betroffen sind.
Der Storage Manager maxView von Microsemi/Adaptec nutzt die Java-Bibliothek. Die Entwickler empfehlen stattdessen vorerst ARCCONF CLI zu benutzen.
Update 03.01.2022:
Wenn Sie derzeit maxView verwenden, kann es aufgrund von Apache Log4j Remote Code Execution (CVE-2021-44228) zu einer Sicherheitslücke im Programm kommen.
Da maxView das Log4j 2.14.0-Framework zum Protokollieren von Tomcat-Webserver-Protokollen verwendet, fällt es unter die Liste der betroffenen Produkte. Obwohl maxView keine JNDI-Funktionen nutzt oder verfügbar macht, ist die Nachschlagefunktion, die standardmäßig mit maxView geliefert wird, im Log4j nicht deaktiviert. Microchip Adaptec arbeitet zügig daran, dieses Problem innerhalb von maxView zu beheben. Bitte folgen Sie ASK-Artikel 17524 für Updates und endgültige Lösungen.
Bitte klicken Sie im Artikel unten auf „Benachrichtigen“, um Updates zu erhalten. (Die Option steht nur zur Verfügung, wenn Sie dort mit Ihrem Microchip Adaptec Konto eingeloggt sind.)
Verwendet keine Log4j Library.
Firmware und Software enthalten keine Bestandteile von Apache.
Die Management Software LSI Storage Authority (LSA) verwendet kein Java, daher existiert hier kein Sicherheitsproblem mit dieser Bibliothek.
Der MegaRAID Storage Manager (MSM) hingegen nutzt log4j, jedoch nur in der Version 1.2.15.
Broadcom hat die MSM-Versionen 17.05.04.00 bis 17.06.02.01 als verwundbar ausgemacht. Ein Entwickler-Team arbeitet daran, die neueste log4j-Version in die MSM Software einzubauen. Frühere Versionen von MSM sollten nicht mehr verwendet werden.
Broadcom hat folgende Informationen dazu veröffentlicht.
Die Software PowerPanel Business und das PDNU2 Utility verwenden die Versionen Log4j v.1.2.17. PowerPanel Business verwendet in Log4J 1.2.17 keinen JMSAppender. Daher ist es von den aktuellen Schwachstellen nicht betroffen.
- SANsymphony
SANsymphony ist von diesem Problem nicht betroffen. Wenn Sie betroffene Komponenten auf demselben Server haben – etwa wenn Software von Drittanbietern installiert wurde – können sie wie üblich aktualisiert werden.
- Swarm
Die Apache Log4j2-Bibliothek wird von einigen Versionen der Gateway- und Elasticsearch-Funktionen von Swarm verwendet. FileFly nutzt Log4j2 nicht und ist daher nicht betroffen. Weitere Informationen darüber, wie sich dieses Problem auf Swarm auswirkt, sowie Workarounds für betroffene Versionen finden Sie unter: DataCore Swarm log4j Abhilfemaßnahmen (CVE-2021-44228)
- vFilO
Die Apache Log4j2-Bibliothek wird für die Protokollierung von einigen vFilO-Komponenten verwendet, und alle Versionen von vFilO, die über das DataCore-Downloadportal verfügbar sind, sind von diesem Problem betroffen.
Durch diese Schwachstelle könnte ein Angreifer mit direktem Netzwerkzugriff (z.B. ohne Firewall zwischen Angreifer und vFilO-System) vFilO dazu bringen, eine JNDI-Verbindung zu einem entfernten LDAP-Server zu öffnen, beliebigen Code abzurufen und auszuführen. Dies kann zur unbeabsichtigten Offenlegung von Informationen, zum Hinzufügen oder Ändern von Daten oder zu Denial of Service (DoS) führen.
Ein Fix ist in Build 4.6.4-116 verfügbar. Sie können das Update-Paket erhalten, indem Sie eine Anfrage an den DataCore-Support stellen. Bitte geben Sie bei der Meldung des Vorfalls die Version an, die Sie derzeit verwenden.
Infortrend hat die Log4j Lücke mit neuer Firmware geschlossen (Update vom 3.1.2022)
Infortrend konnte mit der Firmware Version 1.52E44 die Log4j Lücke innerhalb der betroffenen GS-Serie patchen.
Die Oberflächen SANWatch oder EonOne indes benutzen keine derartige Software-Bibliothek.
NAKIVO Backup & Replication verwendet die Apache Log4j-Bibliothek, die Teil der Apache Logging Services ist. NAKIVO hat eine Sicherheitswarnung herausgegeben, die detaillierte Schritte zur Behebung dieses Problems enthält.
Linux: Eine Vorgehensweise finden Sie hier.
Windows: Stellen Sie sicher, dass Sie das 7z-Tool installiert haben. Wechseln Sie in den Ordner libs, der sich im Installationsordner von NAKIVO Backup & Replication befindet. Öffnen Sie mit 7z die Datei log4j-core-2.2.jar und entfernen Sie JndiLookup.class aus der jar-Datei.
Starten Sie jeweils NAKIVO Backup & Replication neu.
Wichtig: CVE-2021-44228 ist eine schwere Sicherheitslücke. NAKIVO rät dazu dringend, den manuellen Fix so bald wie möglich anzuwenden. Dies sei der beste Weg, um das Risiko von Sicherheitsverletzungen zu vermeiden.
Modelle mit dem proprietären Betriebssystem OS7 sind von dem Problem nicht betroffen. Unsere Techniker haben die NASDeluxe-Systeme NDL-2800SR und NDL-2880R untersucht und keine Spuren der Log4j-Bibliothek oder der Java-Binärdateien selbst gefunden. Zusätzlich zu unseren Ergebnissen haben wir eine Bestätigung vom Hersteller bekommen, dass die neueste Firmware (Version 2.06.03) keine anfälligen Java-Binärdateien enthalten. Im Folgenden finden Sie weitere Informationen zur Überprüfung Ihrer NDL-2xxx-Systeme. Wir werden diesen Abschnitt aktualisieren, sobald wir weitere relevante Informationen erhalten.
Hier sind die Schritte, falls Sie es selbst überprüfen möchten
NEC-Entwickler (TopRAID) haben uns mitgeteilt, dass das Problem (CVE-2021-44228) untersucht worden sei und nur der „Storage Analyzer for VMware vRealize Operations“ von diesem Problem betroffen sein könnte. (Also die VMware-Software und nicht das NEC-Produkt selbst.) Sie bestätigten zudem, dass es keine anderen Probleme im Zusammenhang mit CVE-2021-44228 und NEC Storage-Produkten gäbe.
Netgear teilte uns mit, dass ihre Switche von der Lücke nicht betroffen seien.
Die Produkte von Open-E sind offenbar nicht direkt betroffen, da lediglich System-Tools von Adaptec und LSI/Broadcom die Log4j-Library verwenden. Die Entwicklungsabteilung simulierte dennoch mögliche Auswirkungen und kam bereits gestern zu dem Schluss, dass die Storage-Betriebssysteme DSS V7 und JovianDSS nicht vom Log4j-Problem betroffen sind.
Verwendet keine Log4j Library.
Hier ist nach derzeitigem Stand der Dinge lediglich der Supermicro Power Manager (SPM) von der Schwachstelle betroffen.
| Supermicro Produkt | Betroffen? | Maßnahmen |
|---|---|---|
| BIOS | Nein | |
| BMC (all firmware branches) | Nein | |
| SuperCloudComposer | Nein | |
| SSM | Nein | |
| SD5 | Nein | |
| SPM | Ja | Upgrade auf Log4j 2.15.0 und neues SPM. |
| SMCIPMITool | Nein | |
| SCC Analytics | Nein | |
| SCC PODM | Nein | |
| vCenter Plug-in | Nein | |
| Super Diagnostics Offline | Nein | |
| SUM | Nein | |
| SUM Service (SUM_SERVER) | Nein |
TrueNAS/FreeNAS verwendet keine Java-Komponenten. (Blog-Artikel) Auch TrueNAS-Archiware/TrueNAS-Nextcloud-Integrationen sind nicht betroffen.
