Nødpatchen til den berygtede sårbarhed i Java-biblioteket Log4j er ikke idiotsikker. Apache Software Foundation udgiver en ny version for at rette op på sårbarheden én gang for alle.
En sårbarhed i et vildt populært bibliotek for Java ryster det globale it-landskab. Det vurderes, at biblioteket findes i de fleste virksomhedsmiljøer.
Log4j bruges hovedsageligt til logning. Begivenheder i ansøgninger kan registreres med noter. Tænk på en udskrift af loginoplysningerne efter et loginforsøg. Eller, i tilfælde af en webapplikation i Java, navnet på den browser, som en bruger forsøger at oprette forbindelse til.
Sidstnævnte eksempler er almindelige. I begge tilfælde påvirker en ekstern bruger den log, som Log4j udsender. Det er muligt at misbruge den indflydelse. Logfilerne for enhver Log4j-version mellem 13. september 2013 og 5. december 2021 er i stand til at instruere Java-applikationer til at køre koden fra en ekstern server på en lokal enhed.
Siden 2013 har Log4j behandlet en API: JNDI eller Java Naming and Directory Interface. Tilføjelsen af JNDI gør det muligt for en Java-applikation at køre kode fra en ekstern server på en lokal enhed. Programmører instruerer ved at tilføje en enkelt linje med detaljer om fjernserveren i en applikation.
Problemet er, at ikke kun programmører er i stand til at tilføje reglen til applikationer. Antag, at Log4j logger brugernavnene på loginforsøg. Når nogen indtaster den førnævnte linje i brugernavnsfeltet, kører Log4j linjen, og Java-applikationen fortolker en kommando om at køre koden på den angivne server. Det samme gælder tilfælde, hvor Log4j logger en HTTPS-anmodning. Hvis du ændrer et browsernavn til linjen, kører Log4j linjen og instruerer den indirekte i at køre kode som ønsket.
Nødplaster kan også være usikkert
Den 9. december kom sårbarheden frem i stor skala. Apache Software Foundation, udvikler af Log4j, udgav en nødpatch (2.15) for at rette op på sårbarheden. Siden da har det været en topprioritet for softwareleverandører at behandle version 2.15 og levere en patch til organisationer.
Sikkerhedsorganisationen LunaSec oplyser dog, at plastret ikke er helt vandtæt. Det er fortsat muligt at justere en indstilling og få udført loggede JNDI-kommandoer.
Bemærk venligst: den relevante indstilling skal justeres manuelt, så uændrede varianter af 2.15 er sikre. Ikke desto mindre anbefaler Luna Sec, at leverandører og organisationer opdaterer til Log4j 2.16. 2.16 blev udgivet af Apache Software Foundation som svar på LunaSec. Den nye version fjerner fuldstændig den sårbare indstilling, hvilket gør det umuligt at skabe betingelserne for misbrug.