De Apache Software Foundation heeft een nieuwe versie van log4j2 uitgerold waarin JNDI standaard staat uitgeschakeld en de ondersteuning van Message Lookups volledig is verwijderd. Log4j2 is een populaire logging-library die door een groot aantal Java-applicaties wordt gebruikt.
Log4j kan verschillende soorten lookups uitvoeren, onder andere via de Java Naming and Directory Interface (JNDI) API. Via deze Java-API is het mogelijk voor een Java-applicatie om data en resources op te vragen in de vorm van Java-objecten. In het geval van Log4j gebruikt de library de JNDI-API om via een serviceprovider, zoals LDAP (Lightweight Directory Access Protocol), informatie op te vragen die wordt gelogd.
De kritieke kwetsbaarheid in Log4j, die de afgelopen dagen uitgebreid in het nieuws is geweest, zorgt ervoor dat het mogelijk is voor een aanvaller om Log4j, via de JNDI, een kwaadaardig Java-object vanaf bijvoorbeeld een LDAP-server te laten downloaden dat vervolgens op de aangevallen applicatie- of loggingserver wordt uitgevoerd. Daarmee kan een aanvaller de server compromitteren.
"De meeste mensen geven log4j de schuld dat het JNDI in de eerste plaats had toegevoegd en/of leggen de schuld bij een gebrek aan support voor het project waardoor dergelijk gevaarlijk gedrag zo eenvoudig toegankelijk was", zegt onderzoeker Jeff Dileo van securitybedrijf NCC Group. Hij denkt dat een van de ontwikkelaars ooit heeft besloten om JNDI als "enterprise" feature toe te voegen.
In log4j2 versie 2.16.0 staat JNDI standaard uitgeschakeld en is de support voor lookups in messages volledig verwijderd. Daarmee wordt voorkomen dat een aanvaller log4j de opdracht kan geven om via de JNDI malafide code te laden en uit te voeren.
Deze posting is gelocked. Reageren is niet meer mogelijk.