linux - 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 二进制文件。

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

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

那么你怎么看，应该在哪里修复或报告 - 在 glibc 或内核中？

Answer 1