SEED实验室Return-to-libc攻击获Shell但未取得Root权限问题咨询

嘿，我在SEED实验的这个环节踩过好几次坑，你已经搞定了栈劫持的核心部分，能调出shell说明你的badfile构造和地址计算基本没问题，没拿到root权限大概率是几个容易忽略的环境或配置细节，我给你梳理下最可能的原因和解决办法：

1. 先确认漏洞程序的SUID权限是否真的生效 #

虽然你说按要求编译了，但还是要再核对一遍：

• 用命令查看权限：ls -l <你的漏洞程序名>
• 正常的输出应该是类似 -rwsr-xr-x 1 root root ...，这里的s必须在用户权限段（第一个rwx的位置），而且文件属主得是root。
• 如果不对，切换到root用户执行：

  chown root:root <你的漏洞程序名>
  chmod u+s <你的漏洞程序名>
  

2. 改用setuid(0)+execve替代system("/bin/sh") #

Ubuntu 12.04的libc对SUID程序的环境变量有严格限制，直接调用system("/bin/sh")时，shell会自动降权到你的普通用户权限。换成execve的组合就能绕开这个限制：

• 先找到setuid和execve在libc中的地址，还有/bin/sh字符串的内存地址（或者把/bin/sh写入栈中，再让execve指向这个栈地址）
• 构造Return-to-libc链：setuid(0) → execve("/bin/sh", NULL, NULL)，这样调用后直接拿到root shell

3. 检查ASLR是否完全关闭 #

32位Ubuntu 12.04默认可能开启了部分ASLR，这会导致你调试时的地址和实际运行时不一致，哪怕你调试时验证过栈内容，实际执行时可能因为地址偏移导致权限切换失败：

• 关闭ASLR：echo 0 > /proc/sys/kernel/randomize_va_space
• 关闭后重新运行漏洞程序，再测试你的badfile

4. 调试时确认权限上下文 #

用gdb跟踪执行过程，在调用setuid或execve后，查看寄存器里的EUID（有效用户ID）是否为0：

• 在gdb中可以用info registers查看eax（setuid的返回值，0表示成功），或者执行call geteuid()来确认当前有效权限

按照上面的步骤来，基本就能拿到root shell了，我之前就是因为一开始执着用system函数，卡了半天，换execve就搞定了。

内容的提问来源于stack exchange，提问作者alond22