iLeakage: ataque de ejecución especulativa sin temporizador basado en navegador contra dispositivos Apple

• Aunque las mitigaciones contra Spectre llevan casi 6 años, iLeakage muestra que los canales laterales de ejecución especulativa aún pueden explotarse en Safari en Mac, iPad y iPhone
• Un atacante puede inducir al usuario a visitar una página web maliciosa y hacer clic; luego, con JavaScript y WebAssembly, puede hacer que Safari renderice páginas web arbitrarias y recupere información sensible
• Las demostraciones incluyen la recuperación de títulos de mensajes recientes de Gmail, credenciales de autocompletado de Instagram, historial de visualización de YouTube, y la contraseña de Facebook y un token SMS de 2FA en una MacBook Pro con Apple M3
• El alcance afecta dispositivos macOS e iOS que usan CPU Apple A-series y M-series, y fue mitigado en iOS 17.2 y macOS 14.2, que incluyen Safari 17.2
• También puede bloquearse con Lockdown Mode o desactivando JavaScript, pero hay restricciones funcionales; además, como se ejecuta dentro de Safari y no deja rastros en los logs del sistema, es muy difícil de detectar

---

El riesgo de Spectre vuelve a quedar expuesto en dispositivos Apple

• iLeakage es un ataque de canal lateral de ejecución especulativa dirigido al navegador web Safari
• Apunta a dispositivos macOS e iOS que usan CPU A-series o M-series de Apple
  • Incluye iPhone y iPad recientes
  • También incluye laptops y computadoras de escritorio de Apple desde 2020
• En principio, el código de una pestaña del navegador no debería poder inferir el contenido de otra pestaña, pero iLeakage puede leer el contenido de una página web objetivo de un usuario que visita y hace clic en la página del atacante
• La información recuperable puede incluir datos personales, contraseñas e información de tarjetas de crédito
• Los investigadores revelaron los resultados a Apple el 12 de septiembre de 2022, 408 días antes del lanzamiento público

Datos sensibles recuperados en la práctica

• Los investigadores demostraron casos de recuperación de información de alto valor en servicios populares

• Credenciales de Instagram

  • Usaron un escenario en macOS Safari donde el usuario inicia sesión en Instagram con el administrador de credenciales de autocompletado LastPass

• Bandeja de entrada de Gmail

  • Asumiendo que el usuario tenía una sesión iniciada en Google en iOS Safari, recuperaron en un iPad los títulos de mensajes recientes de una cuenta de Gmail

• Historial de visualización de YouTube

  • Recuperaron el historial de visualización de YouTube en Chrome para iOS
  • Chrome para iOS funciona como una capa sobre el motor de navegación de Safari debido a las políticas de la Apple App Store

• Contraseña de Facebook y token 2FA

  • Primero recuperaron la contraseña de Facebook en un entorno con una MacBook Pro con chip Apple M3, macOS 14.1.1 y Safari 17.1
  • Luego recuperaron, mediante Google Messages, el token SMS de 2FA enviado a un teléfono Android

Cómo funcionan Spectre y los canales laterales

• La mayoría de las CPU modernas usan ejecución especulativa: cuando el resultado de una bifurcación no está disponible de inmediato, predicen la ruta de ejecución y procesan primero las instrucciones de esa ruta
• Si la predicción es incorrecta, la CPU revierte los cambios de estado, pero pueden quedar rastros en el estado microarquitectónico, como la caché
• Spectre es una vulnerabilidad de hardware que aprovecha esos rastros para leer datos que, según la semántica original del programa, no deberían ser accesibles
• Los canales laterales pueden explotar características de implementación del sistema incluso cuando el programa ejecuta un algoritmo seguro
  • Algunos ejemplos son sonido, radiación electromagnética, thermal throttling y uso compartido de recursos microarquitectónicos de la CPU
• Cuando el atacante y el objetivo se ejecutan en la misma CPU, comparten recursos como núcleos, caché y buffers internos; esta contención puede medirse indirectamente mediante variables como tiempos o consumo de energía

Construcción de un ataque sin temporizador que esquiva las defensas de Safari

• Desde Spectre, los proveedores de navegadores han reforzado sus defensas contra ataques de ejecución especulativa y ejecución transitoria
• Las defensas de Safari incluyen 35-bit addressing, value poisoning, una política de aislamiento de procesos por pestaña y temporizadores de baja resolución
• iLeakage es la primera demostración de un ataque de ejecución especulativa contra CPU Apple Silicon y Safari
• El ataque comienza recuperando empíricamente la configuración de caché no publicada de las CPU Apple
  • Luego crea un gadget basado en especulación que distingue aciertos y fallos de caché usando solo temporizadores de baja resolución
  • También se demuestra una variante que aprovecha una race condition sin usar temporizadores
• Este gadget se usa tanto para pruebas de creación de eviction set como para el covert channel
• Tras trasladar la técnica a Safari, hacen que Safari ejecute código para un tipo de dato específico sobre un objeto de tipo incorrecto creado por el atacante mientras la CPU está en ejecución especulativa
• Al final, se vuelve posible realizar una lectura fuera de límites en cualquier lugar del espacio de direcciones del proceso de renderizado de Safari
• Combinado con un nuevo método que consolida sitios web de distintos dominios en el mismo espacio de direcciones, realizan un ataque de type confusion especulativo que filtra información sensible

Mitigaciones, dificultad de detección e impacto por navegador

• iLeakage fue mitigado en Safari 17.2, incluido en iOS 17.2 y macOS 14.2
  • La medida recomendada es actualizar los dispositivos Apple a la versión más reciente del sistema operativo
• Lockdown Mode mitiga iLeakage al desactivar la compilación JIT de Safari
  • La compilación JIT es una función de rendimiento que iLeakage usa para crear primitivas de ataque
  • Lockdown Mode puede cambiar el comportamiento del dispositivo, por ejemplo, bloqueando algunos adjuntos de mensajes y llamadas FaceTime desconocidas
  • La lista completa está en la documentación de Lockdown Mode de Apple
• Desactivar JavaScript también bloquea iLeakage, pero puede hacer que Safari renderice algunos sitios web de forma incorrecta o incompleta, y que funciones web avanzadas como pagos en línea no funcionen
• iLeakage se ejecuta dentro de Safari y no deja rastros en los archivos de log del sistema, por lo que es muy difícil de detectar
  • Sin embargo, las visitas a la página web del atacante podrían quedar en la caché del navegador de páginas visitadas recientemente
• No hay evidencia de explotación real
  • La construcción de un ataque de extremo a extremo es muy difícil y requiere conocimientos avanzados sobre ataques de canales laterales basados en navegador y sobre la implementación de Safari
• Se recomienda seguir usando administradores de credenciales
  • iLeakage puede recuperar credenciales autocompletadas en una página web
  • Muchas plataformas requieren interacción del usuario para que ocurra el autocompletado
• En macOS, Chrome, Firefox y Microsoft Edge usan motores de JavaScript distintos, por lo que iLeakage, que explota particularidades del motor de JavaScript de Safari, no funciona en ellos
• En iOS, debido a las políticas de la Apple App Store y de sandboxing, otras apps de navegador también usan el motor de JavaScript de Safari
  • Chrome, Firefox y Edge para iOS son wrappers sobre Safari que ofrecen funciones auxiliares como sincronización de marcadores y configuración
  • Casi todas las aplicaciones de navegador de la App Store son vulnerables a iLeakage
• El artículo académico está disponible como iLeakage paper y fue publicado en la 2023 ACM Conference on Computer and Communications Security

[GN⁺]

Opiniones de Hacker News

• Parece que falta algo en estas FAQ: me pregunto si esto es una vulnerabilidad de WebKit o de Safari, si se mitiga activando Lockdown Mode en Safari móvil, donde no existe esa configuración para desarrolladores, y cuándo se divulgó a Apple.
  Luego la página se actualizó y ya hay respuesta para la última pregunta: los investigadores divulgaron sus hallazgos a Apple el 12 de septiembre de 2022, 408 días antes del lanzamiento público.

  • Técnicamente se podría ver como una vulnerabilidad del procesador favorito de Hacker News, es decir, una vulnerabilidad de M1/M2, pero todos los CPU relevantes del mercado actual tienen la misma debilidad, así que terminó convirtiéndose en una característica para la que el software debe diseñar mitigaciones.
    Como no es realista eliminar de WebKit todos los gadgets Spectre posibles, los navegadores deberían aprovechar las mitigaciones de Spectre del sistema operativo aislando distintos sitios web en distintos procesos.
    Dado que las FAQ dicen que “al final se logra una lectura fuera de límites en cualquier parte del espacio de direcciones del proceso de renderizado de Safari”, personalmente lo veo como una vulnerabilidad por una mala implementación del aislamiento de sitios de Safari.
  • La última pregunta está respondida en las FAQ: los investigadores divulgaron sus hallazgos a Apple el 12 de septiembre de 2022, 408 días antes del lanzamiento público.
  • Esto parece una vulnerabilidad arquitectónica que permite aprovechar un canal lateral de ejecución especulativa similar a Spectre dentro de Safari u otros navegadores.
    En qué entornos puede explotarse depende de los detalles de implementación de los gadgets basados en JavaScript que provocan y miden este canal lateral, y eso quizá esté en el paper, que todavía no leí.
  • Ahora ya subieron la respuesta a las FAQ: es una vulnerabilidad de Safari y dicen que “iLeakage explota características del motor JavaScript de Safari”.
    Lockdown Mode desactiva la compilación JIT en Safari, por lo que sirve como mitigación, ya que bloquea las funciones de rendimiento que iLeakage usa para crear las primitivas de ataque.

• Sobre “¿es peligroso usar un gestor de credenciales?”, la mayoría responde que no, pero si lo que se filtra es algo de memoria, ¿no debería afectar a toda la memoria dentro del espacio de procesos de Safari?
  No estoy familiarizado con esta área, así que no termino de entender por qué usar o no un gestor de credenciales sería una condición excepcional.

  • Básicamente parecen decir esto: no aporta seguridad adicional contra este ataque específico, pero usar un gestor de contraseñas suele ser más seguro en general y tampoco te vuelve más vulnerable a este ataque.
    Creo que quieren evitar que la gente vuelva a cosas como “newpassword2”; si se desactiva el autocompletado y se rellena mediante un atajo de teclado u otra interacción del usuario, es más seguro.
  • Una de las demos consistía en recuperar la combinación de usuario/contraseña de un sitio de terceros como Instagram gracias a que el gestor de contraseñas había autocompletado los campos y los datos estaban en memoria.
    Podría leerse como que, si no usas un gestor de contraseñas, tampoco las guardas en el navegador y las escribes manualmente cada vez, eres inmune, pero ese es un mal contraargumento por varias razones.
    Los gestores de contraseñas son útiles por muchas otras razones y, aunque te roben una contraseña, al menos solo se compromete un sitio web.
    Esta técnica probablemente también pueda robar tokens de sesión, lo cual, aunque no sea tan grave como robar contraseñas, sigue siendo malo.
    Configurar el gestor de contraseñas para que solo rellene al hacer clic también puede bloquear este ataque.
  • Parece que quieren decir que usar un gestor de contraseñas no te hace más vulnerable.
    Una contraseña autocompletada en una página puede recuperarse igual que una contraseña escrita manualmente, pero no pueden leer directamente todas las contraseñas almacenadas dentro del gestor de contraseñas.
  • Entiendo que esta vulnerabilidad solo permite acceder a la memoria del proceso Safari/WebKit relacionado, específicamente a los sitios abiertos mediante llamadas a window.open.
    No se puede acceder a contraseñas guardadas en una app separada de gestión de contraseñas a menos que esa app las autocomplemente en una ventana o proceso de Safari comprometido.
  • Entiendo que Safari normalmente coloca distintos orígenes y extensiones en distintos espacios de direcciones, por lo que no sería vulnerable a ataques de ejecución especulativa.
    Este ataque encontró una forma de hacer que dos orígenes distintos compartan el mismo espacio de direcciones, y creo que no aplica a extensiones.
    El paper dice: “Mostramos una nueva técnica que explota la política de aislamiento de sitios de Safari, haciendo que una página atacante comparta el espacio de direcciones con una página víctima arbitraria simplemente abriéndola mediante la API JavaScript window.open”.

• Me confunde si realmente es correcto enmarcarlo como algo exclusivo de WebKit. El abuso de caché en sí parece algo general, y la cita también dice que mostró una precisión casi perfecta en Safari, Firefox y Tor.
  Además, me pregunto si el ataque mediante window.open() es realmente exclusivo de WebKit, o si en esta investigación solo analizaron WebKit en profundidad.
  window.open() implica un contexto compartido en el que la ventana que llama recibe una referencia a la nueva ventana, y la nueva ventana tiene una referencia inversa mediante window.opener; me pregunto si otros motores de navegador logran un aislamiento completo.

  • Chromium y Firefox implementaron aislamiento de sitios en navegadores de escritorio, por lo que páginas que no pertenezcan al mismo sitio no deberían cargarse en el mismo proceso.
    En navegadores móviles, el aislamiento de sitios de Chromium es limitado, y Firefox aún no terminó de implementarlo.
    https://www.chromium.org/Home/chromium-security/site-isolati...

• Confuso. Esto parece un problema de alta gravedad, pero la corrección está detrás de un menú de depuración. No entiendo por qué se hizo público antes de desplegarse correctamente en todas partes.
  Además, también demuestra que las mitigaciones contra canales laterales son prácticamente inútiles y que no deberíamos fingir que ataques como este ya fueron corregidos.
  En un host que ejecuta varias aplicaciones en una CPU moderna, por mucho sandboxing que haya, no es seguro ejecutar código no confiable.

  • Parece que Apple tuvo más de 400 días para arreglar esto, y eso ya es más tiempo del que yo le habría dado.
    Creo que es mucho mejor informar del riesgo que dejar a los usuarios de Apple más de otro año sin saber que están en peligro.
    Estoy a favor de darles tiempo a las empresas para corregir bugs, pero a partir de cierto punto se vuelve más irresponsable no avisarles a las personas afectadas.
  • El estado de las mitigaciones también me confunde, pero el paper es más claro que el sitio web.
    El paper explica que el escape del sandbox de JavaScript especulativo sigue siendo posible, pero que el atacante queda limitado a su propio espacio de direcciones y a leer sus propios datos.
    Dice que, al momento de escribirlo, el parche de Apple ya era público y estaba implementado en Safari Technology Preview 173 o superior, y [57] es https://github.com/WebKit/WebKit/pull/10169.
    Debajo de eso, el ingeniero sigue enlazando parches adicionales de refuerzo para window.open() y el aislamiento de procesos.
  • Creía que en Safari 17.0 estándar en Ventura, Swap Processes on Cross-Site Window Open ya estaba activado y marcado como estable.
    Como yo no lo activé manualmente, pensé que quizá Apple ya lo había habilitado y la descripción estaba desactualizada, pero después vi que estaba mirando Swap Processes on Cross-Site Navigation, que tiene un nombre parecido, y parece que actualmente no está activado por defecto.
  • Es porque Apple, “el último bastión de la privacidad y la seguridad”, tuvo esto en sus manos más de 400 días y aun así no lo corrigió.
    Hay que culpar más a Apple por quedarse de brazos cruzados tanto tiempo que a los investigadores por publicarlo antes de que se distribuyera la corrección.
  • Como esta corrección requería cambiar el modelo de procesos de WebKit, es muy probable que todavía esté en pruebas antes del despliegue completo y por eso esté detrás de un menú de depuración.
    No todos los ataques de canal lateral se han corregido, pero decir que las mitigaciones contra canales laterales son inútiles no corresponde.
    Así como la gente puede morir en accidentes de auto aunque use cinturón de seguridad, pero eso no significa que el cinturón sea inútil, las mitigaciones aumentan mucho la dificultad de explotación.

• Dicen que “los investigadores revelaron sus resultados a Apple el 12 de septiembre de 2022”; de verdad me da curiosidad por qué Apple lo dejó prácticamente abandonado más de un año.

  • Porque puede hacerlo.
    Apple es uno de los actores con poder sobre los CVE, así que puede negarse a emitir CVE para sus propios productos, y si tiene ese poder puede moverse tan lento como quiera.

• Creo que vi en el sitio web de iLeakage una frase relacionada con la corrección, pero desapareció. Pensé que me había confundido, pero en realidad el sitio estuvo cambiando durante la última hora.
  Había una frase que decía “Apple acaba de lanzar iOS 17.1, iPadOS 17.1 y macOS Sonoma 14.1, así que actualiza tus dispositivos”, y ahora la revirtieron.
  https://github.com/ileakage-authors/ileakage-authors.github....

  • Parece que uno de los autores del paper está leyendo este hilo.
    Cuando señalé que el sitio no tenía un cronograma de divulgación, agregaron una sección breve al FAQ, y con la confusión sobre si la corrección ya se había desplegado, parece que los investigadores también se confundieron.
  • Raro. Actualicé a iOS 17.1 y en Settings -> Safari -> Advanced -> Feature Flags aparece Swap Processes on Cross-Site Navigation, activado por defecto.
    Me pregunto si es distinto de Swap Processes on Cross-Site Window Open en macOS.

• La frase “iLeakage es un ataque bastante difícil de ejecutar de principio a fin y requiere conocimientos avanzados de ataques de canal lateral basados en navegador y de la implementación de Safari” quizá sea la razón por la que a Apple no le preocupa demasiado.

  • Parece querer decir que es tan difícil de ejecutar que en la práctica es imposible, y que el riesgo real está cerca de 0%.
    Ponerle además otro nombre aterrador y un dominio propio no parece ni profesional ni confiable.

• Si esto afecta a dispositivos macOS o iOS con CPU Apple serie A o serie M, es decir, iPhone/iPad recientes y laptops/escritorios Apple desde 2020, entonces como uno de los raros usuarios de Intel Mac, parece que no me afecta.

  • Probablemente sí te afecte.
    Solo la jerarquía de caché es un poco diferente, y la prueba de concepto necesitaría algunos cambios.
  • Si es macOS, basta con no usar Safari.
    Si es iOS, hay que usar Lockdown Mode, y esa es la única forma de usar un iPhone de manera segura.
    Un benchmark hecho sin Lockdown Mode debería considerarse tan inútil como correr un benchmark de CPU con mitigations=off.

• Otra buena razón para permitir otros motores de navegador en dispositivos iOS.

  • La regulación de la UE quizá termine obligando a Apple.

• Si aparece un error al ejecutar el siguiente comando, concede Full Disk Access a la terminal e inténtalo de nuevo.
  defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1