Checkpoint ha propuesto una técnica de protección llamada Safe-Linking, que complica la explotación de vulnerabilidades

La empresa Checkpoint ha presentado mecanismo de protección Safe-Linking que dificulta la creación de exploits que manipulan la definición o modificación de punteros a búferes asignados durante la llamada a malloc. Safe-Linking no bloquea completamente la explotación de vulnerabilidades, pero con costos mínimos complica significativamente la creación de ciertas categorías de exploits, ya que, además del desbordamiento de búfer, es necesario encontrar otra vulnerabilidad que cause una fuga de información sobre la ubicación del heap en la memoria.

Los parches con la implementación de Safe-Linking están preparados para Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) y Google TCMalloc, y también se han propuesto para la actualización de la protección en Chromium (en
Chromium desde 2012 ya está integrada una técnica enfocada en soluciones al mismo problema llamada MaskPtr, pero la solución de Checkpoint demuestra un rendimiento más alto).
Los parches propuestos ya han sido aprobados para su entrega en la publicación de agosto Glibc 3.32 y la aplicación de Safe-Linking se incluirá por defecto. En uClibc-NG, el soporte para Safe-Linking se incluyó en la versión 1.0.33 y se incluye por defecto. En gperftools (el antiguo tcmalloc), los cambios se han aceptado, pero se propondrán en una de las futuras versiones como opción.

Desarrolladores TCMalloc (el nuevo tcmalloc) se ha negado a aceptar el cambio, citando una fuerte disminución del rendimiento y la necesidad de agregar pruebas extensas para verificar regularmente que todo funcione correctamente. Las pruebas realizadas por ingenieros de Checkpoint mostraron que el método Safe-Linking no causa un consumo adicional de memoria, y el rendimiento durante las operaciones con el heap disminuye en promedio solo un 0.02%, y en el peor de los casos un 1.5% (para comparación, los costos en el método utilizado en Chromium se estiman como "menos del 2%"). La inclusión
de Safe-Linking provoca la ejecución de 2-3 instrucciones de ensamblador adicionales en cada llamada a free() y de 3-4 instrucciones en la llamada a malloc(). No se requiere ejecutar etapas de inicialización y generación de valores aleatorios.

Checkpoint ha propuesto una técnica de protección llamada Safe-Linking, que complica la explotación de vulnerabilidades

Safe-Linking no solo se puede aplicar para aumentar la seguridad de diversas implementaciones de heap, sino también para añadir mecanismos de control de integridad en cualquier estructura de datos que utilice listas enlazadas de punteros, ubicadas junto a los propios buffers. El método es muy simple de implementar y solo requiere la adición de un macro y su aplicación a los punteros del siguiente bloque en el código (por ejemplo, para Glibc cambia solo unas pocas líneas en el código). El método se reduce a los siguientes cambios:

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

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

— nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
…

La esencia del método es el uso de datos aleatorios del mecanismo de aleatorización de direcciones ASLR (mmap_base) para proteger listas enlazadas, como Fast-Bins y TCache. Antes de aplicarse al valor del puntero del siguiente elemento en la lista, se realiza una transformación mediante una máscara y se comprueba la alineación en el límite de la página de memoria. El puntero se reemplaza con el resultado de la operación «(L >> PAGE_SHIFT) XOR (P)», donde P es el valor del puntero y L es la ubicación en memoria donde se almacena este puntero.

Checkpoint ha propuesto una técnica de protección llamada Safe-Linking, que complica la explotación de vulnerabilidades

Al utilizarse en el sistema ASLR (Address Space Layout Randomization) parte de los bits L con la dirección base del heap contienen valores aleatorios, que se utilizan como clave para codificar P (extraídos mediante un desplazamiento de 12 bits para páginas de 4096 bytes). Tal manipulación reduce el riesgo de captura del puntero en un exploit, ya que el puntero no se almacena en su forma original y para reemplazarlo se necesita conocer la información sobre la ubicación del heap. Además, en el código del parche también hay un chequeo adicional de alineación del bloque, que impide que un atacante reemplace el puntero con un valor desalineado y requiere conocimiento sobre el número de bits con los que se ha realizado la alineación, lo que en sistemas de 64 bits permite bloquear 15 de 16 intentos de ataque que no toman en cuenta la alineación.

El método es efectivo para proteger contra ataques que utilizan la sobrescritura parcial de punteros (modificación de los bytes menos significativos), la sobrescritura completa de punteros (redirigir a código del atacante) y cambiar la posición de la lista a una dirección desalineada. Como ejemplo, se mostró que aplicar Safe-Linking en malloc podría bloquear la explotación recientemente descubierta los mismos investigadores de vulnerabilidades CVE-2020-6007 en la iluminación inteligente Philips Hue Bridge, provocada por un desbordamiento de búfer que permite obtener control sobre el dispositivo.

Fuente: opennet.ru

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster