Vulnerabilidades

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de 9.6.0-alpha.29 y 8.6.49, un usuario podía registrarse sin proporcionar credenciales enviando un objeto 'authData' vacío, eludiendo el requisito de nombre de usuario y contraseña. Esto permite la creación de sesiones autenticadas sin credenciales adecuadas, incluso cuando los usuarios anónimos están deshabilitados. La corrección en 9.6.0-alpha.29 y 8.6.49 asegura que 'authData' vacío o no procesable sea tratado igual que un 'authData' ausente a efectos de la validación de credenciales en la creación de nuevos usuarios. Ahora se requieren nombre de usuario y contraseña cuando no hay datos de proveedor de autenticación válidos presentes. Como solución alternativa, utilice un disparador 'beforeSave' de Cloud Code en la clase '_User' para rechazar registros donde 'authData' esté vacío y no se proporcione nombre de usuario/contraseña.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de las versiones 9.6.0-alpha.35 y 8.6.50, cuando un disparador 'Parse.Cloud.afterLiveQueryEvent' se registra para una clase, el servidor LiveQuery filtra campos protegidos y 'authData' a todos los suscriptores de esa clase. Los campos configurados como protegidos a través de Permisos a Nivel de Clase ('protectedFields') se incluyen en las cargas útiles de eventos de LiveQuery para todos los tipos de eventos (crear, actualizar, eliminar, entrar, salir). Cualquier usuario con permisos CLP suficientes para suscribirse a la clase afectada puede recibir datos de campos protegidos de otros usuarios, incluyendo información personal sensible y tokens OAuth de proveedores de autenticación de terceros. La vulnerabilidad fue causada por un error de desvinculación de referencia. Cuando un disparador 'afterEvent' se registra, el servidor LiveQuery convierte el objeto de evento en un 'Parse.Object' para el disparador, luego crea una nueva copia JSON a través de 'toJSONwithObjects()'. El filtro de datos sensibles se aplicó a la referencia de 'Parse.Object', pero la copia JSON sin filtrar fue enviada a los clientes. La corrección en las versiones 9.6.0-alpha.35 y 8.6.50 asegura que la copia JSON se reasigne al objeto de respuesta antes de filtrar, de modo que el filtro opera sobre los datos reales enviados a los clientes. Como solución alternativa, elimine todos los registros de disparadores 'Parse.Cloud.afterLiveQueryEvent'. Sin un disparador 'afterEvent', la desvinculación de referencia no ocurre y los campos protegidos se filtran correctamente.

Escritura de array fuera de límites en Xpdf 4.06 y versiones anteriores, debido a una validación incorrecta del campo 'N' en espacios de color ICCBased.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de 9.6.0-alpha.17 y 8.6.42, un usuario autenticado puede sobrescribir campos de sesión generados por el servidor ('sessionToken', 'expiresAt', 'createdWith') al crear un objeto de sesión a través de 'POST /classes/_Session'. Esto permite eludir la política de expiración de sesión del servidor al establecer una fecha de expiración arbitraria en un futuro lejano. También permite establecer un valor de token de sesión predecible. A partir de la versión 9.6.0-alpha.17 y 8.6.42, el endpoint de creación de sesión filtra los campos generados por el servidor de los datos proporcionados por el usuario, impidiendo que sean sobrescritos. Como solución alternativa, añada un disparador 'beforeSave' en la clase '_Session' para validar y rechazar o eliminar cualquier valor proporcionado por el usuario para 'sessionToken', 'expiresAt' y 'createdWith'.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de 9.6.0-alpha.19 y 8.6.43, un atacante remoto puede provocar la caída del Parse Server al suscribirse a un LiveQuery con un patrón de expresión regular inválido. El proceso del servidor termina cuando el patrón inválido llega al motor de expresiones regulares durante la coincidencia de suscripción, causando denegación de servicio para todos los clientes conectados. La corrección en 9.6.0-alpha.19 y 8.6.43 valida los patrones de expresiones regulares en el momento de la suscripción, rechazando patrones inválidos antes de que sean almacenados. Además, un try-catch de defensa en profundidad evita que cualquier error de coincidencia de suscripción provoque la caída del proceso del servidor. Como solución alternativa, deshabilite LiveQuery si no es necesario.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de 9.6.0-alpha.20 y 8.6.44, un atacante puede eludir la protección predeterminada de la lista de denegación de palabras clave de solicitud y el permiso a nivel de clase para añadir campos enviando una solicitud manipulada que explota la contaminación de prototipos en el mecanismo de copia profunda. Esto permite inyectar campos en esquemas de clase que tienen la adición de campos bloqueada, y puede causar conflictos permanentes de tipo de esquema que no pueden resolverse ni siquiera con la clave maestra. En 9.6.0-alpha.20 y 8.6.44, la biblioteca vulnerable de copia profunda de terceros ha sido reemplazada por un mecanismo de clonación profunda incorporado que maneja las propiedades de prototipo de forma segura, permitiendo que la comprobación de la lista de denegación existente detecte y rechace correctamente la palabra clave prohibida. No se conocen soluciones alternativas disponibles.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de las versiones 9.6.0-alpha.24 y 8.6.47, clientes remotos pueden bloquear el proceso de Parse Server al llamar a un endpoint de función en la nube con un nombre de función manipulado que atraviesa la cadena de prototipos de JavaScript de un gestor de función en la nube registrado, causando un desbordamiento de pila. La corrección en las versiones 9.6.0-alpha.24 y 8.6.47 restringe las búsquedas de propiedades durante la resolución de nombres de funciones en la nube solo a las propiedades propias, evitando el recorrido de la cadena de prototipos desde los gestores de funciones almacenados. No existe una solución alternativa conocida.

Parse Server es un backend de código abierto que puede implementarse en cualquier infraestructura que pueda ejecutar Node.js. Antes de las versiones 9.6.0-alpha.28 y 8.6.48, el mecanismo de restablecimiento de contraseña no aplica garantías de un solo uso para los tokens de restablecimiento. Cuando un usuario solicita un restablecimiento de contraseña, el token generado puede ser consumido por múltiples solicitudes concurrentes dentro de una ventana de tiempo corta. Un atacante que ha interceptado un token de restablecimiento de contraseña puede competir con la solicitud de restablecimiento de contraseña del usuario legítimo, haciendo que ambas solicitudes tengan éxito. Esto puede resultar en que el usuario legítimo crea que su contraseña fue cambiada exitosamente mientras que la contraseña del atacante entra en vigor en su lugar. Todas las implementaciones de Parse Server que utilizan la función de restablecimiento de contraseña están afectadas. A partir de las versiones 9.6.0-alpha.28 y 8.6.48, el token de restablecimiento de contraseña ahora se valida y consume atómicamente como parte de la operación de actualización de contraseña. La consulta a la base de datos que actualiza la contraseña incluye el token de restablecimiento como una condición, asegurando que solo una solicitud concurrente pueda consumir exitosamente el token. Las solicitudes posteriores que utilicen el mismo token fallarán porque el token ya ha sido borrado. No existe una solución alternativa conocida aparte de la actualización.

Parse Server es un backend de código abierto que puede ser desplegado en cualquier infraestructura que pueda ejecutar Node.js. Antes de las versiones 9.6.0-alpha.21 y 8.6.45, un atacante no autenticado puede bloquear el proceso de Parse Server enviando una única solicitud con operadores de condición de consulta profundamente anidados. Esto termina el servidor y deniega el servicio a todos los clientes conectados. A partir de las versiones 9.6.0-alpha.21 y 8.6.45, se ha añadido un límite de profundidad para el anidamiento de operadores de condición de consulta a través de la opción de servidor 'requestComplexity.queryDepth'. La opción está deshabilitada por defecto para evitar un cambio disruptivo. Para mitigar, actualice y configure la opción a un valor apropiado para su aplicación. No se conocen soluciones alternativas disponibles.

OpenProject es un software de gestión de proyectos de código abierto, basado en la web. Las versiones anteriores a 16.6.9, 17.0.6, 17.1.3 y 17.2.1 son vulnerables a un ataque de inyección SQL a través del nombre de un campo personalizado. Cuando ese campo personalizado se utilizaba en un Informe de Costos, el nombre del campo personalizado se inyectaba en la consulta SQL sin la sanitización adecuada. Esto permitía a un atacante ejecutar comandos SQL arbitrarios durante la generación de un Informe de Costos. Dado que los campos personalizados solo pueden ser generados por usuarios con privilegios de administrador completos, la superficie de ataque se reduce un poco. Junto con otro error en el módulo Repositories, que utilizaba el identificador del proyecto sin sanitización para generar la ruta de extracción para un repositorio git en el sistema de archivos, esto permitía a un atacante extraer un repositorio git a una ruta elegida arbitrariamente en el servidor. Si la extracción se realiza dentro de ciertas rutas dentro de la aplicación OpenProject, tras el siguiente reinicio de la aplicación, esto permite al atacante inyectar código ruby en la aplicación. Dado que el identificador del proyecto no puede ser editado manualmente a ninguna cadena que contenga caracteres especiales como puntos o barras, esto necesita ser cambiado a través de la inyección SQL descrita anteriormente. Las versiones 16.6.9, 17.0.6, 17.1.3 y 17.2.1 corrigen el problema.

OpenProject es un software de gestión de proyectos de código abierto y basado en la web. En versiones anteriores a la 16.6.9, 17.0.6, 17.1.3 y 17.2.1, el módulo de Repositorios no escapaba correctamente los nombres de archivo mostrados desde los repositorios. Esto permitía a un atacante con acceso de push al repositorio crear commits con nombres de archivo que incluían código HTML que se inyectaba en la página sin la sanitización adecuada. Esto permitía un ataque XSS persistente contra todos los miembros de este proyecto que accedían a la página de repositorios para mostrar un changeset donde el archivo creado maliciosamente había sido eliminado. Las versiones 16.6.9, 17.0.6, 17.1.3 y 17.2.1 corrigen el problema.

Memray es un perfilador de memoria para Python. Antes de Memray 1.19.2, Memray renderizaba la línea de comandos del proceso rastreado directamente en los informes HTML generados sin escapar. Debido a que no había escape, los argumentos de línea de comandos controlados por el atacante se insertaban como HTML sin procesar en el informe generado. Esto permitía la ejecución de JavaScript cuando una víctima abría el informe generado en un navegador. La versión 1.19.2 corrige el problema.