Non è solo perché lo dicono tutti (ne parla ad esempio TheNewStack), ma chiunque abbia a che fare con applicazioni web su Java lo ha già capito: Log4Shell, la vulnerabilità 0-day della componente Java log4j, costituirà una spina nel fianco per molto, molto tempo.

Non è certamente niente di banale, lo abbiamo già detto, in una scala da 0.1 a 10 il National Vulnerability Database (NVD) la classifica 10.0 CVSSv3, la peggiore possibile. In un modo o nell’altro infatti tutti ne sono coinvolti. A rendere peggiori le cose è quanto sta “sotto al cofano”, infatti sebbene esistano già le patch correttive ed i pacchetti che le contengono (un esempio a caso, il pacchetto liblog4j2-java di Ubuntu) il problema è esteso anche a tutte quelle applicazioni che includono la libreria nei loro rilasci, tipicamente quindi i file war o jar utilizzati in autonomia dai processi Java o mediante Application Server.

In questo senso esistono tool per rilevare le anomalie (citiamo log4j-scan, ma ce ne sono a disposizione numerosi), ma il problema di questi è che bisogna conoscere con esattezza la chiamata da fare, non basta passare semplicemente una url per avere la certezza del rilevamento di un sistema vulnerabile: se infatti il contesto servito è sotto path, allora bisognerà chiamare logicamente il path corretto.

Pertanto potrebbe essere utile un approccio più a basso livello, andando a cercare all’interno del sistema se esistono le librerie incriminate, o se sono contenute nei war e nei jar installati. Certo non ottimale, ma comunque efficace.

E vale la pena ricordare come sebbene la versione di log4j che corregge il bug sia stata indicata inizialmente come la 2.15, è in realtà con la 2.16 che il problema è stato realmente risolto:

La sostanza però rimane quella: le applicazioni vanno patchate. Tutte, tanto il programma casalingo, quanto quello enterprise. E se volete farvi un’idea di quali software mainstream sono affetti date un’occhiata a questa tabella pubblicata da devclass.com:

Tool/Product family	Is it affected?	Is there a fix available?
Puppet	Continuous Delivery for Puppet Enterprise is affected	44228 fix available
Jenkins	Jenkins Core is not affected, preliminary list of affected plugins is available	–
GitLab	No	44228 fix available
GitHub	GitHub Enterprise Server is affected	44228 fix available
JetBrains	Hub, YouTrack Standalone, YouTrack InCloud, Code with me, JetBrains Account, Floating license server, and Upsource are affected	44228 fixes are available, though additional steps need to be taken
Eclipse	Passage project and Eclipse IDE for RCP and RAP Developers which contain Passage are affected	workarounds
Spring Boot	Depending on set logging system	fix will be part of Dec 23 update
Docker	No (a list of official images that might be affected along with mitigation help is available in the announcement blog)	–
Kubernetes	No	–
Red Hat	Red Hat CodeReady Studio 12, Red Hat OpenStack Platform 13, Red Hat Integration Camel K, Red Hat Integration Camel Quarkus, Red Hat OpenShift Application Runtimes Vert.X 4, Red Hat Fuse 7, Red Hat OpenShift 4, Red Hat OpenShift 3.11, Red Hat OpenShift Logging, Red Hat Data Grid 8, and Red Hat AMQ Streaming are affected	depending on project, mostly not
Databricks	No (recommended mitigation steps for customer code are available)	–
VMware	Large parts of the portfolio are affected	patches are currently pending but some workarounds are available
Elastic	Older versions of Elasticsearch, APM Java Agent depending on configuration, and Logstash are affected	44228 fixes and mitigation tips are available
HashiCorp	No	–
Apache Software Foundation	Apache Archiva,Calcite Avatica, Druid, EventMesh, Flink, Fortress, Geode, Hive, Jena, JMeter, JSPWiki, Log4j 2.x, OFBiz, Ozone, SkyWalking, Solr, Struts, and TrafficControl are affected	depending on project

Come è facile capire, non c’è (e non ci sarà nel breve) pace per nessuno, è perciò normale quindi discutere se questa ennesima problematica sia stata causata dall’open-source (“Open Source” is broken) oppure se sia l’open-source invece una vittima (“Open Source” is not broken).

C’è poi una chicca estremamente interessante in merito a questa vulnerabilità, ed è la presentazione di una tecnica di injection mediante JNDI (quindi esattamente la tecnica di Log4Shell) fatta durante un evento Black Hat del 2016:

from @BlackHatEvents USA 2016:

A Journey From #JNDI/LDAP Manipulation to Remote Code Execution Dream Land by @pwntester and @olekmiroshhttps://t.co/LbI7BTodtE

now the exploit vector presented in 2016 is the #log4jRCE.

attached slide #11 from the presentation below. 🙂 pic.twitter.com/CZA9W7ZatD

— an0n (@an0n_r0) December 11, 2021

Quindi sì, 5 anni fa la vulnerabilità in questione era già stata ampiamente illustrata e condivisa.

Cosa è successo nel frattempo?

In conclusione, siamo sopravvissuti fino ad oggi a Shellshock, Heartbleed ed a tante altre situazioni critiche, sopravviveremo anche a questa. Anzi, date un’occhiata a https://log4jmemes.com/ la raccolta di tutti i meme (alcuni dei quali sono stati usati in questo articolo) sul tema, riderci sopra è sempre la cosa migliore: