Nödpatchen för den ökända sårbarheten i Java-biblioteket Log4j är inte idiotsäker. Apache Software Foundation släpper en ny version för att åtgärda sårbarheten en gång för alla.
En sårbarhet i ett mycket populärt bibliotek för Java skakar det globala IT-landskapet. Det uppskattas att biblioteket finns i de flesta företagsmiljöer.
Log4j används främst för loggning. Händelser i ansökningar kan registreras med anteckningar. Tänk på en utskrift av inloggningsuppgifterna efter ett inloggningsförsök. Eller, i fallet med en webbapplikation i Java, namnet på webbläsaren som en användare försöker ansluta till.
De senare exemplen är vanliga. I båda fallen påverkar en extern användare loggen som Log4j matar ut. Det är möjligt att missbruka det inflytandet. Loggarna för alla Log4j-versioner mellan 13 september 2013 och 5 december 2021 kan instruera Java-applikationer att köra koden från en fjärrserver på en lokal enhet.
Sedan 2013 har Log4j bearbetat ett API: JNDI, eller Java Naming and Directory Interface. Tillägget av JNDI tillåter en Java-applikation att köra kod från en fjärrserver på en lokal enhet. Programmerare instruerar genom att lägga till en enda rad med detaljer om fjärrservern i en applikation.
Problemet är att inte bara programmerare kan lägga till regeln i applikationer. Anta att Log4j loggar användarnamnen för inloggningsförsök. När någon skriver in ovannämnda rad i användarnamnsfältet kör Log4j raden och Java-applikationen tolkar ett kommando för att köra koden på den angivna servern. Detsamma gäller fall där Log4j loggar en HTTPS-förfrågan. Om du ändrar ett webbläsarnamn till raden, kör Log4j raden och indirekt instruerar den att köra kod som önskat.
Nödlapp kan också vara osäker
Den 9 december uppdagades sårbarheten i stor skala. Apache Software Foundation, utvecklare av Log4j, släppte en nödpatch (2.15) för att åtgärda sårbarheten. Sedan dess har det varit en högsta prioritet för programvaruleverantörer att bearbeta version 2.15 och tillhandahålla en patch för organisationer.
Säkerhetsorganisationen LunaSec uppger dock att plåstret inte är helt vattentätt. Det är fortfarande möjligt att justera en inställning och att få loggade JNDI-kommandon exekverade.
Observera: den relevanta inställningen måste justeras manuellt, så att omodifierade varianter av 2.15 verkligen är säkra. Trots det rekommenderar Luna Sec att leverantörer och organisationer uppdaterar till Log4j 2.16. 2.16 publicerades av Apache Software Foundation som svar på LunaSec. Den nya versionen tar helt bort den sårbara miljön, vilket gör det omöjligt att skapa förutsättningar för missbruk.