ClickCease ¿Pensabas que Spectre era historia? Sigue vivo y coleando - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

¿Pensabas que Spectre era historia? Sigue vivo y coleando.

12 de marzo de 2021 - Equipo de RRPP de TuxCare

¿Pensabas que Spectre era historia? Sigue vivo y coleando.

Las ciberamenazas van y vienen, pero algunas dejan una huella duradera por su impacto. Pensemos, por ejemplo, en Spectre y la estrechamente relacionada Meltdown, dos de las vulnerabilidades de las que más se ha hablado en los últimos tiempos.

Por supuesto, es frustrante cuando una amenaza cibernética simplemente se niega a desaparecer, y aún peor cuando se trata de una vulnerabilidad muy prominente. Ese está resultando ser el caso de Spectre, uno de los exploits más peligrosos de los últimos tiempos. Aunque los sistemas parcheados están protegidos contra Spectre, la naturaleza de los parches de Spectre y el impacto resultante en el rendimiento significa que un gran número de sistemas no han sido parcheados....

Esto deja a muchos sistemas clave vulnerables a Spectre. Y lo que es peor, se acaba de publicar un nuevo exploit para Spectre de acceso público. Resulta que Spectre no está del todo muerto. Echemos un vistazo.

Contenido

 

 

Introducción a Spectre

Introducción a Spectre

 

Spectre forma parte de un trío de vulnerabilidades relacionadas entre sí. Existen dos versiones de Spectre, mientras que la tercera vulnerabilidad se denomina Meltdown. En su momento, los investigadores de seguridad calificaron estas vulnerabilidades de catastróficas. Afortunadamente, se publicaron rápidamente parches adecuados, pero había una complicación.

 

 

¿Cómo funciona la vulnerabilidad Spectre?

¿Cómo funciona la vulnerabilidad Spectre?

 

En primer lugar, veamos cómo funciona Spectre. Las vulnerabilidades suelen localizarse en el software: errores o descuidos en el código de las aplicaciones o del sistema operativo. Las vulnerabilidades de Spectre son, sin embargo, vulnerabilidades de hardware, y se localizan en el hardware que se utiliza en todos los ordenadores del mundo: la unidad central de procesamiento, o CPU.

En el momento en que se descubrieron, las dos vulnerabilidades Spectre y Meltdown afectaban a casi todas las CPU en uso, desde los chips Intel hasta los procesadores AMD y Arm; aunque el grado de vulnerabilidad de una CPU dependía del proveedor de la CPU y de la arquitectura.

Las vulnerabilidades se reducen a un defecto de hardware en la forma en que están diseñados los procesadores, y es esencialmente un problema a nivel de silicio.

Sin entrar en demasiados detalles técnicos, los procesadores modernos manejan las instrucciones de la CPU de formas complicadas: ejecutando instrucciones fuera de orden y de forma especulativa, por ejemplo. Los procesadores hacen esto para que la ejecución de las instrucciones sea más eficiente, es decir, para que sean más rápidas.

Spectre y su primo Meltdown se basan en fallos en la forma en que se gestiona la ejecución de instrucciones en los procesadores actuales. Al manipular estos fallos, un hacker que explote la vulnerabilidad es capaz de leer espacio de memoria arbitrario y obtener así datos sensibles.

 

 

Por qué los parches de Spectre causaron complicaciones

Por qué los parches de Spectre causaron complicaciones

 

Spectre es una vulnerabilidad de hardware y los proveedores de CPU, incluidos Intel y AMD, lanzaron parches para mitigar los riesgos de Spectre. El parche consistía básicamente en un pequeño software que actualizaba el microcódigo de la CPU.

El microcódigo de la CPU incluye la lista de instrucciones disponibles para el procesador y los procedimientos que se siguen cuando una instrucción tiene varios pasos, lo que también influiría en el tratamiento de eficiencias de ejecución como la ejecución especulativa y fuera de orden.

Cuando se detecta un error o una vulnerabilidad en una función específica de la CPU, el fabricante puede emitir un parche que contenga microcódigo para desactivar la instrucción, hacer que no tenga ninguna función o cambiar la forma en que se gestiona internamente. Se trata del mismo hardware, pero la CPU funcionará de forma ligeramente distinta.

Las ediciones más recientes de las CPU más utilizadas han introducido cambios en su diseño para ser menos vulnerables a Spectre y Meltdown, ya que los fabricantes han aprendido la lección del trío de vulnerabilidades.

Algunos usuarios simplemente nunca ejecutaron los parches, como siempre ocurre con los parches, por lo que el microcódigo de sus CPU nunca se actualizó. Sin embargo, pronto surgió un problema mayor con los parches lanzados para proteger a los usuarios contra Spectre y Meltdown.

 

 

Problemas de rendimiento con los parches Spectre para CPU

Problemas de rendimiento con Spectre CPU parches

 

Los cambios en el microcódigo de la CPU que se incluían en los parches de los proveedores a menudo afectaban al rendimiento de las CPU y, por tanto, a los servidores que utilizaban estas CPU, y en algunos casos lo hacían en un grado inaceptable.

Como Spectre y Meltdown explotaban fallos en las sofisticadas tecnologías que hacen que las CPU sean más eficientes, era difícil desarrollar parches que no afectaran a estas eficiencias. Cuando se publicaron, los parches de Intel, AMD y otros proveedores de procesadores que protegían contra las vulnerabilidades cambiaron o limitaron algunas de estas eficiencias de ejecución de instrucciones.

Los problemas de rendimiento surgieron rápidamente y afectaron a todos los sistemas operativos y a la mayoría de las CPU. Este efecto variaba en función de la CPU en cuestión, y algunos chips Intel se veían más afectados que los procesadores AMD. En un análisis, el sitio de hardware ExtremeTech descubrió durante las pruebas que los chips de Intel se veían afectados cinco veces más que los de AMD.

Microsoft también publicó un artículo sobre el impacto en el rendimiento, señalando un mayor impacto en las CPU más antiguas en comparación con las generaciones posteriores - la compañía sugirió que algunos usuarios verán un notable descenso del rendimiento.

 

 

Los parches del sistema operativo también afectaron al rendimiento

Los parches del sistema operativo también afectaron al rendimiento

 

La primera vía de mitigación contra Spectre y su primo fue a través de un parche que actualizaba el microcódigo de la CPU. Sin embargo, los proveedores de sistemas operativos también lanzaron parches en un intento de protegerse contra Meltdown y Spectre.

Al igual que los parches para la CPU, las mitigaciones implementadas en el sistema operativo provocaron problemas de rendimiento. En el sistema operativo, la mitigación se logró cambiando la forma en que el sistema operativo y, por extensión, el software de usuario que se ejecuta sobre dicho sistema operativo, traduce su código en instrucciones de máquina. En otras palabras, qué instrucciones de la CPU utilizará para realizar sus funciones.

Por ejemplo, a finales de 2018, salió a la luz que una mitigación aplicada a una versión del kernel de Linux provocó que algunas cargas de trabajo vieran una caída del rendimiento de hasta el 50%. En este caso, se trataba de una mitigación llamada Single Thread Indirect Branch Predictors (STIBP), y el impacto en el rendimiento fue tan significativo que el propio Linus Torvalds intervino.

 

 

El resultado: parches retrasados

El resultado: parches retrasados

 

El impacto en el rendimiento de los parches de Spectre, ampliamente publicado, se convirtió rápidamente en un obstáculo para la aplicación de parches de forma amplia y coherente, un obstáculo que va más allá de los problemas que tienen las empresas para aplicar parches de forma coherente en sus máquinas, incluso cuando no implica un impacto en el rendimiento.

Cuando las cargas de trabajo exigían ciertos niveles de rendimiento, e incluso cuando la eficiencia era la única preocupación, los administradores de sistemas optaban a veces por no parchear en caso de que el parche causara graves problemas de rendimiento y, por tanto, de fiabilidad.

El resultado es que, aunque Spectre y Meltdown son vulnerabilidades conocidas, muchos sistemas nunca se parchearon porque a los usuarios les preocupaban los problemas de rendimiento. Se trata de una situación relativamente única, ya que en la mayoría de los casos los administradores de sistemas aplican los parches más eficaces posibles para evitar riesgos de seguridad.

A pesar de los problemas con los parches, hay un aspecto relativamente positivo sobre las vulnerabilidades Spectre: desde su descubrimiento, no se ha publicado ningún exploit disponible públicamente para Spectre. Hasta ahora.

 

 

¿Qué es VirusTotal DB?

¿Qué es VirusTotal DB?

 

El acceso a un exploit público y publicado de una vulnerabilidad puede hacerla mucho más peligrosa de lo que era antes. Por desgracia, en el caso de Spectre, ya ha aparecido el primer exploit disponible públicamente. Se ha publicado recientemente en un sitio web llamado VirusTotal DB. En primer lugar, echemos un vistazo a VirusTotal DB y para qué se utiliza.

VirusTotal se desarrolló originalmente en España, pero ahora está bajo los auspicios de Alphabet, la empresa matriz de Google. Se trata básicamente de un agregador que reúne varios motores de análisis y productos antivirus en línea. Los usuarios pueden subir archivos para su comprobación, incluida la verificación de falsos positivos.

El sitio web depende de una serie de colaboradores, desde motores antivirus y escáneres de sitios web hasta contribuciones de usuarios. Y es en una de estas contribuciones donde se descubrió un exploit funcional para Spectre.

 

 

El descubrimiento del código

El descubrimiento del código

 

En febrero de 2021, un analista descubrió que al añadir una contribución a VirusTotal, un usuario subió simultáneamente un exploit funcional para Spectre que puede utilizarse en sistemas con Linux sin parches.

El código formaba parte de una herramienta llamada Immunity Canvas. La aplicación realiza pruebas de penetración automáticas. Es decir, prueba sistemas contra vulnerabilidades a múltiples exploits. La empresa había desarrollado una herramienta de trabajo para probar este exploit específico de Spectre.

Pero al contribuir con su código a VirusTotal, Immunity Canvas incluyó el código del exploit. Al fin y al cabo, el código de prueba puede utilizarse fuera de la herramienta de pruebas de penetración original y utilizarse de forma independiente con las modificaciones oportunas.

El código no es inmediatamente utilizable: la parte que quiera usarlo debe estar lo suficientemente motivada para manipular el código y convertirlo en un exploit que funcione, pero hay suficiente código en la contribución de VirusTotal para que un actor decidido construya un exploit de Spectre que funcione.

 

Cómo afecta el exploit público Spectre al mundo informático

Cómo afecta el exploit público Spectre al mundo informático

 

En teoría, en un mundo en el que los parches se aplicasen de forma coherente, el exploit para Spectre, ahora hecho público, no supondría ningún peligro. Por supuesto, como hemos explicado anteriormente en este artículo, el problema radica en el hecho de que el golpe de rendimiento generado por algunos parches de Spectre significa que algunos usuarios han optado por no parchear sus sistemas contra Spectre.

Este impacto en el rendimiento puede ser elevado. Es comprensible que algunas empresas piensen que el impacto en el rendimiento es mucho peor que el riesgo o el impacto de una brecha de seguridad, ya que el impacto en el rendimiento requeriría una expansión significativa del hardware para compensarlo.

Con este exploit público, este cálculo ha cambiado: los riesgos de un ataque son mucho mayores con el código del exploit ahora en libertad. En particular, los sistemas vulnerables a Spectre suelen estar aún dentro de su ciclo de vida útil típico.

También existe otra posibilidad que debería preocupar a los usuarios de sistemas que no estén parcheados contra Spectre. Las vulnerabilidades Spectre y Meltdown están estrechamente relacionadas. Ahora que una vulnerabilidad tiene un exploit publicado, existe una vía de trabajo para explotar las otras vulnerabilidades, y un atacante decidido podría aprovechar la oportunidad.

Esto conduce a una tormenta perfecta de un exploit públicamente visible junto con un número significativo de sistemas sin parches. Los administradores de sistemas y las empresas que intentaban evitar las medidas de mitigación por motivos de rendimiento ahora deben reconsiderarlas y aplicarlas.

Si siguen negándose a hacerlo, deben darse cuenta de que se arriesgan a sufrir ataques e infracciones que podrían escalar rápidamente a costes muy elevados.

 

 

Protección contra el exploit público Spectre

Protección contra el exploit público Spectre

 

Spectre es una vulnerabilidad ampliamente conocida y publicitada desde hace tres años, que dispone de mitigaciones desde hace años. Pocos sistemas deberían quedar desprotegidos. Sin embargo, las mitigaciones han tenido un impacto no despreciable en el rendimiento de los sistemas en los que se han implementado, por lo que los administradores de sistemas se han mostrado reacios a aplicarlas.

Un exploit de Spectre disponible públicamente no es una buena noticia, pero protegerse contra él no debería ser difícil. Se han publicado parches para el hardware, y los proveedores de sistemas operativos también han publicado parches eficaces. Este exploit público no funcionará en un sistema parcheado.

Si los sistemas no han sido parcheados, los usuarios deben tomar medidas para parchear contra Spectre y Meltdown, incluso si ello puede afectar al rendimiento. Así de sencillo.

Ahora que un exploit de Spectre está disponible públicamente, ha llegado el momento de actuar: los administradores de sistemas deben parchear los sistemas vulnerables contra Spectre, y deben hacerlo ahora, aunque ello repercuta en el rendimiento. Cuando la aplicación de parches sea difícil, los administradores de sistemas pueden utilizar herramientas como KernelCare para parchear sobre la marcha, sin necesidad de reiniciar los sistemas críticos..

 

 

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín