LOG4J ist eine gängige JAVA-Logging-Bibliothek, die von APACHE zur Verfügung gestellt wird und in vielen Produkten, wie JAVA-Produkten oder Webservice-Plattformen, verwendet wird. XPLM-Produkte verwenden log4j-Bibliotheken direkt oder indirekt in ihrem Code. Der kritische Code ist ein Sicherheitsproblem in den log4j-Bibliotheken, das hier erläutert wird:
https://logging.apache.org/log4j/2.x/security.html
Die Sanierungsstrategie von XPLM sieht in Kategorien wie folgt aus.
Kategorie 1: Entfernen Sie die kritische Klassendatei aus bestehenden log4j-Bibliotheken
Deaktivieren Sie die kritische log4j-Funktionalität vollständig
Eine sofortige Lösung, um die kritische Funktionalität zu deaktivieren, besteht darin, die kritische Klassendatei aus den log4j jar-Dateien und den angesammelten jar-Dateien von Drittanbietern zu entfernen. Die folgende Datei muss aus den jar-Dateien entfernt werden:
org\apache\logging\log4j\core\lookup\JndiLookup.class
Betroffen sind folgende jar-Dateien:
Allgemein log4j log4j-core*.jar Version 2.x
Allgemein log4j log4j *.jar Version 2.x
Betroffene Jar-Dateien in XPLM-Produkten
ECAD Integrate ivs-*-main.jar (mehrere Speicherorte)
Allgemeine Anweisungen für die Entfernung, die für jedes Glas auszuführen sind:
1. Schließen Sie die XPLM-Integration und die damit verbundenen Tools und vergewissern Sie sich, dass die Plattform des Connectors nicht ausgeführt wird (kein Symbol in der Systemablage).
2. Gehen Sie zu den betroffenen jar-Dateien und ändern Sie die .jar-Dateierweiterung in .zip
3. Bearbeiten Sie die ZIP-Datei: Löschen Sie die Datei org\apache\logging\log4j\core\lookup\JndiLookup.class
4. .zip wieder in .jar umbenennen
Das Entfernen der Klasse hat keine Nebeneffekte für die Integrationen, da die entsprechende Klasse von den Integrationen nicht verwendet wird.
Die kritische Nachschlagefunktion kann in log4j auch durch Umgebungseinstellungen deaktiviert werden, aber dieser von Apache angebotene Workaround ist nicht in allen Fällen sicher.
SET LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Diese Einstellung muss in den Startskripten der XPLM-Integrationsprodukte und/oder in einer Systemumgebungsvariablen gesetzt werden, um die kritischen Funktionen abzuschalten. Stellen Sie sicher, dass die Systeme nach den Änderungen neu gestartet werden.
Kategorie 2: Ersetzen Sie log4j durch Version 2.17 oder höher
Das Problem der Sicherheitslücke wurde in den Versionen 2.17 oder höher von log4j behoben. Administratoren müssen die log4j-Bibliotheken ersetzen und alle Startklassenpfade und Befehlsskripte für JAVA anpassen.
Hotfixes für bestimmte Produkte stellen die aktualisierte log4j-Bibliothek und die zugehörigen Konfigurationseinstellungen in Startskripten bereit, um die Installation zu erleichtern. Die folgenden Hotfixes sind verfügbar:
Kategorie 3: XPLM Produkt-Releases oder Hotfix
Alle zukünftigen XPLM Produktversionen enthalten eine log4j Version 2.17 oder höher.
Wenn Sie Fragen haben oder Unterstützung bei der Durchführung der Maßnahmen benötigen, wenden Sie sich bitte an [email protected] einschließlich Informationen:
- Name des Kunden und Name der Kontaktperson
- Verwendetes XPLM-Produkt einschließlich Version und letzter Aktualisierung
- Integrierte Produkte, die Sie von anderen Anbietern verwenden
Alle von XPLM bereitgestellten Maßnahmen zur Produktbehebung gelten für aktuelle und aktiv unterstützte Softwareversionen. Die Abhilfemaßnahmen für diese Versionen sind jedoch ähnlich oder identisch mit früheren Versionen, die Log4j v1 oder v2 nutzen und von XPLM nicht mehr aktiv unterstützt werden.
XPLM empfiehlt Kunden mit älteren Versionen dringend, ähnliche Maßnahmen zum Schutz ihrer Infrastruktur zu ergreifen und sollte nicht davon ausgehen, dass frühere Versionen der Software nicht von den bisher bekannt gewordenen Schwachstellen betroffen sind.