Este artículo se centrará en una pequeña característica de seguridad agregada en GNU ld a la versión 2.30 en diciembre de 2018. En ruso, esta mejora se mencionó en opennet con la siguiente anotación:

Modo "-z código separado", que aumenta la seguridad de los archivos ejecutables a costa de un pequeño aumento en el tamaño y el consumo de memoria

Vamos a resolverlo. Para explicar de qué tipo de problema de seguridad estamos hablando y cuál es la solución, comencemos con las características generales de las vulnerabilidades de vulnerabilidad binaria.

Explotar problemas de control de flujo

Un atacante puede transferir datos al programa y manipularlos de esta manera con la ayuda de varias vulnerabilidades: escribir por índice más allá del límite de la matriz, copiar de forma insegura las cadenas, usar objetos después del lanzamiento. Tales errores son típicos para el código del programa C y C ++ y pueden provocar daños en la memoria con ciertos datos de entrada para el programa.

El elemento de explotación clásico de las vulnerabilidades similares a la corrupción de la memoria es sobrescribir un puntero en la memoria. Luego, el programa utilizará el puntero para transferir el control a otro código: para llamar a un método o función de clase desde otro módulo, para regresar desde una función. Y como el puntero se sobrescribió, el atacante interceptará el control, es decir, se ejecutará el código preparado por él. Si está interesado en variaciones y detalles de estas técnicas, le recomendamos leer el documento .

Este momento común de la operación de tales exploits es conocido, y aquí para el atacante las barreras se han colocado durante mucho tiempo:

1. Comprobación de la integridad de los punteros antes de pasar el control: cookies de pila, protección de flujo de control, autenticación de puntero
2. Aleatorización de direcciones de segmento con código y datos: aleatorización del diseño del espacio de direcciones
3. Evitar que el código ejecute segmentos de código externos: protección de espacio ejecutable

A continuación, nos centraremos en proteger este último tipo.

protección de espacio ejecutable

La memoria del programa es heterogénea y está dividida en segmentos con diferentes derechos: leer, escribir y ejecutar. Esto está garantizado por la capacidad del procesador para marcar páginas de memoria con marcas de acceso en las tablas de páginas. La idea de protección se basa en una estricta separación de código y datos: los datos recibidos del atacante en el proceso de procesamiento deben colocarse en segmentos no ejecutables (pila, montón) y el código del programa en sí, en segmentos separados inmutables . Por lo tanto, esto debería privar al atacante de la capacidad de colocar y ejecutar código extraño en la memoria.

Para evitar la prohibición de la ejecución de código en segmentos de datos, se utilizan técnicas de reutilización de código. Es decir, el atacante transfiere el control a los fragmentos de código (en lo sucesivo denominados gadgets) ubicados en las páginas ejecutables. Las técnicas de este tipo son de diversa dificultad, en orden creciente:

• pasar el control a una función que hace lo suficiente para el atacante: a la función system () con un argumento controlado para ejecutar comandos de shell arbitrarios (ret2libc)
• transferir el control a una función o cadena de dispositivos que deshabilitarán la protección o harán que parte de la memoria sea ejecutable (por ejemplo, llamando a mprotect() ), seguido de la ejecución de código arbitrario
• ejecución de todas las acciones deseadas utilizando una larga cadena de gadgets

Por lo tanto, el atacante se enfrenta a la tarea de reutilizar el código existente en un volumen u otro. Si esto es algo más complicado que volver a una sola función, se requerirá una cadena de gadgets . Para buscar gadgets por segmentos ejecutables, hay herramientas: ropper , ropgadget .

Hoyo READ_IMPLIES_EXEC

Sin embargo, a veces las áreas de memoria con datos pueden ser ejecutables, y los principios de separación de código y datos descritos anteriormente se violan claramente. En tales casos, el atacante se ahorra la molestia de encontrar dispositivos o funciones para reutilizar el código. Un hallazgo interesante de este tipo fue la pila ejecutable y todos los segmentos de datos en el mismo "firewall industrial".

Listado /proc/$pid/maps :

 00008000-00009000 r-xp 00000000 08:01 10 /var/flash/dmt/nx_test/a.out 00010000-00011000 rwxp 00000000 08:01 10 /var/flash/dmt/nx_test/a.out 00011000-00032000 rwxp 00000000 00:00 0 [heap] 40000000-4001f000 r-xp 00000000 1f:02 429 /lib/ld-linux.so.2 4001f000-40022000 rwxp 00000000 00:00 0 40027000-40028000 r-xp 0001f000 1f:02 429 /lib/ld-linux.so.2 40028000-40029000 rwxp 00020000 1f:02 429 /lib/ld-linux.so.2 4002c000-40172000 r-xp 00000000 1f:02 430 /lib/libc.so.6 40172000-40179000 ---p 00146000 1f:02 430 /lib/libc.so.6 40179000-4017b000 r-xp 00145000 1f:02 430 /lib/libc.so.6 4017b000-4017c000 rwxp 00147000 1f:02 430 /lib/libc.so.6 4017c000-40b80000 rwxp 00000000 00:00 0 be8c2000-be8d7000 rwxp 00000000 00:00 0 [stack] 

Aquí puede ver la tarjeta de memoria del proceso de utilidad de prueba. Un mapa consta de áreas de memoria: filas de tabla. Primero, preste atención a la columna derecha: explica el contenido del área (segmentos de código, datos de las bibliotecas de funciones o el programa en sí) o su tipo (montón, pila). A la izquierda, en orden, se encuentra el rango de direcciones que ocupa cada área de memoria y, además, las banderas de derechos de acceso: r (lectura), w (escritura), x (ejecución). Estas banderas determinan el comportamiento del sistema cuando se intenta leer, escribir y ejecutar memoria en estas direcciones. Si se viola el modo de acceso designado, se produce una excepción.

Tenga en cuenta que casi toda la memoria dentro del proceso es ejecutable: la pila, el montón y todos los segmentos de datos. Esto es un problema Obviamente, la presencia de páginas de memoria rwx facilitará la vida de un atacante, ya que podrá ejecutar libremente su código en dicho proceso en cualquier lugar donde su código llegue al transferir datos (paquetes, archivos) a dicho programa para su procesamiento.

¿Por qué surgió tal situación en un dispositivo moderno que admite la prohibición de la ejecución de código en páginas de datos con hardware, la seguridad de las redes corporativas e industriales depende del dispositivo y el problema sonoro y su solución se conocen desde hace mucho tiempo?

Esta imagen está determinada por el comportamiento del núcleo durante la inicialización del proceso (asignación de una pila, montón, carga del ELF principal, etc.) y durante la ejecución de las llamadas al proceso nuclear. El atributo clave que afecta esto es el indicador de personalidad READ_IMPLIES_EXEC . El efecto de este indicador es que cualquier memoria legible también se vuelve ejecutable. Se puede establecer un indicador en su proceso por varias razones:

1. El indicador de software en el encabezado ELF puede solicitar explícitamente Legacy para implementar un mecanismo muy interesante: un trampolín en la pila ( 1 , 2 , 3 ).
2. Puede ser heredado por procesos hijos del padre.
3. ¡Puede ser instalado por el kernel independientemente para todos los procesos! Primero, si la arquitectura no admite memoria no ejecutable. En segundo lugar, por si acaso, para soportar otras muletas antiguas . Este código está en el kernel 2.6.32 (ARM), que tuvo una vida útil muy larga. Este fue solo nuestro caso.

Espacio para encontrar gadgets en una imagen ELF

Las bibliotecas de funciones y los ejecutables del programa están en formato ELF. El compilador gcc traduce las construcciones de lenguaje en código máquina y lo coloca en una sección, y los datos que este código opera en otras secciones. Hay muchas secciones y el enlazador ld las agrupa en segmentos. Por lo tanto, ELF contiene una imagen de programa que tiene dos representaciones: una tabla de secciones y una tabla de segmentos.

 $ readelf -l /bin/ls Elf file type is EXEC (Executable file) Entry point 0x804bee9 There are 9 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 RE 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x1e40c 0x1e40c RE 0x1000 LOAD 0x01ef00 0x08067f00 0x08067f00 0x00444 0x01078 RW 0x1000 DYNAMIC 0x01ef0c 0x08067f0c 0x08067f0c 0x000f0 0x000f0 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x018b74 0x08060b74 0x08060b74 0x00814 0x00814 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 GNU_RELRO 0x01ef00 0x08067f00 0x08067f00 0x00100 0x00100 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 03 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .init_array .fini_array .jcr .dynamic .got 

Aquí puede ver la asignación de secciones a segmentos en una imagen ELF.

Las utilidades utilizan la tabla de secciones para analizar programas y bibliotecas, pero los cargadores no la utilizan para proyectar archivos ELF en la memoria de proceso. La tabla de sección describe la estructura ELF con más detalle que la tabla de segmentos. Varias secciones pueden estar dentro de un segmento.

Los cargadores ELF crean una imagen ELF en memoria basada en el contenido de la tabla de segmentos . La tabla de particiones ya no se usa para cargar ELF en la memoria.

Un segmento ELF tiene banderas que determinan qué permisos tendrá el segmento en la memoria. Tradicionalmente, la mayoría del software para GNU / Linux se organizó de tal manera que se PT_LOAD dos PT_LOAD (cargables en memoria) en la tabla de segmentos, como en la lista anterior:

1. Segmento con banderas RE

   
   

   1.1. Código ejecutable ELF: secciones .init , .text , .fini

   
   

   1.2. Datos inmutables en ELF: .symtab , .rodata

   
   

2. Segmento de banderas RW

   
   

   2.1. Datos variables en ELF: secciones .plt , .got , .data , .bss

   
   

Si presta atención a la composición del primer segmento y sus banderas de acceso, queda claro que tal diseño expande el espacio para buscar dispositivos para técnicas de reutilización de código. En ELF grandes, como libcrypto, las tablas de servicio y otros datos inmutables pueden ocupar hasta el 40% del segmento ejecutable . La presencia de algo similar a piezas de código en estos datos se confirma por los intentos de desmontar dichos archivos binarios con una gran cantidad de datos en el segmento ejecutable sin tablas de sección y símbolos. Cada secuencia de bytes en este único segmento ejecutable puede considerarse útil para el fragmento de ataque del código de máquina y el trampolín, ya sea esta secuencia de bytes con al menos una parte de la línea del mensaje de depuración del programa, parte del nombre de la función en la tabla de símbolos o el número constante del algoritmo criptográfico ...

Solución

• El problema descrito anteriormente se conoce desde hace mucho tiempo .
• Corregido el 12 de enero de 2018 : se agrega la clave `ld -z separate-code: encabezado de segmento" Crear código separado "PT_LOAD" en el objeto. Esto especifica un segmento de memoria que debe contener solo instrucciones y debe estar en páginas totalmente separadas de cualquier otro dato. No cree un segmento de código separado "PT_LOAD" si se usa el código noseparate "). La característica fue lanzada en la versión 2.30 .
• Además, esta característica se incluyó de manera predeterminada en la próxima versión 2.31 .
• Presente en paquetes binutils nuevos, por ejemplo, en los repositorios Ubuntu 18.10. Muchos paquetes ya se han ensamblado con esta nueva característica, que el investigador de ElfMaster encontró y documentó

Como resultado de los cambios en el algoritmo de diseño, se obtiene una nueva imagen ELF:

 $ readelf -l ls Elf file type is DYN (Shared object file) Entry point 0x41aa There are 11 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00000034 0x00000034 0x00160 0x00160 R 0x4 INTERP 0x000194 0x00000194 0x00000194 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x00000000 0x00000000 0x01e6c 0x01e6c R 0x1000 LOAD 0x002000 0x00002000 0x00002000 0x14bd8 0x14bd8 RE 0x1000 LOAD 0x017000 0x00017000 0x00017000 0x0bf80 0x0bf80 R 0x1000 LOAD 0x0237f8 0x000247f8 0x000247f8 0x0096c 0x01afc RW 0x1000 DYNAMIC 0x023cec 0x00024cec 0x00024cec 0x00100 0x00100 RW 0x4 NOTE 0x0001a8 0x000001a8 0x000001a8 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x01c3f8 0x0001c3f8 0x0001c3f8 0x0092c 0x0092c R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 GNU_RELRO 0x0237f8 0x000247f8 0x000247f8 0x00808 0x00808 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt 03 .init .plt .plt.got .text .fini 04 .rodata .eh_frame_hdr .eh_frame 05 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 06 .dynamic 07 .note.ABI-tag .note.gnu.build-id 08 .eh_frame_hdr 09 10 .init_array .fini_array .data.rel.ro .dynamic .got 

El límite entre el código y los datos ahora es más preciso. El único segmento ejecutable realmente contiene solo secciones de código: .init, .plt, .plt.got, .text, .fini.

 $ ld --verbose GNU ld (GNU Binutils for Ubuntu) 2.26.1 * * * using internal linker script: ================================================== /* Script for -z combreloc: combine and sort reloc sections */ /* Copyright (C) 2014-2015 Free Software Foundation, Inc. * * * 

 $ diff elf_x86_64.x elf_x86_64.xe 1c1 < /* Default linker script, for normal executables */ --- > /* Script for -z separate-code: generate normal executables with separate code segment */ 46a47 > . = ALIGN(CONSTANT (MAXPAGESIZE)); 70a72,75 > . = ALIGN(CONSTANT (MAXPAGESIZE)); > /* Adjust the address for the rodata segment. We want to adjust up to > the same address within the page on the next page up. */ > . = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1))); 

Conclusión

Como antes , recomendamos que los desarrolladores no se olviden de utilizar los indicadores de seguridad integrados en el compilador y el vinculador al desarrollar software. Un cambio tan pequeño puede complicar en gran medida la vida del atacante y hacer que la suya sea mucho más tranquila.