Blog
In unserem Blog finden Sie viele spannende Artikel rund um die Themen i‑effect®, EDI und IBM i. Wenn Sie Vorschläge haben für einen Thema, das Sie interessiert, freuen wir uns auf Ihre Vorschläge.
Hinweis zu i‑effect® und der Log4j-Sicherheitslücke (CVE-2021-44228)
Kurzfassung - Über die Lücke in der Software-Komponente Log4j wird aktuell von vielen Seiten berichtet. i‑effect® ist von der Sicherheitslücke CVE-2021-44228 in Log4j 2.x nicht betroffen. In älteren Versionen von i‑effect® wurde allerdings im ZUGFeRD-Modul die Version 1.2 von Log4j verwendet. Auch wenn diese Version durch CVE-2021-44228 nicht betroffen ist, empfehlen wir aufgrund einer anderen weniger kritischen Sicherheitslücke in Log4j 1.2 (CVE-2021-4104) für Anwender:innen von i‑effect® 2.7.62 (nur das ZUGFeRD-Modul) ein Update auf die aktuellste i‑effect® Version.
Donnerstag, 16. Dezember 2021
Ist i‑effect® von der Log4j-Sicherheitslücke betroffen?
Nein, die Standardsoftwarekomponenten von i‑effect® sind nach Untersuchung des Quellcodes und des Changelogs der letzten Versionen nicht von der aktuellen Log4j-Sicherheitslücke (CVE-2021-44228) betroffen.
Log4j kommt in unserer Software in aktuellen Versionen nicht mehr zum Einsatz, i‑effect® setzt zur Protokollierung ein anderes Logging Framework ein (SLF4j + Logback).
Des Weiteren sind von der Sicherheitslücke auch nicht betroffen:
- der in i‑effect® in Verbindung mit Modul *WEBCONTRL eingesetzte "Apache Tomcat" Server
- die Dateien "log4j-over-slf4j.jar", "log4j-to-slf4j.jar" und "log4j-api.jar"
Log4j 1.x in älterer Version von i‑effect® (i-effect 2.7.62 in Verbindung *ZUGFERD)
In älteren Versionen von i‑effect® und in einigen wenigen Versionen innerhalb der Version 2.7 wurde die Version Log4j 1.2 über eine kurze Zeit durch das ZUGFeRD-Modul eingesetzt. Die Versionen 1.x von LOG4j sind allerdings nicht von der aktuellen Sicherheitslücke CVE-2021-44228 betroffen, da diese keine Lookups beinhalten.
Für die Version 1.2 gibt es eine andere Sicherheitslücke (CVE-2021-4104), bei der ein Angreifer in Kombination mit einer Einstellung durch die Veränderung der Log4-Konfiguration einen ähnlichen Angriff durchführen könnte. Laut BSI ist die Ausnutzung nur in Verbindung mit einer schadhaften Programmkonfiguration möglich und daher eher unwahrscheinlich.
“The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.”
Perspektivisch sollten Anwender:innen mit der i‑effect® Version 2.7.62 und dem *ZUGFERD-Modul, um die im ZUGFeRD veraltete Version von LOG4j 1.2 zu aktualisieren auf eine aktuelle i‑effect® Version upgraden.
Was Sie trotzdem prüfen sollten!
Betroffen sein könnten aktive Nutzer des *SOA Moduls oder andere individueller Entwicklungen. Bitte kommen Sie in diesem Fall zwecks weiterer Überprüfung in jedem Fall auf uns zu.
Auch wenn Ihre i‑effect® Version >= 2.8 ist, könnten sich im IFS noch Verzeichnisse und Dateien vorheriger Versionen wie 2.6, 2.7 usw. befinden. Sollte sich darin die betroffene Log4j-Datei/Version "log4j-core-*.jar" befinden, so hat diese keine Auswirkung, da diese Dateien von den neueren i‑effect® Version nicht verwendet werden. Sie können diese JAR-Dateien problemlos löschen.
Quellen:
https://www.kb.cert.org/vuls/id/930724
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549177-1032.pdf?__blob=publicationFile&v=3
http://slf4j.org/log4shell.html
https://cert.uni-stuttgart.de/log4j/