Cómo mitigar la vulnerabilidad SRBDS (CVE-2020-0543) sin reiniciar el servidor

Recientemente, académicos del Grupo de Seguridad de Sistemas y Redes de la Vrije Universiteit (VUSec) han publicado detalles sobre la vulnerabilidad CrossTalk o SRBDS (CVE-2020-0543) en procesadores Intel. La vulnerabilidad CrossTalk permite que el código controlado por un atacante que se ejecuta en un núcleo de CPU filtre datos sensibles de otro software que se ejecuta en un núcleo diferente. En este artículo, te mostraremos cómo mitigar esta vulnerabilidad de CPU Intel sin reiniciar el servidor.

¿Qué es CrossTalk?

La vulnerabilidad CrossTalk es un tipo de ataque MDS (muestreo de datos microarquitectónicos), similar a Spectre, Meltdown o Zombieload. Permite la exposición y el robo de datos sensibles mientras la máquina los accede. Los ataques MDS apuntan a datos de usuario mientras están en un estado transitorio, ya que han estado residiendo dentro de la CPU y muchos sistemas conectados a ella.

La vulnerabilidad SRBDS/CrossTalk es una vulnerabilidad de ejecución transitoria. Nombrada como “Muestreo de Datos del Búfer de Registro Especial” o SRBDS (CVE-2020-0543) por Intel, permite que el código controlado por un atacante que se ejecuta en un núcleo de CPU resulte en el filtrado de datos sensibles de software víctima que se ejecuta en un núcleo diferente.

Figura 1: Diseño de la etapa de perfilado de instrucciones de CrossTalk, cortesía de VUSec

Cualquier sistema que esté utilizando una CPU Intel puede verse afectado por esta vulnerabilidad. Verifica aquí si tu CPU está afectada.

Mitigación sin reinicio de la vulnerabilidad SRBDS (CVE-2020-0543)

Intel ha implementado su mitigación para la vulnerabilidad SRBDS en una actualización de microcódigo distribuida a los proveedores de software el martes 9 de junio de 2020. Esta mitigación requiere la instalación de los últimos parches del Kernel de Linux y la actualización de microcódigo. Ambas operaciones se realizan tradicionalmente al reiniciar.

Si reiniciar un par de servidores no suena como un problema, si eres un SysAdmin que se encarga de más de 500 servidores, seguro que lo es. Reiniciar toda una flota de servidores generalmente requiere una planificación exhaustiva de la ventana de mantenimiento. Afortunadamente, la tecnología de parches en vivo permite aplicar actualizaciones de seguridad a los sistemas contra CrossTalk sin un reinicio, tanto para la actualización de microcódigo como para la aplicación de parches del kernel de Linux.

Canonical, Red Hat y otros proveedores de distribución han lanzado los parches de seguridad para todas las distribuciones de Ubuntu soportadas, Debian, CentOS, Red Hat Enterprise Linux. Y, aunque Canonical y Red Hat tienen su propia solución para parchear vulnerabilidades sin un reinicio, en el caso de SRBDS/CrossTalk aún necesitas reiniciar un escritorio o un servidor después de la actualización.

El equipo de KernelCare ha creado una mitigación sin reinicio para CrossTalk/SRBDS para que puedas evitar reiniciar los servidores para aplicar los parches. Encuentra las instrucciones a continuación:

A) Si estás ejecutando en hardware, sigue 3 pasos para proteger tus servidores de la vulnerabilidad CrossTalk/SRBDS sin un reinicio:

Paso 1: Regístrate para una licencia de prueba gratuita de KernelCare

KernelCare es gratuito para usar durante 30 días en todos tus servidores, no se requiere tarjeta de crédito para registrarse en una prueba. También es gratuito para organizaciones de salud durante el resto de 2020 y siempre será gratuito para organizaciones sin fines de lucro.

Paso 2: Actualizar Microcódigo sin un reinicio

Ejemplo: Actualización de microcódigo en RHEL

Este es el ejemplo de una actualización de microcódigo sin reinicio en RHEL. Las instrucciones para Debian, Ubuntu, CentOS y otras distribuciones se pueden encontrar en la Documentación de KernelCare.

Para distribuciones basadas en RHEL, puedes usar la utilidad microcode_ctl para actualizar el microcódigo.

Antes de comenzar, verifica aquí si los parches para tu distribución están listos. La página se actualiza cada hora.

Obtén el último microcódigo actualizando el paquete microcode_ctl

yum update microcode_ctl

Crea un force-late-intel–06–4f–01 dentro del directorio de firmware.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

Ejecuta la actualización de microcódigo

/usr/libexec/microcode_ctl/update_ucode

Fuerza al kernel a cargar el nuevo microcódigo

echo 1 > /sys/devices/system/cpu/microcode/reload

Verifica el nuevo microcódigo

dmesg | grep microcode  
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12  
[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba  
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13  
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

(Opcional) Verifica nuevamente la nueva versión de microcódigo (revisiones por núcleo)

cat /proc/cpuinfo | grep -e microcode  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21

Paso 3: Aplica los parches de KernelCare

Ahora necesitas actualizar el Kernel de Linux para asegurarte de que el usuario local no pueda leer los datos que estás ejecutando en la CPU. Con KernelCare puedes hacer eso sin reiniciar. Si te registraste para la prueba en el Paso 1, ya estás listo y no tienes que hacer nada más.

B) Si estás ejecutando en VM:

Solo necesitas parchear el Kernel de Linux dentro de la VM. Asegúrate de que tu nodo host también esté actualizado, lo cual es típicamente realizado por tu proveedor de servicios.

Si estás usando tu KernelCare, tus parches serán entregados automáticamente por KernelCare y no necesitas hacer nada extra. Si no, regístrate para una prueba gratuita de 30 días.