Explotación en 10.15 y 11.0 beta

El runtime de Objective-C utilizado en macOS 10.15 no es vulnerable a la técnica de explotación detallada previamente, porque las categorías no se cargan antes de que se establezca didCallDyldNotifyRegister, lo que hace que nuestro método +initialize se llame solo después de que ocurra la inicialización del sandbox.

Sin embargo, map_images aún se llama en nuestro binario, lo que permite alterar los datos del runtime de maneras no deseadas que nos permitirían ejecutar código antes de la inicialización del sandbox. La explotación completa y comentada está en main.c, pero repasaré los detalles básicos aquí. Creamos una estructura de clase de Objective-C cuyo puntero data apunta a una ubicación en libxbc.dylib. Esa ubicación debe elegirse de manera que flags tenga el bit 31 (RW_REALIZED) establecido, para que el runtime no intente realizar esta clase inválida y se bloquee, y firstSubclass debe compartir su dirección con la isa de una clase que queremos sobrescribir. Otra clase (meta) heredará de esta clase inválida y proporcionará su propio método +initialize. Agregamos la subclase a __objc_nlclslist para que el runtime realice esta clase.

Cuando el runtime realiza nuestra subclase, lo que sucede antes de la inicialización del sandbox, llamará a addSubclass en nuestra superclase inválida y subclase, lo que reemplazará la isa de la víctima con un puntero a nuestra subclase, reemplazando efectivamente todos sus métodos con nuestro +initialize. Cuando se llame a nuestro método +initialize, que será antes de la inicialización del sandbox si elegimos una clase víctima adecuada, podemos reemplazar nuevamente las referencias a _libsecinit_initializer con nops (de manera condicional o no), y corregir los cambios en el runtime que hayamos hecho para reanudar la ejecución sin bloquearse más adelante.

Demostración proporcionada

La demostración proporcionada se puede compilar ejecutando make, creando un archivo en ~/Documents/SecretDocument.txt, y ejecutando SnatchBox.app/Contents/MacOS/SnatchBox desde la terminal (Se crea un bundle porque es requerido por com.apple.security.app-sandbox, pero sigue siendo un programa de línea de comandos). El binario compilado está firmado con com.apple.security.app-sandbox lo que normalmente impediría el acceso a ~/Documents/SecretDocument.txt (ya que no está en nuestro contenedor), pero podrá leer sus datos de todos modos. Debido a cambios en la estructura del runtime, esta demostración no funcionará en macOS 10.14 y versiones anteriores sin modificar, pero funcionará en 10.15 y 11.0 (Probado: 10.15.4, 10.15.7 y 11.0 Beta (20A5354i)). Las dos técnicas de explotación se pueden combinar para apuntar a ambas versiones del runtime, pero no se proporciona dicha demostración.

Example run:

Impacto

Como se mencionó anteriormente, esto permite crear una aplicación de la App Store de macOS que no se ejecuta en un sandbox a pesar de que la política de la App Store lo exige. La vulnerabilidad también se puede usar en un framework, que puede ser utilizado por aplicaciones de la App Store que de otro modo serían legítimas. Por último, incluso se puede combinar con algo similar a "Xcode Ghost" para inyectar masivamente código malicioso que se ejecuta fuera del sandbox en aplicaciones de la App Store.

Corrección

Apple corrigió el exploit durante la etapa de pruebas beta de macOS 11.0 agregando una llamada a malloc_size en realizeClassWithoutSwift. Esto confirma que si una clase está marcada como realizada (RW_REALIZED, como nuestra clase falsa), efectivamente tiene un puntero de datos válido, asignado con malloc, con el tamaño correcto (0x20 bytes). Si este no es el caso, el runtime abortará con un mensaje similar a realized class 0x100002078 has corrupt data pointer 0x7fff88c00948. La corrección también se aplicó a iOS, iPadOS, tvOS y watchOS; incluso si no se ven directamente afectados.