Vulnerabilidades

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

En Tensorflow anteriores a la versión 2.3.1, "RaggedCountSparseOutput" no comprueba que los argumentos de entrada formen un tensor irregular válido. En particular, no existe comprobación de que el tensor "splits" tenga el número mínimo requerido de elementos. El código usa esta cantidad para inicializar una estructura de datos diferente. Dado que "BatchedMap" es equivalente a un vector, necesita tener al menos un elemento para que no sea "nullptr". Si el usuario pasa un tensor "splits" que se encuentra vacío o tiene exactamente un elemento, obtenemos una señal "SIGABRT" generada por el sistema operativo. El problema es parcheado en el commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 y es publicado en TensorFlow versión 2.3.1

En Tensorflow anteriores a la versión 2.3.1, la implementación de "RaggedCountSparseOutput" no comprueba que los argumentos de entrada formen un tensor irregular válido. En particular, no existe comprobación de que los valores en el tensor "splits" generen una partición válida del tensor "values". Por lo tanto, el código establece las condiciones para causar un desbordamiento del búfer de la pila. Un "BatchedMap" es equivalente a un vector donde cada elemento es un mapa de hash. Sin embargo, si el primer elemento de "splits_values" no es 0, "batch_idx" nunca será 1, por lo que no habrá un hashmap en el índice 0 en "per_batch_counts". Intentar acceder a eso en el código de usuario resulta en un fallo de segmentación. El problema es parcheado en el commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 y es publicado en TensorFlow versión 2.3.1

En Tensorflow anteriores a la versión 2.3.1, la implementación de "RaggedCountSparseOutput" no comprueba que los argumentos de entrada formen un tensor irregular válido. En particular, no existe comprobación de que los valores en el tensor "splits" generen una partición válida del tensor "values". Por lo tanto, el código es propenso a un desbordamiento del búfer de la pila. Si "split_values" no termina con un valor de al menos "num_values", entonces la condición de bucle "while" activará una lectura fuera de los límites de "split_values" una vez que "batch_idx" se incremente demasiado. El problema es parcheado en el commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 y es publicado en TensorFlow versión 2.3.1

En Tensorflow versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, la API "Shard" en TensorFlow espera que el último argumento sea una función que tome dos argumentos "int64" (es decir, "long long"). Sin embargo, existen varios lugares en TensorFlow donde se usa una lambda que toma argumentos "int" o "int32". En estos casos, si la cantidad de trabajo que se va a paralelizar es lo suficientemente grande, se produce un truncamiento de enteros. Dependiendo de cómo sean usados los dos argumentos de la lambda, esto puede resultar en fallos de segmentación, lectura y escritura fuera de las matrices asignadas a la pila, desbordamientos de pila o corrupción de datos. El problema es parcheado en las commits 27b417360cbd671ef55915e4bb6bb06af8b8a832 y ca8c013b5e97b1373b3bb1c97ea655e69f31a575, y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En Tensorflow versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, al controlar el argumento "fill" de tf.strings.as_string, un atacante malicioso puede desencadenar una vulnerabilidad de cadena de formato debido a la manera en que se construye el uso del formato interno en una llamada de "printf". Esto puede resultar en un fallo de segmentación. El problema es parcheado en el commit 33be22c65d86256e6826666662e40dbdfe70ee83 y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En modo eager, TensorFlow versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1 no establece el estado de la sesión. Por lo tanto, llamar a "tf.raw_ops.GetSessionHandle" o "tf.raw_ops.GetSessionHandleV2" resulta en una desreferencia del puntero null. En el fragmento vinculado, en modo eager, "ctx-) session_state()" devuelve "nullptr". Dado que el código elimina inmediatamente la referencia a esto, obtenemos un fallo de segmentación. El problema es parcheado en el commit 9a133d73ae4b4664d22bd1aa6d654fec13c52ee1 y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1

En Tensorflow versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, el argumento "data_splits" de "tf.raw_ops.StringNGrams" carece de comprobación. Esto permite a un usuario pasar valores que pueden causar errores de desbordamiento de la pila e incluso filtrar el contenido de la memoria. En el fragmento de código vinculado, todas las cadenas binarias después de "ee ff" son contenidos desde la pila de memoria. Dado que estos pueden contener direcciones de retorno, este filtrado de datos se puede utilizar para anular ASLR. El problema es parcheado en el commit 0462de5b544ed4731aa2fb23946ac22c01856b80 y es publicado en TensorFlow versiones 1.15.4, 2.0.3, 2.1.2, 2.2.1 o 2.3.1