¡Vd. usa un navegador obsoleto!

Es posible que la página no se visualice correctamente.

Vulnerables

Уязвимые

Otras ediciones de este tema (40)
  • añadir a favoritos
    Añadir a marcadores

Hardware vulnerable

Consultas: 678 Comentarios: 3 Ranking: 10

lunes 15 de enero de 2018

Un conjunto de noticias navideñas sobre las vulnerabilidades encontradas en varios procesadores causó bastante pánico. Los ingenieros informáticos de todo el mundo tuvieron que analizar las vulnerabilidades durante las fiestas y buscar los modos de protegerse. Pero ¿Qué fue detectado?

En realidad, fueron detectadas tres vulnerabilidades: una fue llamada Meltdown (CVE-2017-5754), y las dos otras recibieron un nombre común Spectre (CVE-2017-5753 и CVE-2017-5715). Para simplificar nuestra tarea, vamos a analizar solo la primera de las tres.

En general, es lógico que en un equipo puedan trabajar usuarios con varios permisos simultáneamente. Y cada uno de ellos puede iniciar aplicaciones con varios permisos de acceso. Así mismo, los datos se procesan en uno (o varios) procesadores de tal modo que un programa con permisos limitados no tiene acceso a los datos si estos permisos no son suficientes. Hasta ahora en SO o en programas de vez en cuando se detectaban vulnerabilidades que permitían mejorar los privilegios para acceder a los datos cerrados, pero no se sabía nada sobre las vulnerabilidades de este tipo a nivel de procesadores.

Las aplicaciones en vez de acceso directo a la memoria física reciben los espacios de direcciones compartidos que se proyectan en la memoria física de tal forma que los espacios de varias aplicaciones no se cruzan. El control de los espacios de direcciones se realiza a nivel de hardware— por el bloque MMU, Memory Management Unit

https://geektimes.ru/post/297029

Esta situación recuerda un inicio de programas en máquinas virtuales, cuando cada una funciona con su memoria que se dedica en caso necesario. Así mismo, el control de los datos de cada programa se realiza a nivel hardware, para que los mismos no se cruzan. Y todo estaría bien sin la “magia”.

Supongamos que Vd. va por la calle. Para llegar de punto А a punto B, Vd. debe hacer N pasos. Vd. realiza la misma secuencia de acciones – los pasos. Así mismo, se puede pronosticar que en caso de hacer un paso de punto А1 a punto А2, es muy probable que Vd. haga pasos similares de А2 a А3, de А3 a А4 etc. Y en caso de poder hacer todos los pasos en uno, Vd. podría estar en el punto B enseguida.

Así funcionan los procesadores modernos. El cálculo de cada paso del programa es un proceso largo y bastante caro. Así mismo, la mayoría de las acciones de programas son lineales y no se dividen en varias operaciones paralelas. Si los comandos del programa se ejecutaran paso por paso, todo funcionaría muy lento porque en este caso el procesador no se usaría completamente. Por lo tanto, el procesador separa el código ejecutable en partes y procesa estas partes de forma paralela, ejecuta tanto el código que debe ejecutarse en el momento como el código que debe ejecutarse más tarde. En lenguaje de la ciencia esto se llama la función de realización especulativa de instrucciones y predicciones de bifurcaciones.

Por ejemplo:

Estos algoritmos son necesarios para el alto rendimiento de todo el sistema si todos los dispositivos periféricos, incluida la memoria operativa, funcionan más lentamente que el procesador central. Si una instrucción ejecutada necesita datos desde fuera, durante el periodo de espera el procesador en vez de esperar empieza a ejecutar el código siguiente, a base de la información sobre qué datos llegan con mayor probabilidad.

https://geektimes.ru/post/297029

Vamos a analizar este caso. Al calcular el paso siguiente, el procesador no sabe qué datos estarán disponibles para el programa al iniciar este paso, por lo tanto, supone que estarán disponibles los datos de cualquier tipo – así mismo, los datos a los cuales el programa en realidad no tiene acceso. Vamos a ver un ejemplo muy simple. El programa declara un conjunto de datos, por ejemplo, de 200 elementos y sigue realizando las mismas acciones con este conjunto durante mucho tiempo. El procesador empieza a realizar estos pasos con antelación. Y en este momento en el código del programa (aún no ejecutado) se registra una solicitud de datos fuera del conjunto (no todos los lenguajes de programación automáticamente prohíben salir del conjunto, esta acción puede ser legítima). Por lo tanto, el procesador solicitará los datos que en principio no estaban disponibles para el programa.

¿Qué pasa si una variable x se encuentra no solamente fuera de un conjunto en concreto, sino en general fuera de la memoria disponible para este proceso? El procesador aun así ejecuta la segunda línea del código. Lo que pasa es que para el funcionamiento del módulo MMU cuya tarea es detectar si el procesador en cuestión puede leer algo en la dirección x, también se necesita tiempo, por lo tanto, el mecanismo de ejecución especulativa trata MMU de la misma forma que al bus externo — empieza la ejecución antes de que llegue una respuesta de MMU diciendo que este código es correcto.

Si MMU informa que el código no es correcto, el procesador simplemente restablece todo lo calculado.

Pero las predicciones no se cumplen, y no recibimos los datos esperados, sino otros datos para realizar el paso ya calculado. No es ningún problema, los cálculos se restablecen y vuelven a realizarse. Los datos recibidos que no deben estar disponibles, no se entregan a programa. Y todo sería seguro si no fuera por otra tecnología de aceleración– caché.

En caché entran todos los datos procesados por el procesador. La caché es completamente autónoma, no sabe ni desea saber cómo entran los datos en la misma, si han sido cargados por causa de una ejecución especulativa o consecutiva ni si la ejecución especulativa ha sido considerada correcta. Los datos llegaron y están en la caché.

Es decir, los resultados del cálculo erróneo están en la caché y no se eliminan una vez realizado el cálculo erróneo. La tarea de un malintencionado es sacar estos datos de la caché. El problema es que el programa no puede leer la caché directamente. Pero por el periodo de la respuesta se puede detectar si el área solicitada ha sido leída por el procesador anteriormente. Si es así, el periodo de respuesta es inferior.

Como sabemos, en los programas hay datos y enlaces a los mismos. Un enlace es, por ejemplo, una dirección en la cual uno debe solicitar la información y los datos es la información que se entrega por esta solicitud. Por supuesto, si los datos se solicitaban anteriormente, se encuentran más rápido.

Por ejemplo, una aplicación tiene disponibles las direcciones 0...9999, y el núcleo — 10000...20000, las cifras aquí no son importantes. Y hacemos una construcción que está en el código de tal forma que el procesador la ejecutará en modo especulativo (por ejemplo, en la repetición 1000 del mismo ciclo, 999 repeticiones anteriores del mismo se realizaban correctamente) y que será un direccionamiento indirecto por valor que está en la dirección 15000.

  1. El procesador en modo especulativo lee el valor en la dirección 15000. Supongamos que allí hay 98 (una acción realizada con antelación durante la cual se solicitan los datos supuestamente no disponibles para la aplicación – recordamos que la aplicación tiene disponibles las direcciones 0...9999).
  2. El procesador lee el valor que está en la dirección 98 (el valor que está en la dirección 15000).
  3. Llega una respuesta de MMU diciendo que la dirección 15000 no es válida (recordamos que los cálculos se realizan antes de la comprobación de accesibilidad real de los datos).
  4. El procesador restablece la cadena y en vez del valor en la dirección 98 nos entrega un error.
  5. Nuestra aplicación empieza a leer las direcciones de 0 y superior en su propio espacio de direcciones (tiene derecho a hacerlo), calculando el tiempo que se necesita para leer cada dirección y no leyéndolas por orden para no entrenar el acceso especulativo.
  6. En la dirección 98 el tiempo de acceso resulta ser varias veces inferior que en otras direcciones.

De esta forma entendemos que alguien ya había leído algo en esta dirección, y la misma, como resultado, está en caché. ¿Quién pudo ser? Es nuestro procesador. En la dirección 15000, respectivamente, hay valor 98.

De esta forma podemos leer toda la memoria del núcleo del sistema, al cual, a su vez, en SO modernos se proyecta toda la memoria física del equipo.

¿Qué puede someterse a Meltdown?

Como mínimo, todos los procesadores Intel de la línea Core, todos los procesadores Intel de la línea Xeon, todos los procesadores Intel de líneas Celeron и Pentium en el núcleo de la familia Core.

También se someten a la vulnerabilidad los procesadores en núcleos ARM Cortex-A75 que aún no se usan para ningunos dispositivos finales, y el primer procesador— Qualcomm Snapdragon 845 en el núcleo Kryo 385 basado en Cortex-A75 y Cortex-A53 — fue declarado solo hace un mes. Es muy probable que Kryo 385 también será vulnerable a Meltdown.

Según la declaración de Apple, «todos los dispositivos iOS » se someten a Meltdown. Eso no se refiere a todos los procesadores usados alguna vez en iPhone/iPad (al fin y al cabo, en iPhone 4 se usa el núcleo estándar Cortex-A8), нpero los procesos ARM en modelos modernos de iPhone y iPad pueden considerarse vulnerables.

Para más información, consulte los enlaces https://geektimes.ru/post/297029 y https://geektimes.ru/post/297031.

#vulnerabilidad #exploit

El mundo de antivirus recomienda

La situación es alarmante, pero hay unas cosas importantes.

  1. Las vulnerabilidades encontradas no le permiten al malintencionado obtener acceso remoto al sistema. Para usar las vulnerabilidades, el archivo nocivo primero debe ser cargado en el sistema. Es decir que tanto el antvirus como la restricción de permisos de instalación de aplicaciones son nuestros mejores amigos para proteger procesadores.
  2. Los parches que protegen de Meltdown, mueven el área de la memoria del núcleo a otra área, como resultado, los datos se separan no slo por el control a nivel hardware, sino que el control de acceso también se separa por direcciones. Como el control pasa de la parte hardware a la parte software, las aplicaciones se ralentizan al realizar solicitudes del sistema. Pero hay una cosa importante. Las aplicaciones de usuario no necesitan mucho estas solicitudes de sistema. Por lo tanto, según los datos existentes, en los juegos casi nada se ralentiza y se puede hacer un parche sin ningún problema. Pero para proteger los servidores, los mismos deben ser aislados completamente. Si no hay nuevos archivos, no hay posibilidad de usar la vulnerabilidad. Pero es mejor hacer un parche allí también.
    En las pruebas sintéticas Vd. realidad puede tener caídas hasta 30%, pero en el sistema real, hasta un sistema que usa activamente las solicitudes de sistema, la caída será inferior, también existe la red, la memoria, todo esto influirá. En escala de centros de datos de la clase GCP, AWS, FB la parte de estos servidores no es la más grande, lo cual causa una reducción total de rendimiento de unos por cientos. Serán afectados los clientes cuyos servidores de someten a la degradación del rendimiento, pero creo que no son muchos.
  3. Javascript en navegadores debe estar desactivado de forma predeterminada.

[Twitter]

Nos importa su opinión

Para redactar un comentario, debe iniciar sesión para entrar en su cuenta del sitio web Doctor Web. - Si aún no tiene la cuenta, puede crearla.

Comentarios de usuarios