El fallo de Intel

2

Desde el 2 de enero de 2018 han aparecido noticias sobre que los procesadores Intel de los últimos 10 años vienen con un defecto de seguridad. ¿Cómo de grave es esto? ¿Es real? ¿Nos debe preocupar? Os hago un spoiler: es grave, es real y nos debe preocupar, porque implicará que nuestras máquinas se van a convertir entre un 5% y un 30% más lentas. ¿Quieres saber por qué? Pues sigue leyendo.

Disclaimer: Este artículo está redactado con la información disponible a través de distintos medios, principalmente el artículo de The Register, y la información no está del todo contrastada, por lo que no puedo garantizar su completa veracidad.

Unos antecedentes antes de empezar

Voy a intentar explicar lo que se sabe del fallo de seguridad sin ponerme demasiado técnico. Esto me obligará a simplificaciones que pueden herir la sensibilidad de más de un técnico. Mis disculpas.

La seguridad de hoy en día en un sistema operativo se basa en que los programas que ejecutamos no pueden hacer lo que quieran. Sólo pueden acceder a los recursos sobre los que tienen que permisos. Así un programa no puede acceder directamente al disco duro, le tiene que “pedir” al sistema operativo que le dé determinado dato del disco duro, y el sistema operativo, controlando si el programa tiene permiso o no, le dará ese dato. Los programas continuamente están intentando acceder a estos recursos haciendo llamadas a lo que se llama el Kernel del sistema operativo.

Podemos entender este Kernel como el “super-programa” de nuestro sistema operativo. Es un programa que prácticamente puede hacer de todo.

Para poder permitir esta seguridad y asegurar que un determinado código sólo puede acceder a los recursos permitidos, los procesadores contienen funcionalidades que controlan en que modo se está trabajando. Así el procesador “sabe” que determinado código debe funcionar en modo “usuario”, un modo restringido. Y también sabe que otro determinado código trabaja en modo “kernel” pudiendo acceder a muchas más cosas. Esto permite que si el código que se está ejecutando en modo usuario intenta acceder a un recurso de otro programa o del mismo kernel, el procesador no le deje.

Recapitulemos: los programas se ejecutan en el procesador en un modo en que se asegura que sólo pueden acceder a donde tienen permiso.

Vamos a continuar un poco más la explicación y vemos dónde está el problema. Los procesadores están diseñados pensando en el tipo de software que se va a ejecutar y contienen optimizaciones para intentar acelerarlo. Veamos dos optimizaciones que están relacionadas con el fallo de seguridad:

  • Por un lado, es muy común que un programa necesite algo del Kernel, y que el procesador salte de un programa al Kernel. Para facilitar esa transición el procesador permite tener un espacio de memoria “compartido” entre el Kernel y la memoria del programa, pero que impide que si se está en modo usuario se pueda acceder a la memoria del Kernel. Así, no es necesario cambiar de página de memoria a la que se está apuntando en el procesador cada vez que cambia del programa al Kernel. Esto permite que la transición entre Pograma y Kernel sea rápida.
  • Por otro lado, los procesadores modernos utilizan la programación especulativa. Esto es que el procesador puede estar haciendo varias cosas a la vez, pero muchas veces esto no se puede aprovechar porque los cálculos se tienen que hacer secuenciales. Así, el procesador se tendría que quedar haciendo una cosa en vez de varias a la vez, porque esta esperando a que se calcule una determinada operación. Por ejemplo: Si le pedimos calcular 3+2+4, el procesador se pondrá a calcular 3+2, y esperará hasta tener el resultado. Cuando haya determinado que es 5, entonces empezará a calcular 5+4. El cálculo especulativo intenta acelerar el proceso “advinando el resultado”. En el ejemplo anterior empezaría calculando 3+2, y en paralelo comenzaría a arrancar sumas de 4+ posibles resultados de la operación anterior, por ejemplo, 3+4, 4+4, 5+4, 7+4. Cuando termina de calcular 3+2, y sabe que es 5, mira a ver si una de sus “especulaciones” era la correcta y si tiene suerte, habrá ganado tiempo, porque empezó a calcularla antes de saber que iba a dar 5. Otro ejemplo es el código detrás de un “if” (una condición) que para evaluar si es verdad o no, al procesador le costará. Por ejemplo obligando a leer un dato de memoria. Así el procesador se quedará esperando al dato de memoria, para saber si se cumple la condición, y mientras tanto irá calculando lo que pasaría si se cumpliese la condición. Así, si luego se cumple la condición, el resultado ya está calculado de antemano.

Recapitulemos: Los procesadores permiten controlar datos en el mismo espacio de memoria separando lo que es de Kernel y lo que es de usuario, y contienen funcionalidades especulativas que pueden acelerar los tiempos de cálculo.

El fallo de seguridad

El fallo, por lo que parece, combina el cálculo especulativo con la protección de la memoria Kernel. Es posible que un cálculo especulativo acceda a memoria a la que no tiene permiso, y eso permita a un programa acceder a memoria que corresponde al Kernel. Es decir, las tareas que se están ejecutando de forma “especulativa” pueden saltarse parte de esa protección, y acceder a zonas. Así, si desarrollamos un código que intente acceder a partes a las que no tiene acceso, y lo desarrollamos de forma que esas búsquedas estén detrás de algún “if” con acceso a memoria (que tarda), podremos conseguir que el código se ejecute de forma especulativa, y que el procesador acierte en sus “adivinaciones”. Así conseguiremos que el código se ejecute sin la protección que le toca.

El resultado es que un programa podría leer y cambiar memoria a la que no tiene acceso, en este caso del Kernel. Y si se puede acceder a esa memoria, se puede acceder a todo lo que esté en la máquina. Porque podemos inyectar lo que queramos en la máquina. Kernel es Dios, y estamos tocando sus apuntes. Así podemos engañar al Kernel y hacer que ejecute lo que nosotros queramos.

Las implicaciones de este fallo son enormes porque potencialmente podrían permitir:

  • Que un usuario sin permisos de administración pudiese ejecutar un código que le otorgue estos permisos. (Este punto ya está demostrado, ayer mismo por un estudiante de doctorado, y más adelante lo anunciaban con mucho más detalle en Google, aprovechando el fallo con dos vectores de ataque: Spectre y Meltdown)
  • Que un virus o un gusano que pueda ejecutar código, pero sin permisos de admin, utilice este fallo para poder ganar esos permisos. Esto abre nuevos vectores de ataque.
  • Que una máquina virtual pueda acceder a funcionalidades del hipervisor y por extensión leer o afectar a otras máquinas virtuales. Esto es especialmente grave en un cloud público, porque significa que contratando una máquina virtual podría ver o afectar lo que pasa en otras (potencialmente).
  • Que un código en un espació muy restringido logre acceder y dominar una máquina. Por ejemplo, un javascript de una web. Este último caso significaría que simplemente por acceder a una web maliciosa, se podría poner en riesgo la seguridad de nuestro PC. (Parece que Mozilla ya ha confirmado este punto).

A quién afecta

No se sabe exactamente a quien afecta pero se cree que los procesadores Intel de la última década estarían todos afectados.

AMD anunció inicialmente que no está afectado. Pero más adelante reconoce que de los diferentes tipos de ataque que se han estudiado hasta la fecha, algunos les afectan, otros no y otros no se sabe. Lo bueno, es que los que les afectan se resuelven fácilmente por un parche en el sistema operativo que no implica sobrecoste, como sí pasa en Intel.

Resumiendo ¿Tienes un servidor basado en Intel comprado en los últimos 10 años? Pues estás afectado. ¿Estas en un cloud? Pues casi seguro estás afectado porque los más grandes (Azure, Google Cloud, AMZ, …) usan procesadores Intel.

La solución

La solución que se está poniendo encima de la mesa por parte de los desarrolladores de sistemas operativos es utilizar distintos espacios de memoria para el Kernel y para el espacio de usuario. Es lo que han llamado KPTI (Kernel Page Table Isolation). El problema es que cada vez que se salte al Kernel el procesador tendrá que cambiar de espacio de memoria, lo cual le costará más de lo que le está costando ahora. Y ese coste no es despreciable. Principalmente porque para cambiar el espacio de memoria implica borrar determinadas cachés del procesador, como el TLB (Translation Lookaside Buffer).

Se sabe que los desarrolladores de Linux y Windows llevan desde Noviembre trabajando en esto. Pero lo hacían manteniendo un perfil bajo, no dejando muy claro por qué lo hacían, hasta que se ha descubierto el pastel. También se esperan parches para MacOS y los principales hypervisores (máquinas virtiales) del mercado. Se espera que estos parches se liberen dentro de muy poco. De hecho los principales proveedores de cloud ya han avisado de que aplicarán el cambio dentro de muy poco. De hecho ya ha habido cambios en diciembre en AMZ, y quejas sobre degradación de rendimiento, por lo que parce que ya están parcheando cosas.

En Linux, de hecho, el cambio ya está listo y probándose, antes de lanzar oficialmente el parche. Así que ya ha habido gente que se ha bajado el parche en pruebas y probado el rendimiento. Y aquí es donde me entra el sudor frio, porque se habla de reducciones de rendimiento de entre el 5% y el 30%, y que probablemente veremos reducciones del 10%-15%.

¿Vas a notar el cambio?

En los PC de sobremesa no lo notaremos muy probablemente. Hoy en día suelen estar sobredimensionados en lo que a CPU se refiere. Así que una reducción de rendimiento de la CPU no se apreciaría mucho.

Si tienes servidores en un CPD, dependerá del sobredimensionamiento que tengas actualmente. Asume que vas a perder un 15% de la potencia de esos servidores.

Si tienes tus servidores en cloud en un esquema adaptativo, creando o destruyendo servidores según lo necesites, dependerá de lo que te esté limitando. Si es RAM, ancho de banda o acceso a disco, no te afectará.  Si es CPU, asume que tu factura puede crecer un 20%. Da miedito…

Conclusión

En las próximas semanas sabremos más datos, y tendremos los parches en la calle. Pero muy probablemente veremos como nuestra granja de servidores va a perder fuerza, y que es posible que nuestros gastos aumenten.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

2 comments

Post a new comment