Recientemente, académicos del Grupo de Seguridad de Redes y Sistemas de la Universidad de Vrije (VUSec) publicaron detalles sobre la vulnerabilidad CrossTalk o SRBDS (CVE-2020-0543) en los 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 Spectre, Meltdown o Zombieload. 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 "Muestreo de datos de búfer de 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 CPU, lo que resulta en la filtración de datos confidenciales del software de la víctima que se ejecuta en un núcleo diferente.
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. Compruebe aquí si su CPU está afectada.
Mitigación sin reinicio de la vulnerabilidad SRBDS (CVE-2020-0543)
Intel implementó 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 aún necesita reiniciar una computadora de 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 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 registrarse para una prueba. También es gratis para las organizaciones de atención médica durante el resto de 2020 y gratis para siempre para las 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. Las instrucciones para Debian, Ubuntu, CentOS y otras distribuciones se pueden encontrar 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, comprueba aquí si los parches para tu distribución están listos. La página se actualiza cada hora.
1. Obtenga el último microcódigo actualizando el microcode_ctl paquete
yum update microcode_ctl
2. Crear un force-late-intel–06–4f–01 dentro del directorio de 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. Consulta 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) Verifique dos veces 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 de 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. De lo contrario, regístrese para obtener una prueba gratuita de 30 días .