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 Universidad de Vrije (VUSec) han publicado detalles sobre CrossTalk o SRBDS (CVE-2020-0543) en los procesadores en los procesadores Intel. La vulnerabilidad CrossTalk permite que el código controlado por un atacante que se ejecuta en un núcleo de la 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 la CPU de Intel sin necesidad de 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 exponer y robar datos sensibles mientras la máquina accede a ellos. Los ataques MDS se dirigen a los datos del usuario mientras están en estado transitorio, ya que han estado residiendo en la CPU y en muchos sistemas conectados a ella.
La vulnerabilidad SRBDS/CrossTalk es una vulnerabilidad de ejecución transitoria. Denominada como «Muestreo de datos del búfer del registro especial» o SRBDS (CVE-2020-0543) por Intel, permite que el código controlado por el atacante se ejecute en un núcleo de la CPU, lo que provoca la filtración de datos sensibles del 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 utilice una CPU Intel puede verse afectado por esta vulnerabilidad. Comprueba 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 del microcódigo. Ambas operaciones se realizan tradicionalmente al reiniciar.
Aunque reiniciar un par de servidores no parece un problema, si eres un SysAdmin que se ocupa de más de 500 servidores, seguro que lo es. Reiniciar toda una flota de servidores suele requerir una planificación exhaustiva de la ventana de mantenimiento. Afortunadamente, la tecnología de parcheo en vivo permite aplicar actualizaciones de seguridad a los sistemas contra CrossTalk sin necesidad de reiniciar, tanto para la actualización del microcódigo como para la aplicación de parches del núcleo de Linux.
Canonical, Red Hate y otros proveedores de distribuciones han publicado los parches de seguridad para todas las distribuciones compatibles de Ubuntu, Debian, CentOS y Red Hat Enterprise Linux. Y, aunque Canonical y Red Hat tienen su propia solución para parchear vulnerabilidades sin reiniciar, en el caso de SRBDS/CrossTalk sigues 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 de modo que puedas evitar reiniciar los servidores para aplicar los parches. Encuentra las instrucciones a continuación:
A) Si estás funcionando con hardware, sigue 3 pasos para proteger tus servidores de la vulnerabilidad CrossTalk/SRBDS sin necesidad de reiniciar:
Paso 1:Regístrate para obtener una licencia de prueba gratuita de KernelCare
KernelCare se puede utilizar gratuitamente durante 30 días en todos tus servidores, sin necesidad de tarjeta de crédito para registrarte para la prueba. También es gratuito para las organizaciones sanitarias durante lo que queda de 2020 y para siempre para las organizaciones sin ánimo de lucro.
Paso 2: Actualizar el microcódigo sin reiniciar
Ejemplo: Actualizar el microcódigo en RHEL
Este es el ejemplo de una actualización de microcódigo sin reinicio en RHEL.Puedes encontrar instrucciones para Debian, Ubuntu, CentOS y otras distribuciones en la documentación de KernelCare.
Para las distribuciones basadas en RHEL, puedes utilizar el comando microcode_ctl para actualizar el microcódigo.
Antes de empezar, comprueba aquí si los parches para tu distribución están listos. La página se actualiza cada hora.
1. Consigue el último microcódigo actualizando la utilidad microcódigo_ctl paquete
yum update microcode_ctl2. Crea un force-late-intel-06-4f-01 dentro del directorio del firmware.
touch /lib/firmware/`uname -r`/force-late-intel-06-4f-013. Ejecuta la actualización del microcódigo
/usr/libexec/microcode_ctl/actualizar_ucódigo
4. Obliga al núcleo a cargar el nuevo microcódigo
echo 1 > /sys/devices/system/cpu/microcode/reload
5. Comprueba 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
6. (Opcional) Vuelve a comprobar la nueva versión del microcódigo (revisiones por núcleo)
cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21
Paso 3: Aplicar los parches KernelCare
Ahora tienes que 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 hacerlo sin reiniciar. Si te has apuntado a la prueba en el paso 1, ya está todo listo y no tienes que hacer nada más.
B) Si estás ejecutando en una VM:
Sólo tienes que parchear el Kernel de Linux dentro de la VM. Asegúrate de que tu nodo anfitrión también está actualizado, lo que suele hacer tu proveedor de servicios.
Si utilizas tu KernelCare: los parches serán entregados automáticamente por KernelCare y no necesitas hacer nada extra. Si no es así, suscríbetea una prueba gratuita de 30 días.