ELF 中 set-uid 和 INTERP（动态链接器）相对路径的安全问题

Question

ELF 二进制文件的 INTERP 部分中的 set-uid 和相对路径的组合非常危险。

我不太确定应该如何以及在哪里报告这个问题，但在我看来，这就像一个关于 linux/glibc 中动态链接如何工作的一般安全问题，所以让我解释一下它是什么：

考虑构建一个动态链接的二进制文件并在 ELF INTERP 部分中指定相对路径（使用 --dynamic-linker gcc 选项），以便您可以使用动态链接的商业应用程序重新分发自定义 glibc 版本（不允许您静态链接 LGPL glibc，但仍然需要让你的二进制文件在具有不同 glibc 版本的不同 Linux 发行版上工作）。

如果您将二进制文件 chown 为 root，并将 set-uid 标志放在您的二进制文件上，它实际上就变成了 rootkit。由于从不同的目录执行它，允许您替换将以 root 权限执行的动态链接器可执行文件。

为了演示这一点，请看一下以下 C 代码 (issue.c)：

#include <stdio.h> 

// 
// build with: 
//   gcc -DNAME=\"vulnarable\" -o issue -Wl,--dynamic-linker,.lib64/ld-linux-x86-64.so.2 issue.c 
//   sudo chown root issue 
//   sudo chmod u+s issue 
// now build some code to be executed with root permissions (we use the same issue.c): 
//   mkdir -p .lib64/ 
//   gcc -DNAME=\"rootkit\" -o .lib64/ld-linux-x86-64.so.2 --static issue.c 
// 

int main(int argc, char* argv[]) 
{ 
    printf("(%s) euid:%d\n", NAME, geteuid()); 
} 

如果您现在像这样执行 set-uid 二进制文件

./issue

，或者只是这样做

ldd issue

而不是得到您可能期望的结果，例如：

(vulnarable) euid:0

您会得到：

(rootkit) euid:0

现在是重点您可以用您喜欢的任何内容替换 ld-linux-x86-64.so.6 二进制文件。

通过不解析 RPATH 中的 $ORIGIN 或在设置了 set-uid 标志时忽略 LD_LIBRARY_PATH ，似乎已经解决了类似的问题。

所以我想知道每当设置 set-uid 标志时是否必须忽略 ELF 中的 INTERP（即通过使用默认动态链接器 - /lib32/ld-linux.so.2 或 /lib64/ld-linux-x86- 64.so.2)?

那么你认为这个问题应该在哪里修复或报告——在 glibc 还是内核中？

Answer 1

是的，在非安全位置使用 setuid 二进制文件指定解释器是不安全的（您提到了相对路径，但世界可写的固定路径也有同样的问题）。但这是 ELF 设计的逻辑结论，为 setuid 二进制文件的 INTERP 处理添加特殊情况并不是正确的方法。这是一个“医生，我这样做的时候很痛。 — 不要这样做。” 是的，这种组合不安全，所以不要使用它！无论如何，干预 ELF 解释器是相当高级的事情，因此除非您了解自己在做什么，否则您不应该这样做，在这种情况下，您可以从逻辑上得出什么是安全的或不应该做什么的结论。

ELF/POSIX/Unix/任何东西的高级特性都会给你搬起石头砸自己脚的强大方法，因为它们很强大。如果您想摆脱所有可能的糟糕情况，您的系统将变得不那么灵活，并且更难以编程，同时仍然存在一些漏洞。