linux – 使用set-uid的安全性问题以及ELF中INTERP(动态链接器)

我不太清楚应该如何以及在哪里报告此问题,但在我看来,这似乎是关于linux / glibc中的动态链接如何工作的一般安全问题,所以让我解释一下它是什么：

考虑构建动态链接的二进制文件并在ELF INTERP部分中指定相对路径(使用–dynamic-linker gcc选项),这样您就可以使用动态链接的商业应用程序重新分发自定义glibc版本(不允许您静态链接)反对LGPL glibc,但仍然需要让你的二进制工作跨不同的linux发行版具有不同的glibc版本).

如果你将二进制文件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:%dn",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.

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

那么您认为,在glibc或内核中应该在哪里修复或报告？