Primer exploit público de corrupción de memoria del kernel de macOS en Apple M5

 (blog.calif.io)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Ingenieros de Calif crearon un exploit de corrupción de memoria del kernel de macOS que funciona en Apple M5 y entregaron a Apple un informe de investigación sobre la vulnerabilidad
  • La cadena de exploit apunta a hardware M5 bare-metal con MIE habilitado, y todos los detalles técnicos se publicarán después de que Apple haga la corrección
  • El objetivo es macOS 26.4.1 (25E253), y pasa de un usuario local sin privilegios a una root shell usando solo llamadas al sistema normales
  • La implementación utilizó dos vulnerabilidades y varias técnicas, y Calif la considera el primer exploit público del kernel de macOS en hardware con MIE
  • Mythos Preview ayudó a identificar bugs y desarrollar el exploit, pero para eludir mitigaciones nuevas como MIE todavía se necesitan expertos humanos

Exploit del kernel de macOS que superó MIE en M5

  • Ingenieros de Calif, junto con Mythos Preview, crearon un exploit de corrupción de memoria del kernel de macOS que funciona en silicio Apple M5, y entregaron personalmente a Apple un informe de investigación sobre la vulnerabilidad en Apple Park
  • Esta cadena apunta a hardware M5 bare-metal con MIE(Memory Integrity Enforcement) habilitado
  • El objetivo es macOS 26.4.1 (25E253), y se trata de una cadena de elevación local de privilegios en el kernel, solo de datos, que comienza con un usuario local sin privilegios, usa únicamente llamadas al sistema normales y termina en una root shell
  • La implementación incluyó dos vulnerabilidades y varias técnicas, y el informe de 55 páginas junto con todos los detalles técnicos se publicarán después de que Apple corrija las vulnerabilidades y la ruta de ataque
  • El cronograma avanzó rápidamente
    • Bruce Dang descubrió el bug el 25 de abril
    • Dion Blazakis se unió a Calif el 27 de abril
    • Josh Maine creó las herramientas, y el 1 de mayo se completó un exploit funcional

El significado de MIE y Mythos Preview

  • La corrupción de memoria sigue siendo el tipo de vulnerabilidad más común, incluso en iOS y macOS, y si no puede bloquearse por completo, se necesitan mitigaciones que aumenten el costo del ataque
  • Apple incorporó muchas funciones defensivas en el hardware teniendo en cuenta tanto el rendimiento como la seguridad, y elevó la dificultad de evasión al controlar toda la pila
  • MIE es un sistema de seguridad de memoria con soporte de hardware basado en MTE (Memory Tagging Extension) de ARM, y fue introducido como una función de seguridad clave en Apple M5 y A19
  • Según la investigación de Apple, MIE interfiere con todas las cadenas de exploit públicas contra iOS moderno, incluidos los recientes kits de exploit filtrados Coruna y Darksword
  • Calif ha estado explorando cómo la IA puede contribuir a construir exploits que también funcionen en entornos MTE, y como el MIE de Apple, centrado en iOS, también se aplicó al M5 de las MacBook más recientes, se abrió una posible ruta de ataque contra macOS
  • Mythos Preview ayudó en todo el proceso de identificación de bugs y desarrollo del exploit, y para tipos de problemas que ya ha aprendido, puede generalizar incluso a problemas de tipo casi idéntico
  • La razón por la que Mythos encontró los bugs rápidamente es que esos bugs pertenecían a tipos ya conocidos, y eludir de forma autónoma mitigaciones nuevas de primer nivel como MIE sigue siendo terreno de expertos humanos
  • Calif puso a prueba el alcance de lo posible cuando se combinan modelos de primer nivel con expertos, y esa combinación pudo completar en una semana un exploit de corrupción de memoria del kernel contra protecciones de máximo nivel
  • MIE no es un mecanismo diseñado para detener por completo a los hackers, y si existen vulnerabilidades adecuadas, puede ser evitado
  • En la serie MAD Bugs, consideran que los sistemas de IA están encontrando cada vez más vulnerabilidades, y que algunas de ellas podrían volverse lo bastante potentes como para superar mitigaciones avanzadas como MIE
  • Cuando Apple creó MIE, no existían entornos como Mythos Preview, y este trabajo es un resultado temprano que muestra la presión que el descubrimiento de bugs basado en IA está ejerciendo sobre las técnicas avanzadas de mitigación

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • Viendo solo la demostración, en la plataforma de recompensas por bugs de Apple esto parece una vulnerabilidad de 100 mil dólares, pero si la presentan bien podría convertirse en una de 1.5 millones de dólares
    Bastaría con reproducirla en una versión beta de macOS, clasificarla como acceso no autorizado y, si es posible, mostrarla también en modo de bloqueo

    • Esto parece una escalada local de privilegios (LPE), y lo que se mencionó arriba se acerca más a una ejecución remota de código sin clics (RCE)

  • Parece que el mundo no estaba nada preparado para el impacto de los LLM en los problemas de seguridad
    Si es cierto, felicidades al equipo de Calif, y aunque los detalles son demasiado técnicos como para entenderlos por completo, estoy esperando el informe de 55 páginas

    • Yo también estoy de acuerdo, pero lo que me preocupa es la gente
      Se escucha por todos lados que desarrolladores están metiendo en producción cambios de código generados por LLM sin entender bien ni siquiera qué están desplegando
      A medida que esos cambios se acumulan, baja la comprensión del código base y el comportamiento se vuelve más riesgoso
      Peor aún, este tipo de comportamiento está siendo impulsado por el liderazgo, directa o indirectamente. Ya sea con metas de velocidad irreales, ascensos por iniciativas vagas de "usar IA", sobrecargar a los desarrolladores que quedaron después de despidos, o poner a desarrolladores inexpertos en roles senior
      Parece que una gran parte de la industria se está volviendo loca mientras intenta reaprender, a las malas, los fundamentos de la seguridad
    • Suena como si estuvieran asumiendo que los blue teams y los ingenieros no están haciendo nada

  • Los LLM van a crear una enorme cantidad de vulnerabilidades estilo Rube Goldberg en los próximos años
    Ya empezó, y aunque este caso no sea uno de esos, de verdad está pasando

    • Puede que, en teoría, sea físicamente imposible construir un sistema completamente seguro
      Algo así como decir que no existe una célula invulnerable a cualquier virus
      Tal vez hasta ahora sobrevivimos gracias a una especie de seguridad por oscuridad, y esa oscuridad tal vez solo significaba que nadie tenía el tiempo ni la concentración para analizar realmente el código
    • Me pregunto si con eso quieren decir que van a introducir esas vulnerabilidades en el kernel con vibe coding, o que las van a encontrar

  • Lamentablemente faltan bastantes detalles
    Tengo mucha curiosidad por saber cómo el bug logró pasar MTE

    • Memory Tagging Extension
      Arm publicó en 2019 la especificación de Memory Tagging Extension (MTE) como una herramienta para ayudar al hardware a detectar bugs de corrupción de memoria
      MTE es un sistema de etiquetado y verificación de etiquetas en memoria que asigna un valor secreto como etiqueta a cada asignación de memoria
      Luego, el hardware solo permite el acceso cuando la solicitud de acceso a memoria incluye el valor secreto correcto
      Si el valor secreto no coincide, la app se cae y se registra el evento, lo que permite a los desarrolladores identificar bugs de corrupción de memoria en cuanto ocurren
      https://support.apple.com/guide/security/operating-system-in...
    • Después de leer más sobre los ataques de solo datos, ya lo entendí
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      Como el programa en realidad no cambia, no se fuerza ninguna operación que haga que MTE tenga que intervenir, así que MTE no se activa
      La otra duda que tengo es por qué Apple no usó aquí verificaciones de fbounds
      Porque en otros lugares las ha aplicado de forma bastante agresiva
      Usar MTE junto con verificaciones integrales de fbounds podría hacer que el sistema operativo fuera extremadamente sólido
    • La memoria de GPU, los shaders, etc., no están protegidos por MTE ni PAC
      Como dijeron "data-only", puede que un comando de GPU encaje aquí
    • Yo tuve la misma pregunta, y si esto es un ataque de solo datos, tal vez la lección sea que MIE, aunque reduce muchas rutas de ataque, no elimina por completo todas las primitivas de corrupción útiles
    • No es la primera vez que un bug pasa MTE
      El año pasado pasó algo parecido en Google Pixel
      https://github.blog/security/vulnerability-research/bypassin...

  • Sorprende que Apple todavía no use bien internamente Swift, supuestamente un lenguaje seguro
    Da la impresión de que todo Swift 6 fue casi puro marketing

    • Sí lo usan, sin duda
      Una de las razones por las que salió Embedded Swift es precisamente reemplazar algo mejor el firmware iBoot, que hoy está escrito en un dialecto de C con ideas parecidas a Fil-C
      Pero esto no es diferente del kernel de Linux
      Que se haya permitido Rust no significa que hayan reescrito todo el mundo, y nadie en su sano juicio intentaría reescribir el kernel con Claude
    • Apple claramente sí usa Swift
      Hace poco lo agregaron al parser de CSS de Safari, y también funciona de forma embebida en partes del Secure Enclave
      Según entiendo, desde la época de Strangeloop se hablaba de meterlo en el kernel, aunque no sé qué tanto ha avanzado eso
      Aparte de eso, Apple ha impulsado fuertemente las verificaciones de fbounds en clang, y eso puede lograr una parte pequeña pero importante de lo que ofrecen los lenguajes con seguridad de memoria
      También me gustaría ver una adopción mayor de Swift o de lenguajes alternativos, y siempre es bienvenida más competencia en el espacio de lenguajes seguros
    • Puede que te interese la opción Strict Memory Safety
      https://docs.swift.org/compiler/documentation/diagnostics/st...

  • Compré un M5 a propósito por MIE, y ahora me siento medio tonto

    • No hace falta
      MTE bloquea una gran categoría de vulnerabilidades y hace que técnicas como ROP y JOP ahora sean muy difíciles o prácticamente imposibles
    • Deberías preocuparte más por el malware de npm/PyPI que por los bugs de corrupción de memoria

  • ¿Editaron el artículo? No explica mucho lo de la visita presencial

  • Esto parece otro caso de marketing exagerado para Mythos
    El informe sobre curl fue mucho más sobrio
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • Esta gente no trabaja ni en Apple ni en Anthropic