La vulnerabilità di container-escape introdotta dalla fix di log4shell è stata sistemata in AWS
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-hotpatchapt install --only-upgrade log4j-cve-2021-44228-hotpatch
Tutto risolto quindi, o almeno si spera.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
