El pegat d'emergència per a la infame vulnerabilitat de la biblioteca de Java Log4j no és infal·lible. L'Apache Software Foundation està llançant una nova versió per solucionar la vulnerabilitat d'una vegada per totes.
Una vulnerabilitat d'una biblioteca molt popular per a Java està sacsejant el panorama informàtic global. S'estima que la biblioteca existeix a la majoria d'entorns corporatius.
Log4j s'utilitza principalment per al registre. Els esdeveniments a les aplicacions es poden registrar amb notes. Penseu en una impressió de les dades d'inici de sessió després d'un intent d'inici de sessió. O, en el cas d'una aplicació web en Java, el nom del navegador al qual s'està intentant connectar un usuari.
Aquests últims exemples són habituals. En ambdós casos, un usuari extern influeix en el registre que genera Log4j. És possible abusar d'aquesta influència. Els registres de qualsevol versió de Log4j entre el 13 de setembre de 2013 i el 5 de desembre de 2021 poden indicar a les aplicacions Java que executin el codi des d'un servidor remot en un dispositiu local.
Des del 2013, Log4j està processant una API: JNDI, o Java Naming and Directory Interface. L'addició de JNDI permet que una aplicació Java executi codi des d'un servidor remot en un dispositiu local. Els programadors donen instruccions afegint una única línia de detalls sobre el servidor remot en una aplicació.
El problema és que no només els programadors són capaços d'afegir la regla a les aplicacions. Suposem que Log4j registra els noms d'usuari dels intents d'inici de sessió. Quan algú introdueix la línia esmentada al camp del nom d'usuari, Log4j executa la línia i l'aplicació Java interpreta una ordre per executar el codi al servidor especificat. El mateix passa amb els casos en què Log4j registra una sol·licitud HTTPS. Si canvieu el nom d'un navegador per la línia, Log4j executa la línia, indicant-li indirectament que executi el codi com vulgueu.
El pegat d'emergència també pot ser insegur
El 9 de desembre, la vulnerabilitat va sortir a la llum a gran escala. L'Apache Software Foundation, desenvolupador de Log4j, va llançar un pedaç d'emergència (2.15) per solucionar la vulnerabilitat. Des de llavors, ha estat una prioritat per als venedors de programari processar la versió 2.15 i proporcionar un pedaç per a les organitzacions.
Tanmateix, l'organització de seguretat LunaSec afirma que el pegat no és completament estanc. Encara és possible ajustar una configuració i executar les ordres JNDI registrades.
Tingueu en compte: la configuració corresponent s'ha d'ajustar manualment, de manera que les variants no modificades de 2.15 siguin segures. No obstant això, Luna Sec recomana que els proveïdors i les organitzacions actualitzin a Log4j 2.16. 2.16 va ser publicat per Apache Software Foundation en resposta a LunaSec. La nova versió elimina completament la configuració vulnerable, cosa que fa impossible crear les condicions per a l'abús.