Dudas sobre las mitigaciones para la vulnerabilidad de la biblioteca Log4j de Apache.

El 9 de diciembre de 2021 se reveló una vulnerabilidad crítica relacionada con la biblioteca Log4j de Apache. Aquí se detalla la vulnerabilidad. En este enlace se mencionan posibles medidas de mitigación. Espero que puedas ayudarme con las siguientes preguntas (disculpa de antemano si mis preguntas suenan demasiado triviales):

Mitigación 1: establecer la propiedad del sistema log4j2.formatMsgNoLookups o la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en true. Esto consta de 2 operaciones diferentes:

La primera consiste en establecer la propiedad del sistema log4j2.formatMsgNoLookups en TRUE. ¿Qué son y dónde se encuentran las propiedades del sistema?

O bien, establecer la variable de entorno LOG4J_Format_MSG_NO_LOOKUPS en TRUE. Aparentemente esto es tan fácil como ejecutar esto: export LOG4J_FORMAT_MSG_NO_LOOKUPS=true. ¿Hay algún problema con crear esa variable de entorno en un sistema que no utiliza la biblioteca Log4j?

Mitigación 2: todos los patrones de PatternLayout se pueden modificar para especificar el convertidor de mensajes como %m{nolookups} en lugar de solo %m. Es decir, en lugar de usar %m, debes usar %m{nolookups}, y esto se aplica en todos los patrones de PatternLayout. En este lugar se enumeran los posibles archivos de configuración de la biblioteca Log4j. Logré encontrar este archivo /usr/lib/appdynamics-php5/proxy/conf/logging/log4j2.xml, que contiene varias líneas como esta: <PatternLayout pattern="[%t] %d{DATE} %5p %c - %m%n"/>. Supongo que solo en esos archivos de configuración es donde se debe aplicar esta mitigación, y no en otros lugares, ¿correcto?

Mitigación 3: eliminar la clase JndiLookup del classpath. Por ejemplo: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. No puedo encontrar ningún archivo llamado JndiLookup.class en ninguna parte. Supongo que si no existe, no es necesario buscar nada más y esta posible mitigación no se aplica, ¿correcto?

davy.ai

July 22, 2023 at 6:42 pm

Respuestas para Mitigaciones para la vulnerabilidad de Log4j

Mitigación 1:

La propiedad del sistema log4j2.formatMsgNoLookups se utiliza para establecer el formato de los mensajes de Log4j sin incluir referencias de búsqueda de JNDI.
Las propiedades del sistema son datos de configuración que pueden ser utilizados por las aplicaciones en Java.
Estas propiedades se pueden establecer de varias maneras, incluyendo opciones de línea de comandos, archivos de propiedades del sistema Java, variables de entorno, etc.
El establecimiento de la propiedad del sistema log4j2.formatMsgNoLookups como true se puede lograr utilizando opciones de línea de comandos de Java o configurándolo programáticamente en el código de Java.
Alternativamente, otra forma mencionada en la mitigación es establecer la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS como true. Esto se puede lograr ejecutando el comando export LOG4J_FORMAT_MSG_NO_LOOKUPS=true.
Establecer esta variable de entorno en un sistema que no utiliza Log4j no debería causar ningún problema, ya que no será utilizado por ninguna otra aplicación o servicio en el sistema.

Mitigación 2:

Esta mitigación sugiere modificar las configuraciones de Log4j para especificar el convertidor de mensajes como %m{nolookups} en lugar de solo %m.
Esto se puede hacer en los archivos de configuración que son utilizados por la biblioteca de Log4j.
En el enlace proporcionado se mencionan varias ubicaciones de archivos de configuración.
El archivo de configuración en el que se debe aplicar esta mitigación depende de dónde se esté utilizando Log4j en el sistema.
En el ejemplo proporcionado, /usr/lib/appdynamics-php5/proxy/conf/logging/log4j2.xml es el archivo de configuración que necesita modificarse.
Otros archivos de configuración en los que se debe aplicar lo mismo dependerán de dónde se esté utilizando Log4j en ese sistema y será necesario identificar esos archivos.

Mitigación 3:

Esta mitigación sugiere eliminar la clase JndiLookup, que es la causa raíz de la vulnerabilidad.
Puede eliminarse de la ruta de clases borrando el archivo de clase directamente del archivo jar o utilizando el comando zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Si el archivo JndiLookup.class no existe, entonces esta mitigación no aplica y se puede omitir.

Answer

davy.ai

July 22, 2023 at 6:42 pm
Respuestas para Mitigaciones para la vulnerabilidad de Log4j

Mitigación 1:
- La propiedad del sistema log4j2.formatMsgNoLookups se utiliza para establecer el formato de los mensajes de Log4j sin incluir referencias de búsqueda de JNDI.
- Las propiedades del sistema son datos de configuración que pueden ser utilizados por las aplicaciones en Java.
- Estas propiedades se pueden establecer de varias maneras, incluyendo opciones de línea de comandos, archivos de propiedades del sistema Java, variables de entorno, etc.
- El establecimiento de la propiedad del sistema log4j2.formatMsgNoLookups como true se puede lograr utilizando opciones de línea de comandos de Java o configurándolo programáticamente en el código de Java.
- Alternativamente, otra forma mencionada en la mitigación es establecer la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS como true. Esto se puede lograr ejecutando el comando export LOG4J_FORMAT_MSG_NO_LOOKUPS=true.
- Establecer esta variable de entorno en un sistema que no utiliza Log4j no debería causar ningún problema, ya que no será utilizado por ninguna otra aplicación o servicio en el sistema.
Mitigación 2:
- Esta mitigación sugiere modificar las configuraciones de Log4j para especificar el convertidor de mensajes como %m{nolookups} en lugar de solo %m.
- Esto se puede hacer en los archivos de configuración que son utilizados por la biblioteca de Log4j.
- En el enlace proporcionado se mencionan varias ubicaciones de archivos de configuración.
- El archivo de configuración en el que se debe aplicar esta mitigación depende de dónde se esté utilizando Log4j en el sistema.
- En el ejemplo proporcionado, /usr/lib/appdynamics-php5/proxy/conf/logging/log4j2.xml es el archivo de configuración que necesita modificarse.
- Otros archivos de configuración en los que se debe aplicar lo mismo dependerán de dónde se esté utilizando Log4j en ese sistema y será necesario identificar esos archivos.
Mitigación 3:
- Esta mitigación sugiere eliminar la clase JndiLookup, que es la causa raíz de la vulnerabilidad.
- Puede eliminarse de la ruta de clases borrando el archivo de clase directamente del archivo jar o utilizando el comando zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
- Si el archivo JndiLookup.class no existe, entonces esta mitigación no aplica y se puede omitir.

Comments are closed.

es.davy.ai

¿Tienes una pregunta?