Ha
aparecido un indicador en el kernel de Linux que desactiva la protección contra las vulnerabilidades de Spectre v4 en todos los procesos secundarios que se ejecutan en el servidor. Más sobre el nuevo parámetro, debajo del corte.
/ Flickr / Rie H / CC BY / Foto modificada¿Por qué necesita deshabilitar la protección?
El grupo de vulnerabilidad del procesador Specter se conoció por primera vez a principios de 2018, y en los próximos meses esta familia se reponía con nuevos "agujeros de seguridad". Las vulnerabilidades están asociadas con la operación de sistemas que aumentan el rendimiento del procesador (escritura
especulativa, lectura y
predicción de transiciones ) y
permiten a los atacantes eludir los mecanismos de aislamiento de memoria en los procesadores de Intel y AMD.
Para cerrar las vulnerabilidades, los desarrolladores de sistemas operativos emiten parches, pero instalarlos a menudo conduce a una disminución en la velocidad de los servidores. Por ejemplo, en máquinas Linux, algunos parches Spectre
reducen el rendimiento en un 30–50%.
Los administradores del sistema no estaban satisfechos con el problema, especialmente en los grandes centros de datos. Comenzaron a pedir a los desarrolladores del kernel de Linux que deshabilitaran selectivamente la protección Spectre. Algunas de las vulnerabilidades descubiertas son solo de naturaleza teórica y, en varios sistemas, básicamente no pueden hacer daño. Por ejemplo, las granjas de procesamiento y las supercomputadoras sin conexión están desconectadas de Internet, por lo que
no temen las inyecciones de códigos maliciosos.
El equipo de Linux se reunió con los usuarios e introdujo varias funciones que desactivan la protección contra vulnerabilidades Spectre v1, v2 (hablaremos más sobre ellos más adelante) y v4. El último de ellos se introdujo a principios de febrero para todas las versiones actuales del kernel: este es el nuevo indicador PR_SPEC_DISABLE_NOEXEC.
Qué y por qué deshabilita la función
La vulnerabilidad de Specter v4 se llama Bypass de almacenamiento especulativo. Permite que el malware acceda a resultados informáticos especulativos que el procesador descartó anteriormente como innecesarios.
Esta situación ocurre cuando la CPU se turna para leer y escribir usando direccionamiento indirecto. La lectura ocurre más a menudo que la escritura, y el procesador puede usar datos de la memoria para determinar la dirección de lectura, sin esperar el cálculo del desplazamiento del direccionamiento indirecto. Si, después de calcular el desplazamiento, se detecta una intersección de las áreas de memoria para escritura y lectura (es decir, la lectura se realizó desde el área incorrecta), la segunda operación se realiza nuevamente y el resultado especulativo se descarta.
En teoría, resulta que si un atacante conoce las direcciones y la estructura de las celdas de memoria, puede extraer datos de ellas, como las claves de cifrado.
El parche para Specter v4 apareció en el kernel de Linux unos días después de la publicación de información sobre la vulnerabilidad; de forma predeterminada,
desactivaba la función de
desambiguación de memoria , lo que permitía la ejecución extraordinaria de comandos. Pero esto
ralentizó las operaciones de E / S
del procesador en un 10–40%.
/ Flickr / Rie H / CC BY-SAY a principios de junio de 2018, la versión 4.17 del kernel permitió desactivar esta protección. Hubo un problema: el parámetro no se pasó del proceso primario al secundario. Para ellos, la protección tenía que deshabilitarse manualmente, lo que causaba inconvenientes a los administradores del sistema. Pero a principios de febrero, los desarrolladores del kernel implementaron la bandera
PR_SPEC_DISABLE_NOEXEC . Complementa la función anterior y copia el modo de funcionamiento del parche desde Spectre v4 del proceso principal al secundario. PR_SPEC_DISABLE_NOEXEC es parte de prctl, y puede habilitarlo al iniciar cualquier proceso nuevo.
Lo que dicen los expertos
En la lista de correo de desarrolladores de kernel de Linux, la introducción de la nueva bandera fue
escrita por Waiman Long de Red Hat. Según él, la protección de Specter v4 afecta significativamente el rendimiento de las aplicaciones que realizan muchas operaciones de escritura, como las bases de datos. PR_SPEC_DISABLE_NOEXEC ayudará a automatizar la verificación para deshabilitar el parche y acelerar los servidores con una gran cantidad de procesos que se ejecutan simultáneamente.
Al mismo tiempo, los participantes en la comunidad de TI notan que en ciertas situaciones, el manejo descuidado de la nueva bandera
puede tener consecuencias desagradables.
"Vale la pena señalar que en algunos entornos no es seguro desactivar la protección de Specter v4", dice Sergey Belkin, jefe del departamento de desarrollo del proveedor de IaaS 1cloud.ru . - Estos incluyen, por ejemplo, servicios web que utilizan Java y JavaScript. La divulgación del contenido del proceso de control por código administrado puede ser fatal para la seguridad de la aplicación ".
Acerca de otros parches Spectre en el kernel de Linux
Además del indicador PR_SPEC_DISABLE_NOEXEC, el kernel de Linux tiene otros parámetros que deshabilitan la protección de Specter.
El primero es
nospectre_v2 . La función desactiva la protección de Specter v2, que permite a los atacantes
usar el bloque de predicción de transición para "forzar" al procesador a realizar una operación especulativa en un módulo de memoria específico. Para protección, el parche
deshabilita la función de predicción de transición indirecta y prohíbe la transferencia de información recibida entre subprocesos en el mismo núcleo de CPU.
Deshabilitar la protección conduce a un aumento en el rendimiento del procesador en un 30%, así es como
cayó después de instalar un parche de Specter v2. Incluso el creador de Linux, Linus Torvalds, apoyó la nueva característica. Según él, la vulnerabilidad amenaza solo a los procesadores con la función
SMT , en este caso particular será más rentable desactivarla.
El segundo parámetro,
nospectre_v1 , desactiva la protección de la primera opción de Spectre. Con la ayuda del malware, los piratas informáticos pueden hacer que el procesador prediga incorrectamente el resultado de una transición condicional y descartar los resultados de los cálculos especulativos en el área de memoria que los piratas informáticos necesitan. Aunque el parche de v1 no afecta significativamente el rendimiento (según algunos
informes , la reducción de la velocidad del procesador puede descuidarse en absoluto), los desarrolladores
pidieron agregar la capacidad de deshabilitar esta protección al núcleo. Esto nos permitió simplificar la estructura de las redes aisladas del acceso externo.
La comunidad del kernel de Linux sigue siendo fiel a la idea de libre elección que Linus Torvalds
estableció al principio: los propios usuarios son responsables de equilibrar la seguridad y el rendimiento de los sistemas Linux. Por lo tanto, debemos esperar que cuando se descubra una nueva vulnerabilidad similar a la de Spectre en el núcleo, aparecerán tanto un parche como la capacidad de deshabilitarlo.
Publicaciones de nuestro blog corporativo: