Apache Foundation ruller ut den fjerde Log4j-oppdateringen på en måned, som fikser flere potensielle sikkerhetssårbarheter.
Tidligere denne måneden, en sikkerhetssårbarhet oppdaget i den populære Java-baserte loggingspakken "Log4j" ble et massivt problem for utallige selskaper og teknologiske produkter. Minecraft, Steam, Apple iCloud og andre applikasjoner og tjenester måtte forhaste oppdateringer med en lappet versjon, men Log4js problemer er ikke helt fikset ennå. Nå ruller enda en oppdatering ut, som tar sikte på å fikse et annet potensielt sikkerhetsproblem.
Apache Software Foundation utgitt versjon 2.17.1 av Log4j på mandag (via Blødende datamaskin), som først og fremst adresserer en sikkerhetsfeil merket som CVE-2021-44832. Sikkerhetsproblemet kan potensielt tillate ekstern kjøring av kode (RCE) ved å bruke JDBC Appender hvis angriperen er i stand til å kontrollere Log4j-loggingskonfigurasjonsfilen. Problemet har fått en "Moderat" alvorlighetsgrad, lavere enn sårbarheten som startet det hele --
CVE-2021-44228, som er vurdert som "Kritisk". Checkmarx sikkerhetsforsker Yaniv Nizry krevde æren for å oppdage sårbarheten og rapportere det til Apache Software Foundation.Apache skrev i sårbarhetsbeskrivelsen, "Apache Log4j2 versjoner 2.0-beta7 til og med 2.17.0 (unntatt sikkerhetsreparasjoner 2.3.2 og 2.12.4) er sårbare for et eksternt kjøring av kode (RCE) angrep der en angriper med tillatelse til å endre loggingskonfigurasjonsfilen kan konstruere en ondsinnet konfigurasjon ved å bruke en JDBC Appender med en datakilde som refererer til en JNDI URI som kan kjøre eksternt kode. Dette problemet løses ved å begrense JNDI-datakildenavn til java-protokollen i Log4j2 versjoner 2.17.1, 2.12.4 og 2.3.2."
Den originale Log4j-utnyttelsen, som også er kjent som "Log4Shell", tillot ondsinnet kode å bli utført på mange servere eller applikasjoner som brukte Log4j for datalogging. Cloudflare-sjef Matthew Prince sa at utnyttelsen ble brukt allerede 1. desember, over en uke før den ble offentlig identifisert, og i følge Washington Post, Google ga over 500 ingeniører i oppgave å lese gjennom selskapets kode for å sikre at ingenting var sårbart. Denne sårbarheten er ikke på langt nær så alvorlig, siden en angriper fortsatt må kunne endre en konfigurasjonsfil som tilhører Log4j. Hvis de kan gjøre det, er det sannsynlig at du har større problemer på hendene uansett.
Denne siste utgivelsen forventes å være den endelige permanente løsningen for den originale utnyttelsen, som mange selskaper allerede har fikset på egen hånd. Vi har imidlertid også sett en rekke andre oppdateringer siden den første for å lukke smutthull som senere ble oppdaget. Med litt flaks bør dette endelig være slutten på Log4Shell-sagaen.