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

Question

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:%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.

所以我想知道在设置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 /的任何高级功能都可以为您提供强大的射击方式,因为它们功能强大.如果你想摆脱所有可能的不良情况,那么你的系统就会变得不那么灵活,而且难以编程,同时还有一些漏洞.