Vulnerabilidades

Se detectó un problema en MediaWiki versiones anteriores a 1.31.10 y desde1.32.x hasta 1.34.x anteriores a 1.34.4. La versión que no es jqueryMsg de la función mw.message(). La función Parse() no escapa al HTML. Esto afecta tanto al contenido del mensaje (que generalmente es seguro) como a los parámetros (que pueden estar basados en la entrada de usuario). (Cuando se carga jqueryMsg, acepta correctamente solo las etiquetas en la lista blanca en el contenido del mensaje y escapa todos los parámetros. Las situaciones con un jqueryMsg descargado son raras en la práctica, pero pueden ocurrir, por ejemplo, para Special:SpecialPages en una wiki sin extensiones instaladas)

Se detectó un filtrado de información en MediaWiki versiones anteriores a 1.31.10 y desde 1.32.x hasta 1.34.x anteriores a 1.34.4. El manejo de la identificación del actor no necesariamente usa la base de datos correcta o la wiki correcta

http.client en Python 3.x antes de la versión 3.5.10, 3.6.x antes de la versión 3.6.12, 3.7.x antes de la versión 3.7.9, y 3.8.x antes de la versión 3.8.5 permite la inyección de CRLF si el atacante controla el método de petición HTTP, como se demuestra insertando caracteres de control CR y LF en el primer argumento de HTTPConnection.request

En los archivos rfb/CSecurityTLS.cxx y rfb/CSecurityTLS.java en TigerVNC versiones anteriores a 1.11.0, los espectadores manejan inapropiadamente las excepciones del certificado TLS. Almacenan los certificados como autoridades, lo que significa que el propietario de un certificado puede hacerse pasar por cualquier servidor después de que un cliente haya agregado una excepción

En tensorflow-lite versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, al determinar el tamaño de dimensión común de dos tensores, TFLite usa un "DCHECK" que no es operativo fuera de los modos de compilación de depuración. Dado que la función siempre devuelve la dimensión del primer tensor, los atacantes maliciosos pueden crear casos en los que este sea mayor que el del segundo tensor. A su vez, esto resultaría en lecturas y escrituras fuera de límites, ya que el intérprete asumirá incorrectamente que existen suficientes datos en ambos tensores. El problema es parcheado en el commit 8ee24e7949a203d234489f9da2c5bf45a7d5157d, y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En tensorflow-lite versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, un modelo TFLite diseñado puede forzar a un nodo a tener como entrada un tensor respaldado por un búfer de "nullptr". Esto se puede lograr cambiando un índice de búfer en la serialización flatbuffer para convertir un tensor de solo lectura en uno de lectura y escritura. El tiempo de ejecución asume que estos búferes son escritos antes de una posible lectura, por lo que son inicializados con "nullptr". Sin embargo, al cambiar el índice del búfer por un tensor y convertir implícitamente ese tensor en uno de lectura y escritura, ya que no existe nada en el modelo que escriba en él, obtenemos una desreferencia del puntero null. El problema es parcheado en el commit 0b5662bc y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En tensorflow-lite versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, si un modelo guardado de TFLite usa el mismo tensor como entrada y salida de un operador, entonces, dependiendo del operador, podemos observar un fallo de segmentación o solo una corrupción de la memoria. Hemos parcheado el problema en d58c96946b y publicaremos parches para todas las versiones entre 1.15 y 2.3. Recomendamos a los usuarios que actualicen a TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En TensorFlow Lite versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, los modelos guardados en formato flatbuffer usan un esquema de indexación doble: un modelo tiene un conjunto de subgráficos, cada subgráfico tiene un conjunto de operadores y cada operador tiene un conjunto de tensores de entrada/salida. El formato flatbuffer usa índices para los tensores, indexando en una matriz de tensores que es propiedad del subgráfico. Esto resulta en un patrón de indexación de doble matriz cuando intenta obtener los datos de cada tensor. Sin embargo, algunos operadores pueden tener algunos tensores opcionales. Para manejar este escenario, el modelo flatbuffer usa un valor negativo "-1" como índice para estos tensores. Esto resulta en un cubierta especial durante la comprobación en el momento de la carga del modelo. Desafortunadamente, esto significa que el índice "-1" es un índice tensorial válido para cualquier operador, incluyendo aquellos que no esperan entradas opcionales e incluso para tensores de salida. Por tanto, esto permite escribir y leer desde fuera de los límites de los arreglos asignados de la pila, aunque solo en un desplazamiento específico desde el inicio de estos arreglos. Esto resulta en gadgets de lectura y escritura, aunque con un alcance muy limitado. El problema es parcheado en varias commits (46d5b0852, 00302787b7, e11f5558, cd31fd0ce, 1970c21 y fff2c83) y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1. Una solución alternativa potencial sería agregar un "Verifier" personalizado al código de carga del modelo para garantizar que solo los operadores que aceptan entradas opcionales usen el valor especial "-1" y solo para los tensores que esperan que sean opcionales. Dado que este enfoque de tipo allow-list es propenso a errores, recomendamos actualizar al código parcheado

En TensorFlow Lite versiones anteriores a 2.2.1 y 2.3.1, los modelos que utilizan la suma de segmentos pueden activar escrituras fuera de límites de los búferes asignados de la pila insertando elementos negativos en el tensor de los ids de segmento. Los usuarios que tienen acceso a "segment_ids_data" pueden alterar "output_index" y luego escribir fuera del búfer de "output_data". Esto podría resultar en un fallo de segmentación, pero también se puede usar para corromper aún más la memoria y se puede encadenar con otras vulnerabilidades para crear explotaciones más avanzadas. El problema es parcheado en el commit 204945b19e44b57906c9344c0d00120eeeae178a y es publicado en TensorFlow versiones 2.2.1 o 2.3.1. Una solución alternativa potencial sería agregar un "Verifier" personalizado al código de carga del modelo para asegurar que los ids de segmento sean todos positivos, aunque esto solo maneja el caso cuando los ids de segmento son almacenados estáticamente en el modelo. Una comprobación similar podría ser realizada si los ids de segmento se generan en el tiempo de ejecución entre los pasos de inferencia. Si los ids de segmento son generados como salidas de un tensor durante los pasos de inferencia, entonces no existe una posible solución alternativa y se recomienda a los usuarios actualizar al código parcheado

En TensorFlow Lite versiones anteriores a 2.2.1 y 2.3.1, los modelos que utilizan la suma de segmentos pueden desencadenar una denegación de servicio al causar una asignación de memoria insuficiente en la implementación de la suma de segmentos. Dado que el código usa el último elemento del tensor que los conserva para determinar la dimensionalidad del tensor de salida, los atacantes pueden usar un valor muy grande para desencadenar una gran asignación. El problema es parcheado en el commit 204945b19e44b57906c9344c0d00120eeeae178a y es publicado en TensorFlow versiones 2.2.1 o 2.3.1. Una solución alternativa potencial sería agregar un "Verifier" personalizado para limitar el valor máximo en el tensor de los ids de segmento. Esto solo maneja el caso cuando los ids de segmento son almacenados estáticamente en el modelo, pero se podría realizar una comprobación similar si los ids de segmento son generados en el tiempo de ejecución, entre los pasos de inferencia. Sin embargo, si los ids de segmento son generados como salidas de un tensor durante los pasos de inferencia, entonces no existe una solución posible y se recomienda a los usuarios actualizar al código parcheado

En TensorFlow Lite versiones anteriores a 2.2.1 y 2.3.1, los modelos que utilizan la suma de segmentos pueden desencadenar un fallo de segmentación y una escritura fuera de límites si los ids de segmento no están ordenados. El código asume que los ids de segmento están en orden creciente, usando el último elemento del tensor que los conserva para determinar la dimensionalidad del tensor de salida. Esto resulta en una asignación de memoria insuficiente para el tensor de salida y una escritura fuera de límites de la matriz de salida. Esto usualmente, resulta en un fallo de segmentación, pero dependiendo de las condiciones del tiempo de ejecución, puede proporcionar un gadget de escritura que se usará en futuras explotaciones basadas ??en una corrupción de la memoria. El problema es parcheado en el commit 204945b19e44b57906c9344c0d00120eeeae178a y es publicado en TensorFlow versiones 2.2.1 o 2.3.1. Una solución alternativa potencial sería agregar un "Verifier" personalizado al código de carga del modelo para asegurar que los ids de segmento estén ordenados, aunque esto solo maneja el caso cuando los ids de segmento son almacenados estáticamente en el modelo. Una comprobación similar podría ser realizada si los ids de segmento se generan en el tiempo de ejecución entre los pasos de inferencia. Si los ids de segmento son generados como salidas de un tensor durante los pasos de inferencia, entonces no existe una posible solución alternativa y se recomienda a los usuarios actualizar al código parcheado

En Tensorflow anteriores a la versión 2.3.1, la implementación de "SparseCountSparseOutput" no comprueba que los argumentos de entrada formen un tensor disperso válido. En particular, no existe comprobación de que el tensor "indices" tenga la misma forma que el "values". Los valores de estos tensores siempre se acceden en paralelo. Por lo tanto, una discrepancia de forma puede resultar en accesos fuera de límites de los búferes asignados de la pila. El problema es parcheado en el commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 y es publicado en TensorFlow versión 2.3.1