Era il Dicembre 2021 quando la libreria log4j ha regalato emozioni forti a chiunque lavorasse nel settore IT con una vulnerabilità che è finita su tutte le news.

Dopo quell’evento, che ha scosso le infrastrutture ovunque nel mondo, Amazon ci ha messo una pezza rilasciando una hot patch che risolveva il problema log4shell. La questione sembrava finita lì se non fosse che, da quell’hot patch, sono poi risultate altre nuove vulnerabilità che permettevano una container escape e consentivano di diventare root sull’host. Le nuove vulnerabilità in questione sono trackate come CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 e CVE-2022-0071, con severità 8.8 su 10.

Tutto ciò non dovrebbe sorprendere se si pensa per un attimo a quanto complesso e interdipendente sia diventato il mondo degli applicativi software odierni, che includono anche una quantità di linee di codice che non hanno precedenti.

A scoprire la vulnerabilità sono stati i ricercatori di Unit 42 i quali rilevano che le hot fix utilizzate cerchino i processi Java da patchare al volo senza assicurarsi che il processo da patchare giri con le restrizioni imposte dal container, quindi un container malevolo potrebbe includere un binario chiamato ‘java’ per ingannare il codice della hot patch e far si che tale binario venga invocato con privilegi elevati.

Da ‘privilegi elevati’ sarebbe poi possibile ottenere una container escape e eventualmente una privilege escalation completa anche sull’host. Secondo i ricercatori di Palo Alto Networks poco sopra linkati, sono affetti da tale problema anche i container non privilegiati e quelli che contengono distribuzioni AWS già hardenizzate.

Una proof of concept è illustrata su Youtube, anche se il codice completo non è stato pubblicato. I ricercatori di cui sopra sono al corrente di tale problema già da 6 giorni dopo la release dell’hot patch problematico da parte di AWS, quindi già da Dicembre dello scorso anno, e ne hanno fatto una responsible disclosure per permettere ad Amazon di risolvere il problema.

Già dal 23 Dicembre 2021 è stata testata una prima fix che si è però rivelata insufficiente e i lavori sono proseguiti, col continuo feedback dei ricercatori di Unit 42, fino alla patch finale rilasciata il 19 Aprile 2022.

Come applicare la hot patch:

• Gli utenti Kubernetes possono deployare l’ultima versione di Daemonset, che non tocca la patch log4shell
• Gli utenti Hotdog possono semplicemente aggiornare all’ultima versione disponibile
• Gli utenti standalone possono fixare con uno dei seguenti update, rispettivamente per .rpm e .deb:
  • yum update log4j-cve-2021-44228-hotpatch
  • apt install --only-upgrade log4j-cve-2021-44228-hotpatch

Tutto risolto quindi, o almeno si spera.

John Toscano

Appassionato di Linux e della cultura open-source da vent’anni, continuo a fare del mio meglio per diffondere tale filosofia e soprattutto condividere la conoscenza.

C’è sempre qualcuno da qualche parte nel mondo che sta avendo un problema che tu hai già risolto e, condividendo la soluzione, puoi fare la differenza.

Se quel qualcuno sei tu, chiedi pure alla community. La trovi ovunque, ad esempio su reddit.com/r/italyinformatica, reddit.com/r/fedora, reddit.com/r/debian, reddit.com/r/ubuntu, reddit.com/r/archlinux, reddit.com/r/linux, sui forum specifici delle distro oppure sulle loro wiki.

Perchè nessun problema andrebbe risolto più di una volta.

[https://it.linkedin.com/in/john-toscano]