Cómo mitigar la vulnerabilidad SRBDS (CVE-2020-0543) sin reiniciar el servidor
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.
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.