Triple_fetch

triple_fetch - ianbeer [https://bugs.chromium.org/p/project-zero/issues/detail?id=1247]

Este es un exploit para CVE-2017-7047, un error lógico en libxpc que permitía a remitentes de mensajes maliciosos enviar objetos xpc_data que estaban respaldados por memoria compartida. Los consumidores de mensajes xpc no parecían esperar que los búferes de respaldo de los objetos xpc_data pudieran ser modificados por el remitente mientras son procesados por el receptor.

Este proyecto explota CVE-2017-7047 para construir un stub de debugserver remoto lldb de prueba de concepto capaz de adjuntarse a y permitir la depuración remota de todos los procesos de espacio de usuario en iOS.

Esta es una visión general de alto nivel del exploit, un análisis en profundidad podría seguir en una fecha posterior. Por ahora, consulte el código para más detalles :)

Parte I

El exploit ataca a NSXPC, una implementación de Llamada a Procedimiento Remoto Objective-C utilizada por muchos servicios de iOS (1). Un mensaje NSXPC consiste en un objeto serializado bplist16 dentro de un objeto xpc_data serializado en xpc dentro de un mensaje mach.

Entre otras cosas, el objeto bplist16 contiene una cadena de codificación de tipos de Objective-C (2) que será analizada por la función ___NSMS1 en CoreFoundation. Esta función no espera que el contenido de la cadena que está analizando cambie y este exploit usa eso para construir una primitiva de desbordamiento de montón explotando el hecho de que una cierta parte de la cadena se obtendrá de la memoria tres veces. Al alternar entre tres valores diferentes y cuidadosamente elegidos, podemos desbordar un tamaño de asignación de montón elegido con bytes arbitrarios.

minibplist16.c contiene una implementación mínima de la serialización bplist y una discusión de cómo funciona.

El mensaje xpc externo contiene el arreglo del montón (heap groom). Utiliza una implementación personalizada del protocolo de serialización XPC para preparar el montón creando diccionarios xpc con claves en conflicto para construir primitivas de asignación y liberación. El mensaje xpc externo también contiene un rociado de montón (heap spray) (usando múltiples copias de un objeto de memoria compartida para mantener bajo el uso de memoria) y un rociado de nombres de derechos de envío de puertos mach.

El desbordamiento apunta el puntero isa Class de un objeto Objective-C a un objeto falso rociado en el montón, de modo que cuando se llama a un método en ese objeto falso, la pila se pivota a una pequeña pila ROP. La ROP fuerza bruta a través de los nombres de derechos de envío de puertos mach rociados intentando enviar el derecho de envío del objetivo a su propio puerto de tarea a cada uno de los nombres de derechos de envío rociados candidatos. El exploit escucha en todos los puertos rociados y si el exploit tiene éxito recibe un derecho de envío al puerto de tarea del objetivo, momento en el que tiene control total sobre la tarea objetivo.

Interludio

El exploit ataca al servicio com.apple.CoreAuthentication.daemon alojado por el demonio coreauthd que se ejecuta como root. Se puede acceder a este servicio desde la sandbox de la aplicación. Un poco de experimentación después de que inicialmente logré que el exploit funcionara reveló que desde el contexto de coreauthd, la API processor_set_tasks puede obtener derechos de envío a los puertos de tarea de todos los procesos de espacio de usuario que se ejecutan en el dispositivo. Esto ha sido conocimiento público desde al menos 2012, y la historia está cubierta en profundidad por el prominente investigador de internos de iOS Jonathan Levin en su sitio (3). El código que Levin subió en 2015 aún funciona hoy en día: no requiere un dispositivo con jailbreak, solo root en un dispositivo estándar.

Parte II

El objetivo principal del depurador que quería construir con este exploit era poder adjuntarse a un proceso arbitrario, establecer puntos de interrupción e inspeccionar y alterar el estado de registros y memoria cuando se alcanzan. En lugar de implementar el protocolo remoto de gdb o lldb desde cero decidí hacer los cambios necesarios en el proyecto lldb debugserver y luego usar el exploit para ejecutarlo.

En lugar de usar puntos de interrupción por software que requieren deshabilitar o eludir la firma de código, el debugserver está parcheado para usar exclusivamente puntos de interrupción por hardware. ARM64 tiene 16 registros de puntos de interrupción por hardware, lo que significa que solo puedes tener un máximo de 16 puntos de interrupción activos.

El soporte prototipo para puntos de interrupción por hardware ARM existía en el código de lldb debugserver pero requería algo de pirateo para que funcionara. Por ejemplo, tuve que agregar código que parchea el puntero de función pthread_introspection_hook en el debugee para que siempre falle, de modo que pueda detectar la creación de nuevos hilos y propagar el estado de los puntos de interrupción por hardware a los hilos recién creados y continuar como si nunca hubiera fallado.

También he parcheado el código de attach y continue para suspender y reanudar directamente la tarea a través del puerto de tarea en lugar de usar ptrace y señales.

Consejos de compilación

Todo debería funcionar para todos los dispositivos iOS que ejecuten 10.0 a 10.3.2 inclusive. He probado en:

iPhone 7 + 10.3.2 iPod Touch + 10.1.1 iPad Mini 2 + 10.2

He incluido un binario debugserver precompilado que sugiero que uses, pero el parche para el debugserver de lldb también está incluido en debugserver.diff.

Compilar el debugserver no es demasiado difícil. Estaba trabajando con las siguientes revisiones de git: lldb: 0db640c4cd1ec4e4c2580336fa5f53be029c5bc7 llvm: ec48fd127774a4b67c72ea7c3057b5c964375e77 clang: b6e778e0bfa2fc32f8821c6b33762f5cb6724659

aplica el debugserver.diff proporcionado.

Para la compilación necesitas cmake (reciente) y ninja; puedes obtenerlos desde el código fuente o binarios desde tu gestor de paquetes de Mac favorito.

(4) tiene una guía sobre cómo configurar una compilación normal de llvm en MacOS que puede ser útil.

Necesitarás enlazar simbólicamente un montón de archivos de encabezado en tu SDK de iOS, al menos:

xpc/ launchd.h libproc.h sys/proc_info.h sys/kern_control.h net/route.h mach/mach_vm.h mach/shared_region.h sys/ptrace.h crt_externs.h

la siguiente invocación de cmake debería darte todas las pistas que necesitas:

cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64" -DCMAKE_TOOLCHAIN_FILE=../cmake/platforms/iOS.cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_RUNTIME=Off -DLLVM_INCLUDE_TESTS=Off -DLLVM_INCLUDE_EXAMPLES=Off -DLLVM_ENABLE_BACKTRACES=Off ../

ninja debugserver

Luego necesitarás firmar o fakesignar el binario debugserver y reemplazar el que está en el proyecto xcode proporcionado.

Firma de código

El proyecto del exploit por defecto instalará una versión mejorada del hook amfid de mach_portal (esta vez con soporte funcional para archivos fat y sin offsets hardcodeados :) )

Si solo quieres depurar cosas, deberías poder firmar el binario debugserver con tu propio certificado y deshabilitar el hook amfid.

Si usas el hook amfid, ten en cuenta que la aplicación en la que se ejecuta aún está sujeta a límites de ejecución de código en segundo plano. La aplicación solicita más tiempo mediante beginBackgroundTaskWithName.

Uso:

Conecta tu host y el iDevice objetivo a la misma red inalámbrica y anota la dirección IP del iDevice.

Compila y ejecuta la aplicación del exploit. Recomiendo hacerlo dentro de xcode, pero funcionará de forma independiente.

Espera un poco. Si no funciona después de un par de minutos, reinicia el dispositivo por completo, espera un poco y luego inténtalo de nuevo.

Si funciona, debería imprimir “patched debugserver listening on port 1234”

Si haces clic en el botón “get process listing”, deberías ver la salida de ps

(es más fácil ver la salida si usas xcode, pero el exploit también mostrará la salida)