Vulnerabilidad de corrupción de memoria del kernel de macOS revelada por primera vez en Apple M5

 (blog.calif.io)
2 puntos por GN⁺ 2026-05-15 | 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 activado, y los detalles técnicos completos se publicarán después de que Apple aplique una corrección
  • El objetivo es macOS 26.4.1 (25E253), y pasa de un usuario local sin privilegios a una root shell usando únicamente llamadas normales al sistema
  • La implementación usó dos vulnerabilidades y varias técnicas, y Calif lo considera el primer exploit público del kernel de macOS en hardware con MIE
  • Mythos Preview ayudó en la identificación de bugs y en el desarrollo del exploit, pero para evadir mitigaciones nuevas como MIE todavía se necesitan expertos humanos

Exploit del kernel de macOS que superó MIE en el 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) activado
  • 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 empieza desde un usuario local sin privilegios, usa únicamente llamadas normales al sistema y termina en una root shell
  • La implementación incluyó dos vulnerabilidades y varias técnicas, y después de que Apple corrija las vulnerabilidades y la ruta de ataque, se publicarán un informe de 55 páginas y todos los detalles técnicos
  • El cronograma avanzó rápidamente
    • Bruce Dang encontró 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 considerando tanto rendimiento como seguridad, y elevó la dificultad de evasión al controlar toda la pila
  • MIE es un sistema de seguridad de memoria con soporte por hardware basado en MTE (Memory Tagging Extension) de ARM, e introducido como una función de seguridad clave en Apple M5 y A19
  • Según la investigación de Apple, MIE interrumpe todas las cadenas de exploit públicas contra iOS moderno, incluidos los kits de exploit filtrados recientemente Coruna y Darksword
  • Calif ha estado explorando cómo la IA puede contribuir a construir exploits que funcionen incluso en entornos MTE, y como el MIE de Apple, centrado en iOS, también se aplica al M5 de las MacBook más recientes, se abrió una posible ruta de ataque sobre macOS
  • Mythos Preview ayudó en la identificación de bugs y en todo el desarrollo del exploit, y en tipos de problemas que ya aprendió 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 evadir de forma autónoma mitigaciones nuevas de primer nivel como MIE sigue siendo territorio de expertos humanos
  • Calif puso a prueba el alcance de lo que es posible cuando se combinan modelos de primer nivel y 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 puede evitarse si existe una vulnerabilidad adecuada
  • En la serie MAD Bugs, consideran que los sistemas de IA están descubriendo cada vez más vulnerabilidades, y que algunos de ellos pueden llegar a ser lo bastante potentes como para superar mitigaciones avanzadas como MIE
  • Cuando Apple creó MIE, no existía un entorno como Mythos Preview, y este trabajo es un resultado temprano que muestra la presión que el descubrimiento de bugs basado en IA ejerce sobre las técnicas avanzadas de mitigación

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-05-15
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