Según The Register, un grave error en el diseño de los procesadores de Intel está generando el caos entre los usuarios, los fabricantes y sobre todo los desarrolladores de sistemas operativos, que están trabajando contrarreloj para parchear el fallo.
El impacto del problema podría ser enorme y abre la puerta a vulnerabilidades de seguridad críticas que podrían ser aprovechadas para potenciales ciberataques. A continuación aclaramos quiénes están afectados, cuál es el impacto del problema y cómo solucionarlo.
¿Qué ha pasado?
Todos los procesadores de Intel de los últimos diez años podrían estar afectados por el problema. Los micros de AMD, por el contrario, parecen estar a salvo según declaraciones de sus responsables.
Ese fallo no parece poder corregirse con una actualización del microcódigo de estos procesadores, y los riesgos, como veremos a continuación, son evidentes y preocupantes.
El problema permitiría que cualquier aplicación accediera a espacios reservados de memoria a los que teóricamente nunca debería acceder para modificarlos, lo que a su vez daría acceso al resto de recursos de la máquina. La solución, como también veremos más adelante, pasa por separar totalmente la memoria del núcleo de los procesos de usuario. Hacerlo atajará el problema, pero podría tener un impacto claro en el rendimiento. Veamos en profundidad todo ello.
¿Cuáles son los riesgos?
Una de las consecuencias más graves es la que permitiría a un atacante leer el contenido de la memoria del núcleo del sistema operativo. En esa memoria es un espacio oculto reservado a procesos y programas que guardan en él cosas como contraseñas, claves de acceso u otros datos sensibles.
Según indican en The Register, el fallo podría ser aprovechado para superar uno de los mecanismos de protección que Intel lleva implementando hace años: el KASLR (Kernel Address Space Layout Randomization), implementado en diversos sistemas operativos para colocar partes del núcleo en sitios aleatorios de memoria para evitar accesos no autorizados a esas partes. En el siguiente video uno de los investigadores de TU Graz describe cómo se haría un ataque ASLR mediante JavaScript que aprovecharía esta vulnerabilidad:
Al colocar esos pedazos de código crítico —de ellos depende el acceso a las funciones seguras que usamos en nuestros equipos— los atacantes no pueden encontrarlos y por tanto no pueden ejecutar código no autorizado. Sin embargo con este tipo de fallo un ciberatacante podría encontrar dónde están esos pedazos de código para acceder a ellos y modificarlos de forma que eso dé acceso al resto del sistema.
El problema, que sale a la luz pública ahora, y el conjunto de parches que tratarán de solucionarlo ha sido denominado como KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed). Esos parches destinados inicialmente a Linux fueron ya perfilados tanto en un estudio de la Universidad de Tecnología en Graz, Austria (PDF) como en una investigación del ingeniero Anders Fogh, que describió los problemas de la "ejecución especulativa" utilizada por Intel en sus procesadores. Él mismo confesaba al final de aquel estudio que al publicarlo se sentía "como si hubiese abierto la caja de Pandora". Lamentablemente parece que ha sido así.
¿A quién y qué afecta?
Parece, eso sí, que están afectados "solo" los procesadores de 64 bits, estando los de 32 bits —más antiguos, pero muchos de ellos aún en uso— a salvo del problema.
En un correo enviado a la lista del kernel Linux los responsables de AMD explicaban que sus procesadores no estaban afectados por el problema, y uno de sus ingenieros, Tom Lendacky, destacaba que "la microarquitectura de AMD no permite referencias a memoria, incluyendo referencias especulativas, que permiten acceder a datos con altos privilegios cuando se ejecutan en un modo menos privilegiado cuando ese acceso resultaría en un fallo de página"
Todo esto implicaría que millones de máquinas en todo el mundo estarían afectadas por este tipo de vulnerabilidad. No solo en el ámbito doméstico, en el que todo PC, portátil o tableta basada en estos microprocesadores estará afectado, sino en el ámbito empresarial.
Este último es aún más peligroso por la cantidad de sistemas que dependen de la seguridad de los grandes centros de datos que nos proporcionan los servicios actuales. Como indican en The Register, las grandes plataformas de Cloud Computing como Amazon EC2, Microsoft Azure o Google Compute Engine estarían afectadas.
La razón es simple: muchos de los servidores utilizados en los centros de datos que ofrecen todos esos servicios están basados en procesadores Intel. No estamos hablando de potenciales problemas en ese servicio de correo web o tienda online en la que compran —que también tienen miga— sino en sistemas críticos utilizados para gestionar cómo se proporcionan servicios básicos (agua, luz, comunicaciones) y que también funcionan sobre máquinas con procesadores de Intel en muchos casos.
¿Cómo solucionarlo?
La única alternativa parece ser la actualización de los sistemas operativos para atajar el problema desde esos sistemas. Que se sepa todos están afectados, así que tanto los usuarios de Windows como los de macOS y los de Linux dependen de las actualizaciones de sistema, que deben llegar en estos días. Los parches consisten en la separación de los espacios de memoria, aislándolos para que el problema de acceso de unos a otros desaparezca.
De hecho ya hay una actualización para el kernel Linux que está disponible, y es curioso (y preocupante) comprobar cómo aunque el código está disponible como en todo proyecto Open Source, se han eliminado o editado los comentarios en los que se explica cómo se han tapado los agujeros. Eso, claro, daría información muy jugosa para potenciales ciberatacantes que quisieran sacar partido de la vulnerabilidad a partir del código publicado para corregirla, lo que les daría muchas pistas.
Se espera que tanto Microsoft como Apple publiquen cuanto antes los parches para corregir el problema. En el caso de Microsoft esa actualización podría llegar el próximo martes (cada semana se produce el ya célebre "Patch Tuesday"), y
Esas actualizaciones también afectarán a las grandes plataformas Cloud Computing: Microsoft ya ha emitido un comunicado avisando de que el próximo 10 de enero habrá cortes del servicio para operaciones de "mantenimiento", y lo mismo ha hecho Amazon, que tiene previsto ese mismo proceso bastante antes, el próximo 5 de enero.
Esas actualizaciones también afectarán a las grandes plataformas Cloud Computing: Microsoft ya ha emitido un comunicado avisando de que el próximo 10 de enero habrá cortes del servicio para operaciones de "mantenimiento", y lo mismo ha hecho Amazon, que tiene previsto ese mismo proceso bastante antes, el próximo 5 de enero.
¿Cuáles son las consecuencias?
Según revelan los primeros estudios, esa bajada de rendimiento podría estar entre el 5 y el 30%, una cifra realmente preocupante que no obstante tiene que ser confirmada. Aún así al menos en el caso de Linux el impacto en el rendimiento se ha comprobado que podría ser notable.
Como explicaban en el blog Python Sweetness, el mecanismo utilizado por Intel tradicionalmente parecía proporcionar un buen equilibrio entre seguridad y rendimiento. Al tener que prescindir de ese mecanismo, perdemos en prestaciones (curioso que lo evaluasen en una CPU de AMD que teóricamente no está afectada por el problema):
La razón principal del antiguo comportamiento Linux de mapear la memoria del núcleo en las mismas tablas de páginas que la memoria de usuario es para que cuando el código del usuario desencadena una llamada, un fallo o una interrupción del sistema, no sea necesario cambiar el diseño de la memoria virtual del proceso en ejecución. Puesto que no es necesario cambiar el diseño de la memoria virtual, tampoco es necesario limpiar las cachés de CPU altamente sensibles al rendimiento que dependen de ese diseño, principalmente el TLB (Translation Lookaside Buffer). Con los cambios ya integrados que hacen que las tablas de página se dividan, es necesario que el kernel limpie estas cachés cada vez que el kernel empiece a ejecutarse y cada vez que el código de usuario reanude la ejecución. Para algunas cargas de trabajo, la pérdida total efectiva del TLB en cada llamada de sistema lleva a ralentizaciones muy visibles: @grsecurity midió un caso sencillo en el que Linux "du -s" sufrió una ralentización del 50% en una CPU AMD reciente.
El impacto en el rendimiento dependerá por supuesto de cada plataforma y de cada aplicación, pero es de esperar que ese impacto se reduzca con posteriores actualizaciones en las que se mejore el nuevo funcionamiento que protege esas áreas reservadas de memoria a las que los procesos no deben acceder.
Como explicaban en el blog Python Sweetness, el mecanismo utilizado por Intel tradicionalmente parecía proporcionar un buen equilibrio entre seguridad y rendimiento. Al tener que prescindir de ese mecanismo, perdemos en prestaciones (curioso que lo evaluasen en una CPU de AMD que teóricamente no está afectada por el problema):
La razón principal del antiguo comportamiento Linux de mapear la memoria del núcleo en las mismas tablas de páginas que la memoria de usuario es para que cuando el código del usuario desencadena una llamada, un fallo o una interrupción del sistema, no sea necesario cambiar el diseño de la memoria virtual del proceso en ejecución. Puesto que no es necesario cambiar el diseño de la memoria virtual, tampoco es necesario limpiar las cachés de CPU altamente sensibles al rendimiento que dependen de ese diseño, principalmente el TLB (Translation Lookaside Buffer). Con los cambios ya integrados que hacen que las tablas de página se dividan, es necesario que el kernel limpie estas cachés cada vez que el kernel empiece a ejecutarse y cada vez que el código de usuario reanude la ejecución. Para algunas cargas de trabajo, la pérdida total efectiva del TLB en cada llamada de sistema lleva a ralentizaciones muy visibles: @grsecurity midió un caso sencillo en el que Linux "du -s" sufrió una ralentización del 50% en una CPU AMD reciente.
El impacto en el rendimiento dependerá por supuesto de cada plataforma y de cada aplicación, pero es de esperar que ese impacto se reduzca con posteriores actualizaciones en las que se mejore el nuevo funcionamiento que protege esas áreas reservadas de memoria a las que los procesos no deben acceder.
En pruebas adicionales realizadas en Phoronix los responsables de este medio comprobaron cómo efectivamente la bajada de rendimiento es significativa en diversos ámbitos. Aclararon cómo los procesadores de Intel con PCID (Process-Context IDentifiers) probablemente "sufran menos" con estos parches y también como aun cuando en varias pruebas (pero no todas) el rendimiento bajaba, parece que en juegos ese rendimiento no se ve especialmente afectado.
Oportunidad para AMD
Este nuevo problema es aún mayor, y puede que esto tenga consecuencias graves para su negocio a corto y medio plazo. El descubrimiento del fallo se suma a otro descubrimiento de hace pocos días especialmente delicado para intentar no ver suspicacias en ese movimiento.
Se trata de cómo Brian Krzanich, presidente de Intel, había vendido todas las acciones que pudo de su empresa (unos 11 millones de dólares en total) y se quedó con el mínimo estricto al que le obligaba la regulación de su cargo.
Habrá que estar atentos a la reacción de Intel en este sentido. La empresa todavía no ha emitido comunicados oficiales al respecto, y tampoco hay novedades en sus cuentas en redes sociales.
La gran beneficiada podría ser AMD, que en el último año ha logrado plantarle cara a Intel con sus Ryzen en diversos escenarios, aunque en gaming Intel seguía superándola en prestaciones.
Es probable que estos problemas acaben desequilibrando la balanza para muchos potenciales fabricantes y usuarios, que quizás ahora tengan un poderoso motivo para acudir a soluciones de AMD en lugar de una Intel que tendrá que reaccionar muy rápido y muy bien para solventar un problema realmente grave en sus procesadores.
Publicado
bajo licencia Creative Commons.
No hay comentarios.:
Publicar un comentario