Checkpoint propuso la técnica de protección Safe-Linking, lo que dificulta la explotación de vulnerabilidades

Compañía de punto de control presentado Mecanismo de protección Safe-Linking, que dificulta la creación de exploits que manipulen la definición o modificación de punteros a los buffers asignados al ejecutar una llamada malloc. Safe-Linking no bloquea completamente la posibilidad de explotar vulnerabilidades, pero con una sobrecarga mínima complica significativamente la creación de ciertas categorías de exploits, ya que además del desbordamiento del búfer explotable, es necesario encontrar otra vulnerabilidad que provoque la fuga de información sobre la ubicación del montón en la memoria.

Se han preparado parches que implementan Safe-Linking para Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) y Google TCMalloc, y también se proponen actualizar la protección en Chromium (en
Desde 2012, Chromium ya ha incorporado la técnica de protección MaskPtr destinada a resolver el mismo problema, pero la solución de Checkpoint demuestra un mayor rendimiento).
Los parches sugeridos ya han sido aprobados para su entrega en la versión de agosto. Glibc 3.32 y Safe-Linking estará habilitado de forma predeterminada. uClibc-NG admite enlaces seguros entró incluido en la versión 1.0.33 y está habilitado de forma predeterminada. Cambios en gperftools (antiguo tcmalloc) aceptado, pero se ofrecerá como opción en una versión futura.

Desarrolladores TCMalloc (nuevo tcmalloc) se negó a aceptar cambiar, citando una grave degradación del rendimiento y la necesidad de agregar pruebas exhaustivas para comprobar periódicamente que todo funciona como se esperaba. Las pruebas realizadas por los ingenieros de Checkpoint mostraron que el método Safe-Linking no genera un consumo adicional de memoria y que el rendimiento al realizar operaciones de montón se reduce en promedio solo un 0.02% y, en el peor de los casos, un 1.5% (a modo de comparación, la sobrecarga en El método utilizado en el cromo se estima en “menos del 2%”). Inclusión
Safe-Linking da como resultado que se ejecuten de 2 a 3 instrucciones de ensamblaje adicionales cada vez que se llama a free(), y de 3 a 4 instrucciones cada vez que se llama a malloc(). No es necesario ejecutar las etapas de inicialización y generación de valores aleatorios.

Checkpoint propuso la técnica de protección Safe-Linking, lo que dificulta la explotación de vulnerabilidades

Safe-Linking se puede utilizar no sólo para mejorar la seguridad de varias implementaciones de montón, sino también para agregar controles de integridad a cualquier estructura de datos que utilice listas de punteros enlazados individualmente colocados junto a los propios buffers. El método es muy sencillo de implementar y sólo requiere agregar una macro y aplicarla a punteros al siguiente bloque del código (por ejemplo, para Glibc cambios sólo unas pocas líneas de código). El método se reduce a los siguientes cambios:

+#definir PROTECT_PTR(pos, ptr) \
+ ((__tipode (ptr)) ((((tamaño_t) pos) >> 12) ^ ((tamaño_t) ptr)))

+#definir REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- siguientep = p->fd;
+ siguientep = REVEAL_PTR (p->fd);
...

La esencia del método es utilizar datos aleatorios del mecanismo de aleatorización de direcciones ASLR (mmap_base) para proteger listas vinculadas individualmente como Fast-Bins y TCache. Antes de aplicar el valor a un puntero al siguiente elemento de la lista, realiza una conversión de máscara y comprueba la alineación de la página. El puntero se reemplaza por el resultado de la operación "(L >> PAGE_SHIFT) XOR (P)", donde P es el valor del puntero y L es la ubicación de memoria donde se almacena el puntero.

Checkpoint propuso la técnica de protección Safe-Linking, lo que dificulta la explotación de vulnerabilidades

Cuando se utiliza en el sistema. ASLR (Aleatorización del diseño del espacio de direcciones) parte de los bits L con la dirección base del montón contiene valores aleatorios que se utilizan como clave para codificar P (extraído mediante una operación de desplazamiento de 12 bits para páginas de 4096 bytes). Esta manipulación reduce el riesgo de secuestro del puntero en un exploit, ya que el puntero no se almacena en su forma original y reemplazarlo requiere conocimiento de la asignación del montón. Además, el código del parche también contiene una verificación adicional de la alineación del bloque, que no permite que un atacante reemplace un puntero con un valor no alineado y requiere conocimiento de la cantidad de bits que están alineados, lo que en sistemas de 64 bits también permite el bloqueo. 15 de 16 intentos de ataque que no tienen en cuenta el alineamiento.

El método es eficaz para proteger contra ataques que utilizan la reescritura parcial del puntero (cambiando los bytes bajos), la reescritura completa del puntero (redireccionando al código del atacante) y cambiando la posición de la lista en una dirección no alineada. A modo de ejemplo, se muestra que el uso de Safe-Linking en malloc permitiría bloquear la explotación recientemente. identificado por los mismos investigadores de vulnerabilidad CVE-2020-6007 en la luz inteligente Philips Hue Bridge, causado por un desbordamiento del búfer y que le permite obtener el control del dispositivo.

Fuente: opennet.ru

Añadir un comentario