Saturday’s Talks: Log4Shell starà con noi per molto tempo, è bene prepararsi

0

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 familyIs it affected?Is there a fix available?
PuppetContinuous Delivery for Puppet Enterprise is affected44228 fix available
JenkinsJenkins Core is not affected, preliminary list of affected plugins is available
GitLabNo44228 fix available
GitHubGitHub Enterprise Server is affected44228 fix available
JetBrainsHub, YouTrack Standalone, YouTrack InCloud, Code with me, JetBrains Account, Floating license server, and Upsource are affected44228 fixes are available, though additional steps need to be taken
EclipsePassage project and Eclipse IDE for RCP and RAP Developers which contain Passage are affectedworkarounds
Spring BootDepending on set logging systemfix will be part of Dec 23 update
DockerNo (a list of official images that might be affected along with mitigation help is available in the announcement blog)
KubernetesNo
Red HatRed 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 affecteddepending on project, mostly not
DatabricksNo (recommended mitigation steps for customer code are available)
VMwareLarge parts of the portfolio are affectedpatches are currently pending but some workarounds are available
ElasticOlder versions of Elasticsearch, APM Java Agent depending on configuration, and Logstash are affected44228 fixes and mitigation tips are available
HashiCorpNo
Apache Software FoundationApache Archiva,Calcite Avatica, Druid, EventMesh, Flink, Fortress, Geode, Hive, Jena, JMeter, JSPWiki, Log4j 2.x, OFBiz, Ozone, SkyWalking, Solr, Struts, and TrafficControl are affecteddepending 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:

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.