Hay una falla de seguridad grave en Log4J que aparentemente ha sido reparada. Pero no he encontrado una explicación inteligible de cómo podría haber una falla de seguridad en un marco de registro.
Parece tener algo que ver con "búsquedas". https://logging.apache.org/log4j/2.x/manual/lookups.html
¿Pero eso está en un archivo de configuración, no en un archivo de registro que podría inyectarse?
Pregunta. ¿Cómo elimino todas las cosas inteligentes de una vez por todas para evitar futuros exploits? Solo quiero iniciar sesión.
Parece que tengo que quitar los signos "$", pero eso es solo una suposición. (También se debe eliminar cualquier \ns para evitar la suplantación de archivos de registro. Siempre escribo un contenedor muy simple para que el registro pueda hacer este tipo de cosas).
(Tengo una corrección muy simple por la que pasan todos los mensajes de registro, por lo que es fácil para mí eliminar todos los "$" que no están en cadenas de formato).
La única forma de evitar las vulnerabilidades causadas por las búsquedas es deshabilitarlas por completo.
Según el equipo de log4j2, la forma de hacerlo es agregando el parámetro Java
-Dlog4j2.formatMsgNoLookups=true
Esto definitivamente corrige la capacidad de llamar a las búsquedas poniendo ${...} secuencias en la entrada del usuario (como en las URL que están registradas).
Desafortunadamente, las búsquedas se aplican a la secuencia registrada, incluso si usa parámetros o registra seguimientos de pila de excepciones. Las secuencias de búsqueda en su código no son peligrosas, porque son controlables. Pero los que provienen del usuario no son predecibles. Si registra 'nombre de usuario incorrecto: xxx', no tiene idea de lo que el usuario puede escribir para explotar otra vulnerabilidad.
Sin embargo, no puede estar seguro de que no haya otros errores graves en el marco, por lo que es razonable cambiar a otro marco de registro.
Un buen candidato es Logback , iniciado por el autor original de Log4j. El desarrollador afirma claramente que su marco no tiene nada que ver con los problemas de seguridad introducidos en Log4j2:
A menos que se especifique lo contrario, cuando decimos log4j nos referimos a log4j 1.x. También nos gustaría enfatizar que el inicio de sesión no está relacionado con log4j 2.x. No comparte código ni vulnerabilidades con log4j 2.x.
Aparentemente, el error se solucionó en la versión 2.16.0, sin embargo, solo aborda esa vulnerabilidad en particular y la función de búsqueda peligrosa no se eliminó.
Según el informe de Sophos ,
La versión actualizada de Log4j aún es compatible con el sistema potencialmente peligroso de "búsquedas" de cadenas "lo que ves, no es lo que obtienes", pero las conexiones JNDI basadas en la red, ya sea en la misma máquina o en otro lugar. , ya no están habilitados de forma predeterminada.
En otras palabras, log4j2 sigue siendo inseguro, pero no tan ridículamente inseguro como antes.
Por cuestiones de seguridad como esta, tiene sentido mantener la información actualizada en un solo lugar.
Consulte la información oficial de Log4j sobre esta vulnerabilidad aquí: https://logging.apache.org/log4j/2.x/security.html El documento establece varias medidas de mitigación aplicables para diferentes versiones de Log4j.
Me doy cuenta de que, en general, la convención de StackOverflow es tener pasos y ejemplos explícitos en la respuesta aquí en StackOverflow, en lugar de vincular a documentación externa, pero creo que las fallas de seguridad sensibles deberían ser una excepción.