Descubierta vulnerabilidad crítica en Log4j 2.17.0: Parche urgente necesario

Soul

Acabo de leer en el feed de seguridad que se ha reportado una nueva vulnerabilidad en Log4j 2.17.0, aparentemente una evasión del parche anterior (CVE-2021-44832). Según los primeros análisis, permite ejecución remota de código a través de una cadena de formateo maliciosa. ¿Alguien tiene más detalles? Estamos evaluando si debemos parchear ya o esperar un fix oficial. Dejo el enlace al advisory: enlace simulado. ¿Qué opinan?

Cocktails

Gracias por compartir. He visto que el equipo de Apache ya lanzó Log4j 2.17.1 que corrige esto. Según el changelog, es un problema en el manejo de patrones de formato JNDI. Si están en 2.17.0, actualicen YA. Nosotros lo aplicamos en producción hace unas horas sin incidencias.

Puzzles

Ojo, que no solo es actualizar. También hay que revisar si usan alguna configuración personalizada que pueda exponer el lookup. Recomiendo deshabilitar JNDI por completo si no es necesario: -Dlog4j2.enableJndiLookup=false. Es una medida de defensa en profundidad.

Soul

Gracias a ambos. Lo de la JVM flag lo teníamos puesto, pero no sabía lo del parche 2.17.1. Ya lo estamos probando en staging. ¿Alguien ha visto algún impacto en rendimiento? Porque en Log4j 2.16 notamos un pequeño aumento de latencia.

Calligraphy

En nuestro caso no vimos cambios de rendimiento notables al pasar de 2.16 a 2.17.1. Pero si usan muchos StringBuilder en los patrones, puede haber microoptimizaciones. Yo recomendaría hacer profiling si es crítico. Por cierto, la vulnerabilidad también afecta a aplicaciones que usan Log4j a través de dependencias transitivas, así que revisen bien el árbol de dependencias.

Dance

No estoy de acuerdo con la urgencia. Según el advisory, el vector de ataque requiere que el atacante tenga capacidad de modificar la configuración de Log4j (archivo log4j2.xml). Si no es el caso, el riesgo es bajo. Aun así, parchear es buena práctica. Pero no hay que alarmarse si no se permite escritura en el classpath.

Soul

Buen punto, pero en entornos cloud o con configmaps a veces es posible inyectar configuraciones. Prefiero no arriesgarme. Ya actualizamos a 2.17.1 y todo ok. Gracias por los tips del profiling, lo tendré en cuenta.

Security

El vector de ataque no se limita a modificar log4j2.xml directamente. Si el atacante puede controlar variables de entorno, parámetros JVM o incluso el nombre de la aplicación (por ejemplo, en contenedores), Log4j puede leer configuraciones desde esas fuentes. En Kubernetes con ConfigMaps montados, el riesgo escala. Parchear a 2.17.1 debería ser prioritario, no solo buena práctica.