Check point (un proveedor global de soluciones de seguridad IT) dio a conocer hace varios días la introducción del mecanismo de seguridad “Safe-Linking”, que dificulta la creación de exploits que manipulan la definición o el cambio de punteros a buffers asignados al realizar una llamada malloc.

El nuevo mecanismo «Safe-Linking» no bloquea completamente la posibilidad de explotar vulnerabilidades, pero con una sobrecarga mínima complica la creación de ciertas categorías de exploits, ya que además del desbordamiento del búfer explotado, es necesario encontrar otra vulnerabilidad que cause información sobre la ubicación del montón (heap) en la memoria.

Se prepararon parches de implementación Safe-Linking para Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) y Google TCMalloc, así como se propuso modernizar la protección en Chromium (desde 2012 Chromium ya se ha integrado con soluciones al mismo problema) Técnica de protección MaskPtr, pero la solución de Checkpoint demuestra un mejor rendimiento).

Los parches propuestos ya han sido aprobados para su entrega en la versión de agosto de Glibc 3.32 y Safe-Linking estará habilitado de forma predeterminada. En uClibc-NG, el soporte de enlace seguro se incluyó en la versión 1.0.33 y está habilitado de forma predeterminada. En gperftools (antiguo tcmalloc) se aceptan los cambios , pero se ofrecerán como una opción en una versión futura.

Los desarrolladores de TCMalloc se negaron a aceptar el cambio, citando un fuerte éxito en el rendimiento y la necesidad de agregar pruebas avanzadas para verificar regularmente que todo funcione correctamente.

Las pruebas realizadas por los ingenieros de Check point mostraron que el método Safe-Linking no conduce a un consumo de memoria adicional y el rendimiento al realizar operaciones de almacenamiento dinámico en promedio disminuye solo en un 0.02%, y en el peor de los casos en un 1.5%

Habilitar Safe-Linking conduce a la ejecución de 2-3 instrucciones de ensamblador adicionales con cada llamada a free () y 3-4 instrucciones al llamar a malloc(). No se requiere el inicio de la inicialización y generación de valores aleatorios.

Safe-Linking se puede usar no solo para aumentar la seguridad de varias implementaciones de almacenamiento dinámico, sino también para agregar controles de integridad a cualquier estructura de datos que use una lista de punteros vinculados individualmente ubicados al lado de los buffers.

El método es muy simple de implementar y solo requiere agregar una macro y aplicarla a los punteros al siguiente bloque del código (por ejemplo, para Glibc solo se cambian unas pocas líneas en el código).

La esencia del método es aplicar datos aleatorios del mecanismo de aleatorización de direcciones ASLR (mmap_base) para proteger listas enlazadas individualmente, como Fast-Bins y TCache. Antes de aplicar el valor del puntero al siguiente elemento de la lista, se realiza la conversión de máscara y la verificación de la alineación a lo largo del borde 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 la memoria donde se almacena este puntero.

Cuando se usa en el sistema ASLR (asignación aleatoria del diseño del espacio de direcciones), algunos de los bits L con la dirección base del montón contienen valores aleatorios que se usan como clave para codificar P (se extraen mediante una operación de desplazamiento de 12 bits para páginas de 4096 bytes).

Tal manipulación reduce el riesgo de capturar un puntero en un exploit, ya que el puntero no está almacenado en su forma original y para reemplazarlo, necesita conocer información sobre la ubicación del montón.

El método es efectivo para proteger contra ataques que utilizan la redefinición parcial de punteros (cambio de bytes bajos), reescritura completa de punteros (redirección al código del atacante) y cambio de posición de la lista en una dirección no alineada.

Como ejemplo, se muestra que el uso de Safe-Linking en malloc bloquearía la explotación de la vulnerabilidad CVE-2020-6007 descubierta recientemente por los mismos investigadores en la luz de fondo inteligente Philips Hue Bridge causada por el desbordamiento del búfer y permitiendo controlar el dispositivo.

Fuente: https://research.checkpoint.com