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

Dise√Īo de la etapa de perfilado de instrucci√≥n de CrossTalk

Recientemente, acad√©micos del Grupo de Seguridad de Redes y Sistemas de la Universidad de Vrije (VUSec) han publicado detalles sobre CrossTalk o SRBDS (CVE-2020-0543) vulnerabilidad en procesadores Intel. La vulnerabilidad CrossTalk permite que el c√≥digo controlado por un atacante se ejecute en un n√ļcleo de CPU para filtrar datos confidenciales de otro software que se ejecuta en un n√ļcleo diferente. En este art√≠culo, le mostraremos c√≥mo mitigar esta vulnerabilidad de la CPU Intel sin reiniciar el servidor.

¬ŅQu√© es CrossTalk?

La vulnerabilidad CrossTalk es un tipo de ataque MDS (muestreo de datos de microarquitectura), similar a espectro, fusión o carga de zombis. Permite la exposición y el robo de datos confidenciales mientras la máquina accede a ellos. Los ataques de MDS apuntan a los datos del usuario mientras se encuentran en un estado transitorio, ya que ha estado residiendo dentro de la CPU y muchos sistemas conectados con ella.

La vulnerabilidad SRBDS/CrossTalk es una vulnerabilidad de ejecuci√≥n transitoria. nombrado como un ‚ÄúMuestreo de datos de b√ļfer de registro especial‚ÄĚ o SRBDS (CVE-2020-0543) de Intel, permite que el c√≥digo controlado por el atacante se ejecute en un n√ļcleo de la CPU, lo que da como resultado la filtraci√≥n de datos confidenciales del software de la v√≠ctima que se ejecuta en un n√ļcleo diferente.


Dise√Īo de la etapa de perfilado de instrucci√≥n de CrossTalk
Figura 1: Dise√Īo de la etapa de creaci√≥n de perfiles de instrucci√≥n de CrossTalk, cortes√≠a de VUSec

Cualquier sistema que utilice una CPU Intel puede verse afectado por esta vulnerabilidad. Chequea aquí si su CPU se ve 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 y actualizaciones de microc√≥digo del kernel de Linux. Ambas operaciones se realizan tradicionalmente al reiniciar.

Si bien reiniciar un par de servidores no parece ser un problema, si usted es un administrador de sistemas que se ocupa de más de 500 servidores, seguro que lo es. Reiniciar una flota de servidores completa 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 reiniciar, tanto para la actualización del microcódigo como para la aplicación de parches del kernel de Linux.

Canonical, Red Hate y otros proveedores de distribución han lanzado los parches de seguridad para todas las distribuciones de Ubuntu compatibles, Debian, CentOS, 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 todavía necesito reiniciar un escritorio o un servidor después de la actualización.

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

A) Si est√° ejecutando en hardware, tome 3 pasos para proteger sus servidores de la vulnerabilidad CrossTalk/SRBDS sin reiniciar:

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

KernelCare es de uso gratuito durante 30 días en todos sus servidores, no se requiere tarjeta de crédito para Regístrese para una prueba. Tambien es gratis para organizaciones de salud para el resto de 2020 y para siempre gratis para organizaciones sin fines de lucro.

Paso 2: Actualizar microcódigo sin reiniciar

Ejemplo: Actualización de microcódigo en RHEL

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

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

Antes de empezar, compruebe aquí si los parches para su distribución están listos. La página se actualiza cada hora.

1. Obtenga el √ļltimo microc√≥digo actualizando el microc√≥digo_ctl paquete

yum update microcode_ctl

2. Crea un force-late-intel‚Äď06‚Äď4f‚Äď01 dentro del directorio del firmware.

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

3. Ejecute la actualización del microcódigo

/usr/libexec/microcode_ctl/update_ucode

4. Forzar al kernel a cargar el nuevo microcódigo

echo 1 > /sys/dispositivos/sistema/cpu/microcódigo/recargar

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) Vuelva a verificar 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 parches KernelCare

Ahora necesita actualizar el kernel de Linux para asegurarse de que el usuario local no pueda leer los datos que está ejecutando en la CPU. Con KernelCare puede hacerlo sin reiniciar. Si se registró para la versión de prueba en el Paso 1, está listo y no tiene que hacer nada más.

B) Si est√° ejecutando en VM:

Solo necesita parchear el Kernel de Linux dentro de la VM. Aseg√ļrese de que su nodo host tambi√©n est√© actualizado, lo que normalmente hace su proveedor de servicios.

Si está utilizando su KernelCare, sus parches serán entregados automáticamente por KernelCare y no necesita hacer nada adicional. Que no РRegístrese para una prueba gratuita de 30 días.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *