El sistema operativo macOS se caracteriza por su robustez y múltiples capas de seguridad diseñadas para proteger al usuario y al sistema en sí. Sin embargo, como todo software complejo, puede presentar vulnerabilidades explotables, especialmente en componentes que interactúan constantemente con otros procesos o aplicaciones, como es el caso de la comunicación entre procesos en macOS (IPC) mediante mensajes Mach. En la primera parte de esta investigación titulada "Rompiendo la Barrera del Sonido", se revela un estudio pormenorizado sobre cómo se puede emplear el fuzzing — una técnica automatizada de prueba que consiste en enviar datos aleatorios o manipulados a un programa para descubrir fallos — aplicado a CoreAudio, el componente encargado del manejo de audio en macOS, a través de esta vía de mensajes Mach. Los procesos altamente privilegiados que operan en macOS incluyen una gran cantidad de “daemons” o demonios de sistema que procesan cientos de mensajes IPC cada segundo. Hay casos en los que estos demonios, pese a su alto nivel de privilegios, aceptan datos provenientes de procesos con restricciones severas o sandboxeados, lo que crea una superficie de ataque significativa si esas comunicaciones no están debidamente protegidas.
En este contexto, se estudia cómo la manipulación de mensajes Mach puede ser un vector efectivo para encontrar vulnerabilidades que permitan escapar del sandbox, logrando así elevar privilegios y tomar control del sistema. El enfoque adoptado para esta investigación es una metodología híbrida conocida como "fuzzing basado en conocimiento" o "knowledge-driven fuzzing". Esta técnica combina la automatización del fuzzing con la ingeniería inversa manual para obtener una comprensión profunda del código que se está auditando. De esta forma, es posible no solo detectar fallos con rapidez sino también comprender su estructura y contexto, lo que facilita una mejor triage de los incidentes críticos. La investigación se inicia identificando un vector de ataque viable, seguido por la selección del objetivo, la construcción de un entorno para inyectar las pruebas de fuzzing, la ejecución del fuzzing y la posterior interpretación tanto de las fallas encontradas como de la cobertura de código lograda.
La elección del vector de ataque recae en los mensajes Mach, que conforman el componente más bajo del sistema IPC en macOS. Estos mensajes son estructuras que se almacenan en colas controladas por el kernel y se envían y reciben a través de puertos Mach a los que los procesos deben tener derechos específicos para interactuar. Al tratarse de una vía fundamental para la comunicación entre procesos, poseen un historial documentado de problemas de seguridad. Conocer su funcionamiento interno y atacar desde esta base permite descubrir fallas potencialmente graves que otras técnicas podrían pasar por alto. Selección de objetivo: dentro de la gran variedad de servicios que operan con mensajes Mach existe la necesidad de escoger un blanco estratégico.
En este caso, se optó por coreaudiod, el demonio responsable de la gestión de audio en macOS a través del servicio Mach “com.apple.audio.audiohald”. Las razones que motivaron esta elección incluyen la complejidad del proceso, la exposición a servicios de aplicaciones potentes como Safari GPU Process, el gran número de manejadores de mensajes, y la sensibilidad relacionada con el control de hardware que coreaudiod puede modificar.
Además, tratar con módulos en gran medida cerrados como CoreAudio Framework representa un reto atractivo para la ingeniería inversa. En la creación del “fuzzing harness”, el entorno específico desde donde se envían mensajes manipulados para analizar la respuesta del sistema, se exploraron dos alternativas. La primera consistía en realizar fuzzing a nivel interprocesos, enviando mensajes Mach a coreaudiod usando la API mach_msg. Sin embargo, este método presentaba problemas de complejidad añadida, sobrecarga y dificultades para recopilar información detallada de cobertura de código debido a la separación entre procesos. La segunda alternativa, y la adoptada finalmente, fue desarrollar un “harness” directo que carga los manejadores de mensajes Mach dentro del mismo espacio de proceso donde corre el fuzzer.
Esto permite eficiencias significativas en la instrumentación y recopilación de datos, aunque con el compromiso de asumir que los mensajes evaden ciertas validaciones del kernel. Dadas estas circunstancias, la investigación se apoyó en el análisis estático y dinámico para localizar el núcleo de manejo de mensajes Mach. Gracias a herramientas que permiten analizar el Dyld Shared Cache, lugar donde se almacenan los frameworks en macOS modernos, se descubrió que el framework CoreAudio contiene la funcionalidad deseada, a la vez que utiliza el Mach Interface Generator (MIG) para facilitar la programación de servidores y clientes RPC mediante mensajes Mach. La función central que procesa los mensajes en coreaudiod es el servidor MIG, que lee el identificador msgh_id del mensaje y en base a él, llama al manejador específico correspondiente. Esto fue confirmado vía depuración con LLDB observando la interacción real del sistema en runtime, incluso cuando se realizaban acciones habituales del usuario como cambiar el volumen.
Al establecer el “fuzzing harness”, fue necesario superar varios obstáculos propios del entorno. Inicialmente, la ausencia de exportación de la función objetivo requería técnicas de recuperación de símbolos tipo las empleadas por TinyInst. A su vez, el sistema espera que la capa HAL (Hardware Abstraction Layer) esté inicializada y en estado adecuado para procesar mensajes, situación que no se cumplía al invocar directamente la función con datos manipulado, lo que demandó llamar rutinariamente a funciones de arranque del sistema HAL para preparar el entorno. Otro reto importante fue la necesidad de simular una interacción continua, dado que los handlers de mensajes Mach para coreaudiod mantienen estado y dependen unos de otros. Esto significaba que no bastaba enviar un solo mensaje; la fuzzer debía generar flujos secuenciales para registrar clientes y preparar el sistema antes de que mensajes más complejos fueran aceptados.
El concepto de API Call Chaining aplicado ayudó a que una única entrada de datos modulada se tradujera en una serie de llamadas válidas entrelazadas, aumentando notablemente la exploración de código. Durante la fase de fuzzing, fue también inevitable contar con un corpus inicial de mensajes legítimos para facilitar el aprendizaje del fuzzer, que luego se complementó con inputs generados automáticamente. La aplicación Audio MIDI Setup se usó para provocar envíos reales a coreaudiod, que pudieron ser capturados y volcados en un formato entendible. Las limitaciones del entorno hicieron imprescindible crear mocks y bypasses para ciertas funciones, evitando errores inexistentes en la operación real o caídas inducidas por llamadas erróneas a librerías de sistema. Técnicas como la interposición de funciones en C y hooks en C++ proporcionaron un ecualizador entre la realidad del demonio coreaudiod en ejecución y las condiciones del fuzzing relativo en un espacio aislado.
Un punto decisivo fue la incorporación gradual de un entendimiento más detallado de la estructura esperada en los mensajes y la forma correcta de formatear campos críticos para pasar los chequeos internos de los manejadores. De otro modo, la fuzzer se frustraba con fallas prematuras o pérdidas abruptas de cobertura. Gracias a esta serie de ajustes y optimizaciones, se logró identificar varias caídas y, más importante aún, un fallo de alta gravedad dentro del demonio coreaudiod, específicamente relacionado con una vulnerabilidad de confusión de tipos (type confusion) en la manipulación de objetos HALS. Este defecto radicaba en que algunos manejadores de mensajes Mach asumían equivocadamente que un objeto recuperado tenía un tipo específico (ioct), lo que llevaba a desreferenciar punteros erróneos y, eventualmente, a la ejecución de código arbitrario o fallas de memoria. Las implicancias de esta vulnerabilidad son severas porque, mediante el envío manipulado de mensajes Mach, un atacante podría aprovechar la inconsistencia para corromper la memoria o alterar el flujo de ejecución con privilegios elevados, lo que originalmente estaba protegido por sandbox.
Particularmente, la función _XIOContext_Fetch_Workgroup_Port fue uno de los manejadores afectados, con otros varios que compartían la misma falla de validación insuficiente. Se confirmó que este hallazgo era explotable mediante el envío de mensajes Mach legítimos usando la API mach_msg, lo que descartó falsos positivos derivados de aquel entorno controlado de fuzzing. El reporte fue entregado a Apple en octubre de 2024, y posteriormente solucionado con un parche liberado en diciembre del mismo año, asignándose el CVE-2024-54529. La solución aplicada consiste en añadir verificaciones estrictas sobre el tipo de objeto que se extrae antes de realizar cualquier operación o llamada a funciones miembro, ajustando inclusive offsets de campos dentro de las estructuras para evitar errores de lectura. Esta práctica generalizada es un estándar contra vulnerabilidades de tipo confusión y asegura que el sistema maneje de forma segura y consistente las comunicaciones vía IPC.
Finalmente, la experiencia y resultados demuestran la potencia del enfoque "knowledge-driven fuzzing" en la investigación de seguridad de sistemas complejos como macOS. Combinar automática exploración de inputs con análisis profundo y construcción iterativa de un entorno de pruebas robusto, permite descubrir vulnerabilidades críticas que pueden tener un impacto significativo en la seguridad del ecosistema. Se espera que la segunda parte de este estudio profundice en la explotación práctica de la vulnerabilidad detectada, aportando detalles técnicos sobre cómo esta falla puede ser usada como una vía para burlar mecanismos de aislamiento y obtener ejecución de código con elevados privilegios en macOS. La labor de investigación evidencia asimismo la importancia de continuar desarrollando herramientas y técnicas para auditar en profundidad puntos de comunicación internos de sistemas operativos modernos, manteniendo así un estándar elevado de seguridad para todos sus usuarios.
