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:
— an0n (@an0n_r0) December 11, 2021
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
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:
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Lascia un commento