Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer información sobre una vulnerabilidad identificada en el kernel de Linux 6.2 (ya catalogada bajo CVE-2023-1998) y la cual se destaca porque esta deshabilita la protección contra ataques de Spectre v2 que permiten el acceso a la memoria de otros procesos que se ejecutan en diferentes hilos SMT o Hyper Threading, pero en el mismo núcleo de procesador físico.

La vulnerabilidad es destacable entre otras cosas porque se puede utilizar para organizar la fuga de datos entre máquinas virtuales en sistemas en la nube. 

Para quienes desconocen de Spectre, deben saber que esta es una de las dos vulnerabilidades de CPU de ejecución transitoria originales (la otra es Meltdown), que implican ataques de canal lateral de sincronización de microarquitectura. Estos afectan a los microprocesadores modernos que realizan predicciones de saltos y otras formas de especulación.

En la mayoría de los procesadores, la ejecución especulativa resultante de una predicción errónea de una rama puede dejar efectos secundarios observables que pueden revelar datos privados. Por ejemplo, si el patrón de accesos a la memoria realizados por dicha ejecución especulativa depende de los datos privados, el estado resultante de la memoria caché de datos constituye un canal lateral a través del cual un atacante puede extraer información sobre los datos privados mediante un ataque de tiempo.

Desde la divulgación de Spectre y Meltdown en enero de 2018, han surgió diversas variantes y nuevos tipos de vulnerabilidad relacionadas con estas.

El kernel de Linux permite que los procesos del espacio de usuario habiliten las mitigaciones al llamar a prctl con PR_SET_SPECULATION_CTRL, que deshabilita la función de especulación, así como al usar seccomp. Nos dimos cuenta de que en las máquinas virtuales de al menos uno de los principales proveedores de la nube, el kernel aún dejaba el proceso de la víctima expuesto a ataques en algunos casos, incluso después de habilitar la mitigación de spectre-BTI con prctl. 

Sobre la vulnerabilidad se menciona que en el espacio del usuario, para protegerse contra los ataques de Spectre, los procesos pueden deshabilitar selectivamente la ejecución de instrucciones especulativas con prctl PR_SET_SPECULATION_CTRL o usar el filtrado de llamadas del sistema basado en seccomp.

Según los investigadores que identificaron el problema, la optimización incorrecta en el kernel 6.2 dejó las máquinas virtuales de al menos un gran proveedor de nube sin la protección adecuada, a pesar de la inclusión del modo de bloqueo de ataques spectre-BTI a través de prctl. La vulnerabilidad también se manifiesta en servidores normales con el kernel 6.2, que se inician con la configuración «spectre_v2=ibrs».

La esencia de la vulnerabilidad es que al elegir los modos de protección IBRS o eIBRS, las optimizaciones realizadas deshabilitaron el uso del mecanismo STIBP (Single Thread Indirect Branch Predictores), que es necesario para bloquear fugas cuando se usa tecnología de subprocesos múltiples simultáneos (SMT o Hyper-Threading). )

A su vez, solo el modo eIBRS brinda protección contra fugas entre hilos, no así el modo IBRS, ya que con él el bit IBRS, que brinda protección contra fugas entre núcleos lógicos, se borra por razones de rendimiento cuando el control vuelve al espacio del usuario, lo que hace que los subprocesos del espacio del usuario no estén protegidos contra los ataques de la clase Spectre v2.

La prueba consta de dos procesos. El atacante envenena constantemente una llamada indirecta para redirigirla especulativamente a una dirección de destino. El proceso de la víctima mide la tasa de predicción errónea e intenta mitigar el ataque llamando a PRCTL o escribiendo en el MSR directamente mediante un módulo del kernel que expone las operaciones de lectura y escritura del MSR en el espacio del usuario.

El problema afecta solo al kernel de Linux 6.2 y se debe a una implementación incorrecta de las optimizaciones diseñadas para reducir la sobrecarga significativa al aplicar la protección contra Spectre v2. La vulnerabilidad fue corregida en la rama experimental del kernel Linux 6.3.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.