Slik finner du ut om du er rammet av sårbarheten i log4j, og slik fikser du det

Først må vi finne ut om vi har noen log4j-core i classpathen:

1$ mvn dependency:list | grep log4j
2[INFO] org.apache.logging.log4j:log4j-core:jar:2.14.1:compile
3[INFO] org.apache.logging.log4j:log4j-api:jar:2.14.1:compile

Her ser vi at vi har log4j-core 2.14.1, som er sårbar (du må opp på 2.16.0 for å være trygg). Merk at det er log4j-core som inneholder sårbarheten, ikke log4j-api

Da har vi tre muligheter:

1. Oppgradere log4j
2. Erstatte log4j med slf4j eller noe annet
3. Minimere risiko for misbruk på gjeldende versjon

Oppgradere log4j

Dersom du vil oppgradere må du legge inn en dependency på log4j 2.16.0:

1<dependency>
2    <groupId>org.apache.logging.log4j</groupId>
3    <artifactId>log4j-core</artifactId>
4    <version>2.16.0</version>
5</dependency>
6<dependency>
7    <groupId>org.apache.logging.log4j</groupId>
8    <artifactId>log4j-api</artifactId>
9    <version>2.16.0</version>
10</dependency>
11

Erstatte log4j med slf4j

Dersom du vil erstatte log4j med slf4j må du fjerne log4j-core fra pom.xml. Dersom du ikke har en direkte avhengighet til log4j må du finne ut hvem som drar den inn transitivt. Bruk mvn dependency:tree og finn ut hvilket bibliotek du er avhengig av, og legg inn en exclusion i pom-en:

1<dependency>
2    <groupId>no.kantega</groupId>
3    <artifactId>misbehaving-library</artifact>
4    <version>1.0-SNAPSHOT</version>
5    <exclusions>
6        <exclusion>
7            <groupId>org.apache.logging.log4j</groupId>
8            <artifactId>log4j-core</artifactId>
9        </exclusion>
10    </exclusions>
11</dependency> 

Deretter kan du få alle som bruker log4j-api til å logge til slf4j/logback ved å legge inn følgende avhengigheter:

1<dependency> 
2    <groupId>org.apache.logging.log4j</groupId> 
3    <artifactId>log4j-to-slf4j</artifactId> 
4    <version>2.16.0</version> 
5</dependency> 
6<dependency> 
7    <groupId>org.slf4j</groupId> 
8    <artifactId>slf4j-api</artifactId> 
9    <version>1.7.32</version> 
10</dependency> 
11<dependency> 
12    <groupId>ch.qos.logback</groupId> 
13    <artifactId>logback-classic</artifactId> 
14    <version>1.2.8</version> 
15</dependency> 

Selv om du har kode som bruker log4j-api vil nå logback bli brukt.

1 public class LogTest { 
2     @Test 
3     void name() { 
4         org.apache.logging.log4j.Logger logger = LogManager.getLogger(); 
5         logger.error("nå går dette via slf4j og logback"); 
6     } 
7} 

Minimere risiko for misbruk på gjeldende versjon

Dersom du ikke har mulighet til å oppgradere log4j, finnes det noen tiltak du kan gjøre for å minimere risikoen for misbruk. De første tiltakene som ble anbefalt har vist seg ikke å dekke alle misbruksscenarier likevel, men det er kommet nye anbefalinger.

Den tydeligste og enkleste anbefalingen er å fjerne JndiLookup.class fra log4j-core.jar. Det gjør du ved å lokalisere log4j-core.jar på classpathen og slette den aktuelle klassefilen. Etterpå må du selvsagt restarte tjenesten din.

$ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Velger du denne løsningen må du sørge for at det ikke blir lagt ut ny versjon av log4j-core.jar ved oppgraderinger av tjenesten din.

Anbefalingene utvikler seg fra dag til dag, så vi anbefaler at du går rett til kilden dersom du ikke kan oppgradere eller bytte ut log4j: https://logging.apache.org/log4j/2.x/security.html

Sårbarheten ble oppdaget av LunaSec. De vedlikeholder en detaljert guide med kompenserende tiltak for sårbarheten.