Damián Digital

El misterioso caso de los parches de la tabla de aislamiento de páginas en Linux

Hay un error de seguridad embargado que afecta aparentemente a todas las arquitecturas de CPU contemporáneas que implementan la memoria virtual, lo que requiere cambios de hardware para resolver completamente. El desarrollo urgente de una mitigación de software se está haciendo en forma abierta y recientemente aterrizado en el kernel de Linux, y una mitigación similar comenzó a aparecer en núcleos NT en noviembre. En el peor de los casos, la corrección del software provoca una gran desaceleración en las cargas de trabajo típicas. Hay indicios de que el ataque tiene un impacto en los entornos de virtualización comunes, incluidos Amazon EC2 y Google Compute Engine, y pistas adicionales de que el ataque exacto puede implicar una nueva variante de Rowhammer.

Realmente no me preocupan mucho los problemas de seguridad, pero adoro un poco de intriga, y parece que cualquiera que normalmente escriba sobre estos temas está de alguna manera muy ocupado, o ya conoce los detalles y no está hablando, lo que me deja con unas pocas horas en el Día de Año Nuevo para ir a buscar tanta información sobre este misterio como pude reunir.

Tenga en cuenta que se trata en gran medida de un tipo de conexión de puntos invisibles, por lo que en su mayoría representa conjeturas hasta el momento en que se levanta el embargo. De todo lo que he visto, incluidos los vendedores involucrados, muchos fuegos artificiales y mucho drama es probable cuando llegue ese día.

LWN

El camino comienza con el estado actual de LWN del artículo de aislamiento de la tabla de páginas del núcleo publicado el 20 de diciembre. Es evidente por el tono que una gran cantidad de trabajo urgente por parte de los desarrolladores núcleo núcleo se ha vertido en la serie de parches KAISER publicado por primera vez en octubre por un grupo de investigadores de TU Graz en Austria.

El propósito de la serie es conceptualmente simple: evitar una variedad de ataques al desmantelar tanto kernel de Linux de la tabla de páginas de proceso mientras el proceso se está ejecutando en el espacio de usuario, obstaculizando enormemente los intentos de identificar rangos de direcciones virtuales del kernel del código de espacio de usuario sin privilegios .

El documento del grupo que describe KAISER, KASLR is Dead: Long Live KASLR , hace una referencia específica en su resumen para eliminar todo el conocimiento del espacio de direcciones del núcleo del hardware de administración de memoria mientras el código de usuario está activo en la CPU.

De particular interés con este conjunto de parches es que toca un núcleo, el pilar fundamental del kernel (y su interfaz con el espacio de usuario), y que obviamente se apura con la mayor prioridad. Al leer acerca de los cambios en la administración de memoria en Linux, generalmente la primera referencia a un cambio ocurre mucho antes de que el cambio se fusione, y generalmente después de numerosas rondas de revisión, rechazo y guerra de llama que abarca muchas estaciones y fases lunares.

La serie KAISER (ahora KPTI) se fusionó en un tiempo inferior a 3 meses.

LEER  Explicación de los defectos de seguridad del CPU con Spectre y Meltdown

Resumen: ASLR

En la superficie, los parches aparecen diseñados para garantizar que la distribución aleatoria del espacio de direcciones siga siendo efectiva: esta es una característica de seguridad de los sistemas operativos modernos que intenta introducir tantos bits aleatorios como sea posible en los rangos de direcciones para los objetos comúnmente mapeados.

Por ejemplo, al invocar /usr/bin/python, el enlazador dinámico dispondrá que la biblioteca C del sistema, el montón, la pila de subprocesos y el ejecutable principal reciban todos los rangos de direcciones asignados aleatoriamente:

$ bash -c ‘grep heap /proc/$$/maps’
019de000-01acb000 rw-p 00000000 00:00 0 [heap]
$ bash -c ‘grep heap /proc/$$/maps’
023ac000-02499000 rw-p 00000000 00:00 0 [heap]

Observe cómo el desplazamiento inicial y final para el montón de proceso bash cambia a lo largo de las ejecuciones.

El efecto de esta característica es que, si un error de gestión de búfer provoca que un atacante sobrescriba alguna dirección de memoria que apunta al código del programa, esa dirección se utilizará posteriormente en el flujo de control del programa, de modo que el atacante pueda desviar el flujo de control a un búfer que contiene los contenidos de su elección, se vuelve mucho más difícil para el atacante llenar el búfer con código de máquina que llevaría, por ejemplo, a la función de biblioteca de sistema () C invocada, ya que la dirección de esa función varía entre ejecuciones .

Este es un ejemplo simple, ASLR está diseñado para proteger muchos escenarios similares, incluyendo evitar que el atacante aprenda las direcciones de los datos del programa que pueden ser útiles para modificar el flujo de control o implementar un ataque.

KASLR es “simplemente” ASLR aplicado al kernel mismo: en cada reinicio del sistema, los rangos de direcciones que pertenecen al kernel se aleatorizan de forma que un atacante que logra desviar el flujo de control mientras se ejecuta en modo kernel no adivine las direcciones para las funciones y estructuras necesarias para implementar su ataque, como ubicar los datos de proceso actuales y cambiar el UID activo de un usuario no privilegiado a root, etc.

Malas noticias: la mitigación del software es costosa

La razón principal del antiguo comportamiento de Linux al mapear la memoria kernel en las mismas tablas de páginas que la memoria de usuario es que cuando el código del usuario desencadena una llamada al sistema, falla o un incendio de interrupción, no es necesario cambiar el diseño de la memoria virtual de el proceso de ejecución.

Como no es necesario cambiar el diseño de la memoria virtual, no es necesario eliminar los cachés de CPU altamente sensibles al rendimiento que dependen de ese diseño, principalmente el Translation Lookaside Buffer .

Con los parches de división de la tabla de páginas combinados, es necesario que el kernel vacíe estos cachés cada vez que el kernel comienza 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 de la derivación de TLB en cada llamada al sistema genera desaceleraciones muy visibles: @grsecurity midió un caso simple en el que el “du -s” de Linux sufrió una reducción del 50% en una CPU reciente de AMD.

34C3

En el CCC de este año, puedes encontrar a otro de los investigadores de TU Graz describiendo un ataque ASLR de JavaScript puro que funciona sincronizando cuidadosamente el funcionamiento de la unidad de administración de memoria de la CPU a medida que atraviesa las tablas de página que describen el diseño de la memoria virtual. El efecto es que a través de una combinación de sincronización de alta precisión y desalojo selectivo de líneas de caché de CPU, un programa Javascript que se ejecuta en un navegador web puede recuperar la dirección virtual de un objeto Javascript, permitiendo ataques posteriores contra errores de administración de memoria del navegador.

Entonces, de nuevo, en la superficie, tenemos un grupo que crea los parches KAISER que también demuestran una técnica para desenmascarar las direcciones ASLR’d, y la técnica, demostrada mediante Javascript, se puede volver a implementar inminentemente contra un núcleo del sistema operativo.

LEER  Un error de MS Office con 17 años de antigüedad permite a los piratas informáticos instalar malware sin interacción del usuario

Resumen: memoria virtual

En el caso habitual, cuando algún código de máquina intenta cargar, almacenar o saltar a una dirección de memoria, las CPU modernas primero deben traducir esta dirección virtual a una dirección física, recorriendo una serie de matrices administradas por OS (denominadas tablas de página). ) que describen una asignación entre la memoria virtual y la RAM física instalada en la máquina.

La memoria virtual es posiblemente la característica de robustez más importante en los sistemas operativos modernos: es lo que evita, por ejemplo, que un proceso de extinción bloquee el sistema operativo, un error del navegador web bloquee su entorno de escritorio o una máquina virtual ejecutándose en Amazon EC2 desde efectuar cambios en otra máquina virtual en el mismo host.

El ataque funciona explotando el hecho de que la CPU mantiene numerosas cachés, y manipulando cuidadosamente los contenidos de estas cachés, es posible inferir a qué direcciones se dirige la unidad de administración de memoria detrás de las escenas mientras recorre los diversos niveles de tablas de páginas, ya que un acceso sin almacenamiento en caché tardará más tiempo (en tiempo real) que un acceso en caché. Al detectar a qué elementos de la tabla de páginas se accede, es posible recuperar la mayoría de los bits en la dirección virtual que la MMU estaba ocupada resolviendo.

Evidencia de motivación, pero no de pánico

Hemos encontrado motivación, pero hasta ahora no hemos visto nada que justifique el puro pánico detrás de este trabajo. ASLR en general es una mitigación imperfecta y una última línea de defensa: apenas hay un período de 6 meses en el que incluso una persona no preocupada por la seguridad puede leer acerca de algún nuevo método para desenmascarar punteros ASLR, y la realidad ha sido así. durante todo el tiempo que ASLR haya existido.

Reparar ASLR solo no es suficiente para describir la motivación de alta prioridad detrás del trabajo.

Evidencia: es un error de seguridad de hardware

A partir de la lectura de la serie de parches, varias cosas son obvias.

En primer lugar, como señala @grsecurity , algunos comentarios en el código han sido redactados y, además, el archivo de documentación principal que describe el trabajo actualmente falta por completo del árbol fuente de Linux.

Al examinar el código, se estructura en forma de un parche de tiempo de ejecución aplicado al inicio solo cuando el núcleo detecta que el sistema se ve afectado, utilizando exactamente el mismo mecanismo que, por ejemplo, aplica mitigaciones para el infame error Pentium F00F:

Más pistas: Microsoft también ha implementado la división de tablas de páginas

Desde una pequeña búsqueda en el árbol fuente de FreeBSD, parece que hasta ahora otros sistemas operativos libres no están implementando la división de tablas de páginas, sin embargo, como señaló Alex Ioniscu en Twitter , el trabajo ya no está limitado a Linux: kernels NT públicos desde tan temprano ya que noviembre comenzó a implementar la misma técnica.

 

Conjetura: Rowhammer

Profundizando en el trabajo de los investigadores de TU Graz, encontramos When rowhammer solo toca una vez , un anuncio el 4 de diciembre de una nueva variante del ataque de Rowhammer:

En este artículo, presentamos novedosas primitivas de ataque y explotación de Rowhammer, que muestran que incluso una combinación de todas las defensas es ineficaz. Nuestra nueva técnica de ataque, el martilleo de una sola ubicación, rompe las suposiciones previas sobre los requisitos para activar el error de Rowhammer

Como resumen rápido, Rowhammer es una clase de problema fundamental para la mayoría (¿todos?) De DRAM de productos básicos, como la memoria en una computadora promedio. Mediante la manipulación precisa de un área de la memoria, es posible causar la degradación del almacenamiento en un área de memoria relacionada (pero por lo demás lógicamente distinta). El efecto es que Rowhammer se puede usar para voltear bits de memoria a los que el código de usuario no privilegiado no debería tener acceso, como bits que describen la cantidad de acceso que ese código debería tener al resto del sistema.

Encontré este trabajo en Rowhammer particularmente interesante, sobre todo porque su lanzamiento está muy cerca de los parches de división de la tabla de páginas, pero debido a que los ataques de Rowhammer requieren un objetivo: debes conocer la dirección física de la memoria que estás intentando mutar, y un primer paso para aprender una dirección física puede ser aprender una dirección virtual, como en el trabajo de desenmascaramiento de KASLR.

LEER  Linux, crucial en el descubrimiento del bosón de Higgs

Guesswork: afecta a los principales proveedores de la nube

En la lista de distribución del kernel podemos ver, además de los nombres de los mantenedores del subsistema, las direcciones de correo electrónico que pertenecen a los empleados de Intel, Amazon y Google. La presencia de los dos principales proveedores de servicios en la nube es particularmente interesante, ya que nos proporciona una pista sólida de que el trabajo puede estar motivado en gran parte por la seguridad de la virtualización.

Lo que lleva a aún más conjeturas: la memoria RAM de la máquina virtual y las direcciones de memoria virtual utilizadas por esas máquinas virtuales se representan finalmente como grandes matrices contiguas en la máquina host, matrices que, especialmente en el caso de solo 2 inquilinos en una máquina host, son asignados por asignadores de memoria en los kernels Xen y Linux que probablemente tengan un comportamiento muy predecible.

Conjetura favorita: es un ataque de escalada de privilegios contra hipervisores

Poniéndolo todo junto, no me sorprendería si comenzamos 2018 con el lanzamiento de la madre de todos los errores de escalamiento de privilegios de hipervisor, o algo similarmente sistemático como para impulsar tanta urgencia, y la presencia de tantos nombres interesantes en el conjunto de parches CC lista.

Un último tidbit, mientras he perdido mi lugar leyendo los parches, hay algún código que marca específicamente paravirtual o HVM Xen como no afectado.

Invertir en palomitas de maíz, 2018 va a ser divertido

Es totalmente posible que esta suposición esté a millas de distancia de la realidad, pero una cosa es segura, serán algunas semanas emocionantes cuando se publique lo que sea que se publique.

 

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

A %d blogueros les gusta esto: