set-uid和ELF二进制文件的INTERP部分中的相对路径的组合非常危险。
我不太确定应该如何以及在何处报告此问题，但是在我看来，这就像一个有关Linux/glibc中动态链接如何工作的一般安全性问题，所以让我解释一下这是什么:
考虑构建动态链接的二进制文件，并在ELF INTERP部分中指定相对路径(使用--dynamic-linker gcc选项)，以便您可以通过动态链接的商业应用程序重新分发自定义glibc版本(不允许您进行静态链接)反对LGPL glibc，但仍需要使您的二进制文件在具有不同glibc版本的不同linux发行版上运行)。
如果将二进制文件插入根目录，并在二进制文件上放置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标志时(即通过使用默认的动态链接器-/lib32/ld-linux.so.2或/lib64/ld-linux-x86- 64.so.2)？
那么，您认为在glibc或内核中应该在哪里修复或报告该问题呢？
最佳答案
是的，在不安全的位置使用setuid二进制文件指定解释器是不安全的(您提到了相对路径，但可写世界的固定路径也存在相同的问题)。但这是ELF设计的逻辑结论，要为setuid二进制文件的INTERP处理添加特殊情况并不是要走的路。这是的一个例子:“医生，我这样做时会很痛。 —不要这样做。” 是的，此组合不安全，请不要使用它!无论如何，使用ELF解释器进行干预是相当先进的，因此除非您了解自己在做什么，否则您不应该这样做，在这种情况下，您可以从逻辑上得出安全或不应该做什么的结论。
ELF/POSIX/Unix/无论使用什么高级功能，因为它们功能强大，因此可以为您提供一站式拍摄的强大方法。如果您想摆脱所有可能的不良情况，则系统的灵活性将大大降低，并且难以编写程序，同时仍然存在一些漏洞。
关于linux - set-uid和ELF中INTERP(动态链接器)的相对路径的安全问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9019083/