Retbleed: un nuevo ataque de ejecución especulativa que afecta a Intel y AMD

Hace poco se dio a conocer la noticia de que un grupo de investigadores de ETH Zurich ha identificado un nuevo ataque al mecanismo de ejecución especulativa de saltos indirectos en la CPU, que permite extraer información de la memoria del kernel u organizar un ataque al sistema host desde máquinas virtuales. Las vulnerabilidades recibieron el nombre en código Retbleed (ya catalogadas bajo CVE-2022-29900, CVE-2022-29901) y son de naturaleza similar a los ataques de Spectre-v2.

[#1 JimmyTM]

Se preparó un conjunto de cambios para el kernel de Linux y el hipervisor Xen, que bloquean el problema mediante programación en las CPU más antiguas. El parche propuesto para el kernel de Linux cambia 68 archivos, agrega 1783 líneas y elimina 387 líneas.

Desafortunadamente, la protección genera costos generales significativos: en los textos realizados en procesadores AMD e Intel, la degradación del rendimiento se estima entre un 14% y un 39%. Es preferible utilizar protección basada en instrucciones IBRS, disponible en las nuevas generaciones de CPUs Intel y soportada desde el kernel Linux 4.19.

Mañana: "Intel y AMD realizan una subvención para la Escuela Politécnica Federal de Zúrich con 500 millones de dólares cada una"

[#2 Jakeukalane]

Ya esto es un tanto... peculiar. ¿Seguro que merece la pena degradar tanto el rendimiento para un usuario de escritorio? ¿Me van a atacar haciendo ejecución especulativa? Por si acaso voy a parar las actualizaciones un tiempo. Una degradación tan grande hace que parezca un parche chapucero.

Edit. Pues parece grave. ¿Y para llegar a leer esos cachés no haría falta ejecutar código no testado?

[#3 JimmyTM]

#2 ¿Y para llegar a leer esos cachés no haría falta ejecutar código no testado?

la vulnerabilidad viene del micro. Aquí tienes la prueba: www.youtube.com/watch?v=dmSPvJxPm80

[#4 Jakeukalane]

#3 ¿entonces? ¿Requiere ejecutar código no testado o se puede hacer a través del navegador, por ejemplo?

[#5 JimmyTM]

#4 ¿Requiere ejecutar código no testado o se puede hacer a través del navegador, por ejemplo?
Por qué no los dos?

Requiere acceso por un usuario aunque no tenga permisos. Pero es buena pregunta. Dependiendo de la seguridad del navegador igual hasta es posible.

[#6 Jakeukalane]

#5 En un Linux de sobremesa donde requiero compilar o renderizar cosas y prácticamente ya no instalo software nuevo si requiere pasos complicados antes de llegar a eso quizás no me compense perder tanto rendimiento. Pero si es un ataque factible incluso navegando quizás sí (aunque se me ocurre que antes que eso podría algún bloqueador de javascript). Pero creo que en unos meses no habrá opciones y todos los kernels tendrán esta cosa...