Apache Foundation lanserar den fjärde Log4j-uppdateringen på en månad, som åtgärdar fler potentiella säkerhetsbrister.
Tidigare den här månaden, en säkerhetssårbarhet upptäckt i det populära Java-baserade loggningspaketet "Log4j" blev ett enormt problem för otaliga företag och tekniska produkter. Minecraft, Steam, Apple iCloud och andra applikationer och tjänster var tvungna att skynda på uppdateringar med en korrigerad version, men Log4js problem har inte åtgärdats helt än. Nu rullar ännu en uppdatering ut, som syftar till att fixa ytterligare ett potentiellt säkerhetsproblem.
Apache Software Foundation släpptes version 2.17.1 av Log4j på måndag (via Pipande dator), som i första hand åtgärdar ett säkerhetsfel märkt som CVE-2021-44832. Sårbarheten kan potentiellt tillåta fjärrkörning av kod (RCE) med JDBC Appender om angriparen kan kontrollera Log4j-loggningskonfigurationsfilen. Problemet har fått en "måttlig" allvarlighetsgrad, lägre än sårbarheten som startade det hela -- CVE-2021-44228
Apache skrev i sårbarhetsbeskrivningen, "Apache Log4j2 versioner 2.0-beta7 till och med 2.17.0 (exklusive säkerhetsfixutgåvorna 2.3.2 och 2.12.4) är sårbara för en fjärrkörningsangrepp (RCE) där en angripare med behörighet att ändra loggningskonfigurationsfilen kan konstruera en skadlig konfiguration med hjälp av en JDBC Appender med en datakälla som refererar till en JNDI URI som kan exekvera på distans koda. Det här problemet åtgärdas genom att begränsa JNDI-datakällans namn till java-protokollet i Log4j2 versionerna 2.17.1, 2.12.4 och 2.3.2."
Den ursprungliga Log4j-exploateringen, som också är känd som "Log4Shell", gjorde att skadlig kod kunde köras på många servrar eller applikationer som använde Log4j för dataloggning. Cloudflares vd Matthew Prince sa att utnyttjandet användes redan den 1 december, över en vecka innan det identifierades offentligt, och enligt Washington Post, Google gav över 500 ingenjörer i uppdrag att läsa igenom företagets kod för att säkerställa att ingenting var sårbart. Denna sårbarhet är inte i närheten av lika allvarlig, eftersom en angripare fortfarande måste kunna ändra en konfigurationsfil som tillhör Log4j. Om de kan göra det är det troligt att du har större problem på dina händer ändå.
Den här senaste utgåvan förväntas vara den sista permanenta fixen för den ursprungliga exploateringen, som många företag redan fixat på egen hand. Men vi har också sett ett antal andra uppdateringar sedan den första för att stänga kryphål som senare upptäcktes. Med lite tur borde detta äntligen vara slutet på Log4Shell-sagan.