Her er en kort oppskrift på hvordan du finner ut om prosjektet ditt er rammet av log4shell og hvordan du fjerner sårbarheten.

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

$ mvn dependency:list | grep log4j
[INFO] org.apache.logging.log4j:log4j-core:jar:2.14.1:compile
[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

Apache Log4j-hullet skaper problemer også for norske utviklere

mandag 13. desember 2021

Da har vi tre muligheter:

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

#1: Oppgradere log4j

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

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.16.0</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.16.0</version>
</dependency>

#2: 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:

<dependency>
    <groupId>no.kantega</groupId>
    <artifactId>misbehaving-library</artifact>
    <version>1.0-SNAPSHOT</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
        </exclusion>
    </exclusions>
</dependency> 

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

<dependency> 
    <groupId>org.apache.logging.log4j</groupId> 
    <artifactId>log4j-to-slf4j</artifactId> 
    <version>2.16.0</version> 
</dependency> 
<dependency> 
    <groupId>org.slf4j</groupId> 
    <artifactId>slf4j-api</artifactId> 
    <version>1.7.32</version> 
</dependency> 
<dependency> 
    <groupId>ch.qos.logback</groupId> 
    <artifactId>logback-classic</artifactId> 
    <version>1.2.8</version> 
</dependency> 

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

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

#3: 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.

Dette kan vi lære av Log4j-hullet: - Beste måten å få til robust kode, er å lage enkel kode

tirsdag 14. desember 2021