RHSB-2021-009 Log4Shell - Esecuzione di codice remoto - log4j (CVE-2021-44228)
Riassunto esecutivo
Apache Log4j è una libreria per la funzionalità di log in applicazioni basate su Java.
È stato trovato un difetto in Apache Log4j v2 (un aggiornamento di Log4j), che consente a un aggressore remoto di eseguire codice sul server se il sistema registra un valore di stringa controllato dall'aggressore con il lookup del server Java Naming and Directory Interface™ (JNDI) Lightweight Directory Access Protocol (LDAP). Questo difetto permette ad un attaccante remoto di eseguire codice sul sistema di destinazione con gli stessi privilegi dell'applicazione basata su Java che ha invocato Apache Log4j v2.
Questo problema è stato assegnato a CVE-2021-44228 e valutato con un impatto di gravità di Critical.
I seguenti prodotti NON sono interessati da questo difetto e sono stati esplicitamente elencati qui a beneficio dei nostri clienti.
Red Hat Enterprise Linux
Gestione avanzata del cluster di Red Hat per Kubernetes
Red Hat Advanced Cluster Security per Kubernetes
Red Hat Ansible Automation Platform (motore e torre)
Sistema di certificati Red Hat
Red Hat Directory Server
Gestione dell'identità di Red Hat
Red Hat CloudForms
Infrastruttura di aggiornamento di Red Hat
Red Hat Satellite
Red Hat Ceph Storage
Red Hat Gluster Storage
Red Hat OpenShift Data Foundation
Piattaforma Red Hat OpenStack
Virtualizzazione di Red Hat
Red Hat Single Sign-On
Riassunto tecnico
Una falla è stata trovata nella libreria di logging Java Apache Log4j nelle versioni dalla 2.0.0 e prima della 2.15.0. Un attaccante remoto che può controllare i messaggi di log o i parametri dei messaggi di log può eseguire codice arbitrario sul server attraverso l'endpoint LDAP JNDI. Fate riferimento a CVE-2021-44228 per maggiori dettagli.
Mitigazione
Per le versioni 2.10 e successive di Log4j:
impostare la proprietà di sistema log4j2.formatMsgNoLookups o la variabile d'ambiente
LOG4J_FORMAT_MSG_NO_LOOKUPS
a true
Per le versioni di Log4j tra 2.7 e 2.14.1:
tutti i pattern PatternLayout possono essere modificati per specificare il convertitore di messaggi come %m{nolookups} invece che solo %m
Per le versioni di Log4j tra 2.0-beta9 e 2.10.0:
rimuovere la classe JndiLookup dal classpath. Per esempio:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Su OpenShift 4 e in OpenShift Logging, la mitigazione di cui sopra può essere applicata seguendo i passi di questo articolo: https://access.redhat.com/solutions/6578421
Su OpenShift 3.11, la mitigazione al componente Elasticsearch interessato può essere applicata seguendo i passi di questo articolo: https://access.redhat.com/solutions/6578441
Dettagli tecnici
Una falla è stata trovata nella libreria di logging Java Apache Log4j nelle versioni dalla 2.0.0 e prima della 2.15.0. Un attaccante remoto che può controllare i messaggi di log o i parametri dei messaggi di log può eseguire codice arbitrario sul server attraverso l'endpoint LDAP JNDI.
Questo problema riguarda solo le versioni di log4j tra 2.0 e 2.14.1. Per sfruttare questa falla è necessario:
Un endpoint accessibile da remoto con qualsiasi protocollo (HTTP, TCP, ecc.) che permette a un attaccante di inviare dati arbitrari,
Una dichiarazione di log nell'endpoint che registra i dati controllati dall'attaccante.
Impatto sui servizi cloud
L'impatto di CVE-2021-44228 e le relative vulnerabilità di log4j divulgate finora sono state valutate per tutti i servizi cloud. Quelli identificati come potenzialmente interessati sono stati affrontati immediatamente. L'uso della componente vulnerabile e l'esposizione potenziale variava tra i servizi. Red Hat ha applicato mitigazioni (vedi sopra), patch e, in alcuni casi, ha rimosso il componente vulnerabile per affrontare il rischio in modo tempestivo.
Red Hat continua a monitorare il potenziale impatto di queste vulnerabilità sui servizi cloud Red Hat e lavora con terze parti, se necessario, per fornire garanzie sui nostri servizi. Ulteriori comunicazioni saranno emesse come richiesto.
Aggiornamenti per i prodotti interessati
I clienti Red Hat che eseguono le versioni interessate di questi prodotti Red Hat sono fortemente raccomandati di aggiornare non appena sono disponibili gli errata. I clienti sono invitati ad applicare immediatamente gli aggiornamenti disponibili e ad attivare le mitigazioni come ritengono opportuno.
Prodotto | Componente(i) | Consulenza / Aggiornamento |
Red Hat CodeReady Studio 12 | log4j-core | |
Red Hat Enterprise Application Platform 7 | log4j-core | |
Red Hat Integration Camel K | log4j-core | |
Red Hat Integration Camel Quarkus | log4j-core | |
Red Hat OpenShift Application Runtimes Vert.X 4 | log4j-core | |
Red Hat Fuse 7 | log4j-core | |
Red Hat OpenShift 4 | alveare-contenitore presto-container logging-elasticsearch6-container | |
Red Hat OpenShift 3.11 | logging-elasticsearch5-container | |
Registrazione di Red Hat OpenShift | logging-elasticsearch6-container | |
Red Hat Data Grid 8 | log4j-core | |
Red Hat AMQ Streams | log4j-core | |
Piattaforma Red Hat OpenStack 13 | opendaylight | Fine della vita |
Red Hat Process Automation Manager | log4j-core |
[1] Il link dell'avviso/aggiornamento sarà aggiunto una volta che gli aggiornamenti saranno attivi.
Diagnosticare
È stato sviluppato uno script di rilevamento delle vulnerabilità per determinare se il tuo sistema è attualmente vulnerabile a questa falla. Per verificare l'autenticità dello script, puoi scaricare anche la firma GPG staccata. Le istruzioni su come utilizzare le firme GPG per la verifica sono disponibili sul Portale clienti.
FAQ
D: Dobbiamo riavviare un servizio o un'applicazione dopo aver applicato correzioni o mitigazioni di sicurezza? Se sì, quali?
R: Mentre è una buona pratica e raccomandato riavviare il servizio o l'applicazione, dipende dalla strategia di distribuzione dell'applicazione; per esempio:
Nelle applicazioni basate su Java, sì, i server delle applicazioni devono essere riavviati dopo aver applicato la correzione di sicurezza.
Q. Nei prodotti Red Hat OpenShift (incluso OpenShift Logging), è necessario accettare gli aggiornamenti una volta che sono disponibili?
Per saperne di più sul processo di aggiornamento di OpenShift Container Platform e OpenShift Logging, usa la seguente guida come riferimento:
D: Servizi come ARO/OSD/ROSA sono vulnerabili?
R: No, per le ragioni citate qui:
Vulnerabilità Apache log4j2 Remote Code Execution (RCE)
D: Dopo aver applicato gli aggiornamenti di Log4j v2 menzionati sopra, devo ancora aspettare il rilascio dei Security Errata in CVE-2021-45046, CVE-2021-45105 e CVE-2021-44832?
R: No, non devi aspettare i nuovi rilasci di CVE-2021-45046, CVE-2021-45105 e CVE-2021-44832. Questi CVE sono problemi di impatto di gravità MODERATA. A meno che non usiate un Pattern Layout non predefinito con un Context Lookup (per esempio, $${ctx:loginId}) nella configurazione di Log4J del vostro prodotto (che non è configurato di default e out-of-box nei prodotti Red Hat), non siete vulnerabili a questi problemi.
D: Alcuni prodotti Red Hat forniscono Log4j v1. Gli aggiornamenti menzionati in questo bollettino di sicurezza risolvono anche la vulnerabilità in Log4j v1?
R: Log4j versione 1 non è affetto da CVE-2021-44228 (Log4Shell). Per Log4j v1, c'è un problema separato CVE-2021-4104 (Log4j v1.x) e ha una valutazione di impatto di gravità moderata. Questo problema non è lo stesso di CVE-2021-44228 (Log4Shell). Log4j 1.2 è vulnerabile alla deserializzazione di dati non attendibili quando l'attaccante ha accesso in scrittura alla configurazione di Log4j o è configurato per utilizzare JMSAppender con opzioni specifiche abilitate, che non è la configurazione predefinita. Per i prodotti Red Hat che distribuiscono Log4j v1, i permessi e la configurazione predefiniti impostati su Log4j v1 mitigano contro CVE-2021-4104. Si prega di vedere la pagina CVE(CVE-2021-4104) per maggiori dettagli.
Comments