Monitoring Module ist nicht von kritischer log4j-Sicherheitslücke (CVE-2021-44228 „Log4Shell“) betroffen

Das Monitoring Module (HLMM) verwendet als Basis Spring Boot, welches im Standard wiederum kein log4j2 verwendet. In den ausgelieferten Libraries (exemplarisch für die Web-Application des aktuellen Releases) findet man auf dem Monitoring-Server einige JAR-Dateien, die auf log4j in einer der betroffenen Versionen hindeuten:

# locate log4j | grep jar$ | grep webapp
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-api-2.14.1.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-over-slf4j-1.7.32.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar

Hier fehlt allerdings explizit die Datei beginnend „log4j-core“, welche von den aktuellen Sicherheitsproblemen betroffen ist. Spring Boot und damit auch HLMM enthält zwar die Log4J-API, nutzt im Standard intern allerdings SLF4J/Logback.

Weiterführende Informationen dazu finden Sie auch unter dem folgenden Link:
https://github.com/spring-projects/spring-boot/issues/28958

Spring Boot does not use log4j2 by default and those of you who are opting-in for log4j2 can update to a version that fixes the problem.

Quelle

Im Kern heißt dies also: HLMM ist von dem Problem nicht betroffen und es sind keine außerplanmäßigen Patches erforderlich.

Update 15.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45046 betroffen.

Update 18.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45105 betroffen.

Weitere Informationen zu der Sicherheitslücke:

JIT-Compiler-Bug im Firefox 18 (Update)

Mozilla Firefox LogoAm 08. Januar diesen Jahres hat Mozilla den Firefox 18 veröffentlicht. Einer der wichtigsten Neuerungen ist ein neuer JIT-Compiler für JavaScript, welcher vor allem größere JavaScript-Anwendungen beschleunigen soll. Der Name des JIT-Compilers IonMonkey ist dabei eine Anlehnung an SpiderMonkey, der JavaScript-Engine von Mozilla im Firefox.

Weiterlesen

Optimierte JavaScript-Anwendungen mit erweiterten Debugging-Möglichkeiten

Es sollte mittlerweile in jeder halbwegs ernsthaften Webanwendung gängig sein, dass das JavaScript nicht as is ausgegeben wird, sondern in einer optimierten Variante. Dabei wird in der Regel auf eine Kombination aus Konkatenation und Minifizierung zurückgegriffen.

In diesem Artikel stelle ich eine Möglichkeit vor, dies in einem Java-Projekt mit Spring einzusetzen. Als Builder wird Maven und als JS-Compiler wird der Google Closure Compiler verwendet. Als Boni werden die Source Maps in der Konbination mit Google Chrome vorgestellt. Grundsätzlich sind einige Werkzeuge zum Teil auch ohne Java oder Spring einsetzbar — Google Closure Compiler ist zwar in Java geschrieben, aber als JAR verfügbar und universell per Executable steuerbar.

Weiterlesen

Verknüpfung von JIRA und Jenkins – oder: Wie erhält man gegenseitiges Feedback zwischen Ticket- und CI-System

In einer Entwicklungsumgebung entsteht schnell die Anforderung, dass man wissen will, in welcher Version nun wirklich Feature X integriert wurde oder Bug X gelöst wurde. Selbstverständlich gehört ein vernünftiges Versions- und Releasemanagement dazu, aber für die internen „Snapshot-Releases“ ist in der Regel nur die Build- und Revisionsnummer eindeutig. Folgerichtig benötigt man geeignete, automatische Workflows um sowohl zu jedem Build die betreffenden Tickets als auch bei jedem Ticket die betreffenden Builds zu ermitteln und anzuzeigen. Gleichzeitig hat dies den Nebeneffekt, dass diese Informationsverlinkung indirekt auch archiviert wird. Weiterlesen

Migration von Trac zu JIRA

Einführung von Atlassians Confluence, FishEye und JIRA

In diesem Artikel geht es um die Einführung, also Installation und Konfiguration, der Produkte JIRA, FishEye und Confluence von der Firma Atlassian in einer ursprünglich rein Trac-basierten Umgebung. Weiterlesen