作为一项学习练习，我试图在以下代码段中找到一个弱点，以获取作为可执行文件所有者的访问权限。
setresuid(geteuid(), geteuid(), geteuid());
system("/usr/bin/id");
FWIW，我看不到任何。我知道setresuid会将uid设置为文件的所有者，但我无法将所有者更改为除我自己以外的任何人。我想通过改变PATH来尝试重定向id命令，但由于它使用绝对路径，因此该技巧不起作用。 提示？
答案 0 :(得分：1)
有可能利用涉及setresuid()未经检查的使用的模糊（现在已修补）问题：
在Linux 2.6及更高版本中，如果进程使用setresuid()运行，则 RLIMIT_NPROC可能会失败（即，进程数限制为由ulimit -n设置，这样如果setresuid()成功，目标UID将有太多进程。
但是，在Linux 3.1及更高版本中，失败的setresuid()会在进程上设置一个标志，以便任何后续的execve()调用都会失败。如果system()失败，这将阻止setresuid()在任何现代Linux上运行。
除非有一些更大的上下文被省略，否则可以设置环境变量（例如LD_PRELOAD），这会导致代码被注入/usr/bin/id。对于setuid可执行文件，这些变量将被忽略，但对于由 setuid可执行文件启动的可执行文件不会被忽略，如此处所示。
如果您使用的是易受攻击的系统（Linux 2.6到3.0），您可以通过设置环境变量并导致setresuid()失败来利用此漏洞，以便/usr/bin/id运行用户 - 指定的代码为root。
答案 1 :(得分：1)
system()函数通过将命令作为参数传递给/bin/sh -c来执行。我认为/usr/bin/id计划并不是特别相关; shell的行为是关键。特别要注意的是，当真实和有效的UID不同时，shell的启动行为是不同的：
如果shell启动时有效用户（组）id不等于真实用户（组）id [...]没有读取启动文件，shell函数不会从环境继承，SHELLOPTS，BASHOPTS ，CDPATH和GLOBIGNORE变量（如果它们出现在环境中）将被忽略，并且有效用户ID将设置为真实用户ID。
- BASH 4.1手册
如果包含您提供的代码的程序安装了suid，则代码通过设置真实，有效和保存的UID全部等于有效UID（将是UID）来防止应用该段落中给出的条件可执行文件的所有者）。
漏洞利用通常围绕不安全数据的不安全使用，环境变量经常成为违规者。 ENV环境变量特别命名一个文件，在某些情况下shell将在启动时执行。当真实有效的UID不同时，bash将不会运行它，如上文摘录中所述，但在POSIX兼容模式下以交互式调用<{1}}时将会这样做
这对于非交互式调用没有帮助，这里适用，所以现在我必须去推测。我怀疑，但目前无法记录，其他一些过去 - 甚至现在 - 版本的shell 执行读取并执行{{ 1}}以非交互方式调用时。这将提供一个向量，用于执行任意命令作为setuid程序的所有者。
在对该推测的弱支持下，我将您的注意力引向sh变量，该变量类似于ENV，但在调用BASH_ENV 非以ENV为交互式。我假设一旦这两个变量更加平行，适用于交互式和非交互式模式，但bash的非交互式使用和bash的交互式使用在不同时间被删除。出于不同的原因。很可能删除了ENV的非交互式使用，以准确插入您正在寻找的洞。