Ricorderete Log4Shell, la vulnerabilità più grave del decennio che ha spaventato molti vendor? 

Censita con CVE-2021-44228 è stata oggetto di rapide correzioni; a volte correzioni “troppo rapide”; non è un caso che il rischio si sia ripresentato in varie forme attraverso le vulnerabilità CVE-2021-45046 e CVE-2021-45105 che affrontavano differentemente le debolezze del codice Log4j. La natura del problema evidentemente era complessa e capillare nella struttura del software da creare non pochi problemi nell’individuazione delle cause e soprattutto nella costruzione di una soluzione definitiva. 

La costruzione di un correttivo “definitivo” è stato un problema per molti vendor, soprattutto per uno come Amazon che nel suo ecosistema AWS (Amazon Web Services) ha un uso intensivo delle tecnologie associate a Java e quindi a Log4j. Trovare il tempo e la struttura di una correzione completa non era evidentemente spendibile nel breve periodo, pertanto nel dicembre 2021 Amazon AWS ha rilasciato dei correttivi come soluzione a breve termine per Log4Shell, facilmente implementabili su larga scala in attesa della diponibilità di una versione correttiva più robusta: le cosiddette “hot patch”. 

Questa soluzione è tecnologicamente interessante, in quanto si tratta in effetti non di codice in sostituzione di quello “fallato”, ma di agenti Java da iniettare in un qualsiasi processo JVM in esecuzione per eseguire una correzione “al volo”, del metodo lookup() per tutte le istanze caricate della classe interessata al problema org.apache.logging.log4j.core.lookup.JndiLookup. Questa soluzione travalica la specificità dell’ecosistema in cui Java sta agendo, ed è pertanto fruibile per tutti gli utenti del mondo Java (non solo AWS), e possono essere quindi applicate ad altri ambienti cloud e on-premise. 

Questo meccanismo consente di corregge le applicazioni Java vulnerabili senza conoscerle, senza toccarle (nel senso del loro codice), ma agendo solo sul framework Log4j, modificandolo “in memoria”. 

Tutto molto bello, ma ahimè dal punto di vista di efficacia questa soluzione ha avuto i suoi guai. 

In particolare, secondo i ricercatori della Unit 42 di Palo Alto, questo meccanismo porta con sé 4 distinte problematiche di sicurezza classificabili complessivamente come “correzioni incomplete”; le quattro vulnerabilità sono state classificate con CVSS 8.8 rispettivamente con CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 e CVE-2022-0071. 

I problemi non risolti possono consentirebbero lo sfruttamento (senza privilegio) di ogni container nell’ambiente della hot patch per ottenere l’evasione dallo stesso e l’acquisizione dell’intero host (CVE-2022-0070, CVE-2022-0071). Allo stesso tempo i processi privi di privilegio potrebbero aumentarli ottenendo l’esecuzione di codice con privilegio root (CVE-2021-3100, CVE-2021-3101). Queste vulnerabilità non dipendono dalla configurazione dell’ambiente, ma dalla hot patch, e possono dunque essere sfruttate nella maggior parte degli ambienti AWS. 

Sono state prodotte correzioni a questi problemi per i seguenti ambienti specifici: Amazon Linux (AMI), Kubernetes e Bottlerocket. 

Tweet