代码漏洞

Question

作为一项学习练习，我试图在下面的代码片段中找到一个弱点，以便以可执行文件的所有者身份获得访问权限。

setresuid(geteuid(), geteuid(), geteuid());
system("/usr/bin/id");

FWIW，我什么都看不到。 我知道setresuid会将uid设置为文件的所有者，但是我不能将所有者更改为除我之外的任何人。 我曾考虑过尝试通过更改PATH来重定向id命令，但是由于它使用了绝对路径，因此该技巧不起作用。 提示？

Answer 1

有可能利用一个晦涩（现已修补）的问题，该问题涉及对setresuid()的未经检查的使用：

1. 在Linux 2.6和更高版本中，如果进程使用RLIMIT_NPROC （即，对由ulimit -n设置的进程数的限制）运行，则setresuid()可能会失败 ，从而使得如果setresuid() ，目标UID会有太多进程setresuid()成功。

   但是，在Linux 3.1和更高版本中，如果setresuid()失败， setresuid()在进程上设置一个标志，以使任何后续execve()调用都将失败。 如果setresuid()失败，这将阻止system()在任何现代Linux上运行。

2. 除非有一些较大的上下文被忽略，否则可能会设置环境变量（例如LD_PRELOAD ），从而导致代码被注入到/usr/bin/id 。 这些变量对于setuid可执行文件将被忽略，但对于setuid可执行文件启动的可执行文件将不会被忽略，就像在这里发生的那样。

如果您使用的是易受攻击的系统（Linux 2.6至3.0），则可以通过设置环境变量并导致setresuid()失败来利用此漏洞，以便/usr/bin/id以root用户/usr/bin/id运行用户指定的代码。

Answer 2

system()函数通过将参数传递给/bin/sh -c来执行作为其参数给出的命令。 我认为/usr/bin/id程序不是特别重要； 关键是外壳的行为。 特别要注意的是，当实际UID和有效UID不同时，shell的启动行为也不同：

如果shell以有效用户（组）ID不等于真实用户（组）ID的身份启动，则不会读取启动文件，也不会从环境，SHELLOPTS，BASHOPTS，CDPATH，和GLOBIGNORE变量（如果它们出现在环境中）将被忽略，并且有效用户ID设置为实际用户ID。

-BASH 4.1手册

如果包含您提供的代码的程序已安装suid，则该代码会通过设置所有等于有效UID（将是所有者的UID）的实际，有效和保存的UID来防止应用该段中给出的条件可执行文件）。

攻击通常围绕不安全地使用不可靠的数据，而环境变量常常是违法者。 ENV环境变量特别命名一个文件，该文件在某些​​情况下将在启动时执行。 如上面摘录中所述，当实际UID与有效UID不同时， bash不会运行它，但在POSIX兼容模式下以交互方式或以sh调用时， bash不会运行它。

如此处适用的那样，这对于非交互式调用没有帮助，所以现在我不得不进行推测。 我怀疑 ，但目前无法记录，以非交互方式调用时，shell的其他某些版本（甚至可能是当前版本） 确实会从ENV命名的文件中读取并执行命令。 这将提供一个向量来作为setuid程序的所有者执行任意命令。

在这种推测的弱支持下，我将您的注意力转向BASH_ENV变量，该变量类似于ENV ，但在非交互调用bash时（如bash ）使用该变量。 我假设一旦这两个变量更加并行，就适用于交互式和非交互式模式，但是在不同时间删除了ENV的非交互式使用和BASH_ENV的交互式使用。 由于不同的原因。 很可能删除了ENV的非交互式使用，以准确塞住您要查找的孔。