(2023-2024-1)20232830《Linux内核原理分析与设计》第十二周作业
目录
1. SET-UID程序漏洞实验
Set-UID 是 Unix 系统中的一个重要的安全机制。当一个 Set-UID 程序运行的时候,它被假设为具有拥有者的权限。例如,如果程序的拥有者是root,那么任何人运行这个程序时都会获得程序拥有者的权限。Set-UID 允许我们做许多很有趣的事情,但不幸的是,它也是很多坏事情的罪魁祸首。
实验目标:
- 欣赏好的方面,理解为什么 Set-UID 是需要的,以及它是如何被执行的。
- 注意坏的方面,理解它潜在的安全性问题。
2. 实验内容
2.1 没有 Set-UID 机制的情况
passwd,chsh,su,和 sudo 命令都具有 Set-UID 机制,如果它们没有这些机制的话,会发生什么。通过以下命令来进行测试:
打开终端,执行以下命令,使得test.c文件中新增“exec”函数;
cp /usr/bin/passwd /tmp/passwd
ls -la /usr/bin/passwd
ls -la /tmp/passwd
# shiyanlou 用户密码可以通过点击右侧工具栏环境信息看到
/tmp/passwd
/usr/bin/passwd
从上面的截图可以看出:将 passwd 拷贝到 /tmp/ 下,权限发生了变化(在原目录下 suid 位 被设置),复件没有了修改密码的权限。
对于 chsh,su,和 sudo 命令,把这些程序拷贝到用户目录下,同样不再具有 root 权限。
2.2 运行 Set-UID 程序
以 root 方式登录,拷贝 /usr/bin/zsh 到 /tmp, 同时设置拷贝到 tmp 目录下的 zsh 为 set-uid root 权限,然后以普通用户登录,运行 /tmp/zsh。观察是否获得root 权限。
通过上述运行结果,可知普通用户运行tmp目录下的zsh获得了root权限;
接下来,拷贝 /bin/bash 到 /tmp 目录,同时设置 /tmp 目录下的 bash 为 Set-UID root 权限,然后以普通用户登录,运行 /tmp/bash。观察是否获得root 权限。
通过上述运行结果,可知运行tmp目录下的bash无法获得root权限。
可见,同样的操作,运行复制的 zsh 可以获得 root 权限,而 bash 不能。
2.3 Bash 内在保护机制
从上面步骤可以看出,/bin/bash 有某种内在的保护机制可以阻止 Set-UID 机制的滥用。为了能够体验这种内在的保护机制出现之前的情形,使用另外一种shell程序——/bin/zsh。在一些 linux 的发行版中(比如 Fedora 和 Ubuntu),/bin/sh 实际上是 /bin/bash 的符号链接。为了使用 zsh,需要把 /bin/sh 链接到 /bin/zsh。
通过以下指令能将默认的shell指向zsh:
sudo su
cd /bin
rm sh
ln -s zsh sh
2.4 PATH 环境变量的设置
system(const char * cmd) 系统调用函数被内嵌到一个程序中执行一个命令,system() 调用 /bin/sh 来执行 shell 程序,然后 shell 程序去执行 cmd 命令。但是在一个 Set-UID 程序中 system() 函数调用 shell 是非常危险的,这是因为 shell 程序的行为可以被环境变量影响,比如 PATH;而这些环境变量可以在用户的控制当中。通过控制这些变量,用心险恶的用户就可以控制 Set-UID 程序的行为。
下面的 Set-UID 程序被用来执行 /bin/ls 命令;然后程序员可以为 ls 命令使用相对路径,而不是绝对路径。在 /tmp 目录下新建 test.c 文件,输入如下内容:
int main()
{
system("ls");
return 0;
}
把 /bin/sh 拷贝到 /tmp 目录下面重命名为 ls(先要确保 /bin/ 目录下的 sh 符号链接到 zsh,而不是 bash),将环境变量 PATH 设置为当前目录 /tmp,运行编译的程序 test。即可获得 root 权限:
有运行结果可知,普通用户运行test程序,获得root权限。
接下来,先恢复环境变量 PATH ,然后修改 /bin/sh 使得其返回到 /bin/bash,重复上面的攻击,观察是否获得root权限:
修改 sh 连接回 bash,运行 test 程序不能使普通用户获得 root 权限。
2.5 system() 和 execve() 的不同
首先确保 /bin/sh 指向zsh,使用以下命令:
sudo su
cd /bin
rm sh
ln -s zsh sh
再使用以下命令恢复PATH:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
相关背景:Bob 在一家审计代理处工作,他正在调查一家公司是否存在诈骗行为。为了这个目的,他需要阅读这家公司在 Unix 系统中的所有文件。为了保护系统的可靠性,他不能修改任何一个文件。为了达到这个目的,Vince——系统的超级用户为他写了一个 SET-ROOT-UID 程序,并且给了 Bob 可以执行它的权限。这个程序需要 Bob 在命令行中打出一个文件名,然后运行 /bin/cat 命令显示这个文件。既然这个程序是以 root 权限运行的,它就可以显示 Bob 想看的任何一个文件。然而,既然这个程序没有写操作,Vince 很确信 Bob 不能用这个程序修改任何文件。
首先在 /tmp 目录下新建 SRU.c 文件,内容如下:
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
char *v[3];
if(argc < 2)
{
printf("Please type a file name.\n");
return 1;
}
v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = 0;
//Set q = 0 for Question a, and q = 1 for Question b
int q = 0;
if (q == 0)
{
char *command = malloc(strlen(v[0]) + strlen(v[1]) + 2);
sprintf(command, "%s %s", v[0], v[1]);
system(command);
}
else execve(v[0], v, 0);
return 0 ;
}
程序中有 q=0,程序会使用 system() 调用命令行,这个命令不安全,Bob 可能会出于好奇或者个人利益驱使阅读或者修改只有 root 用户才可以运行的一些文件。
如以下图示,file 文件只有 root 用户有读写权限,但普通用户通过运行该程序,阅读并重命名了 file 文件:
提出问题,如果令 q=1,刚才的攻击还会有效吗?
修改为 q=1 后,不会有效。前面步骤之所以有效,是因为 system() 函数调用 /bin/sh,链接至 zsh,具有 root 权限执行了 cat file 文件后,接着执行 mv file file_new 命令。
而当令 q=1, execve() 函数会把 file; mv file file_new 看成是一个文件名,系统会提示不存在这个文件:
普通用户不能通过SRU2程序将file文件重命名。
2.6 LD_PRELOAD 环境变量
为了保证 Set-UID 程序在 LD_PRELOAD 环境的操纵下是安全的,动态链接器会忽略环境变量,但是在某些条件下是例外的,接下来的实验能够弄清楚这些条件是什么。
首先,建立一个动态链接库,在/tmp目录下,创建一个mylib.c,代码内容如下:
#include <stdio.h>
void sleep (int s)
{
printf("I am not sleeping!\n");
}
通过以下命令进行编译:
gcc -fPIC -g -c mylib.c
gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0.1 mylib.o -lc
接下来创建myprog.c,内容如下:
int main()
{
sleep(1);
return 0;
}
随后,把myprog 编译成一个普通用户下的程序在普通用户下运行,可见,它会使用 LD_PRELOAD 环境变量,重载 sleep 函数:
继续把myprog 编译成一个 Set-UID root 的程序在普通用户下运行,在这种情况下,忽略 LD_PRELOAD 环境变量,不重载 sleep 函数,使用系统自带的 sleep 函数:
尝试另一种情况,在一个普通用户下把 myprog 编译成一个 Set-UID 普通用户的程序在另一个普通用户下运行,在尝试前需要使用rm myprog
命令把之前编译生成的 myprog 文件删掉:
如图,在上述情况下,并不会重载sleep函数。
总结,由以上四种情况可见:只有用户自己创建的程序自己去运行,才会使用 LD_PRELOAD 环境变量,重载 sleep 函数,否则的话忽略 LD_PRELOAD 环境变量,不会重载 sleep 函数。
2.7 消除和清理特权
为了更加安全,Set-UID 程序通常会调用 setuid() 系统调用函数永久的清除它们的 root 权限。然而有些时候,这样做是远远不够的。
首先,在 root 用户下,并在 /tmp 目录新建一个空文件 zzz。而后将下面代码命名为 test2.c,放在 /tmp 目录下,编译这个程序,并给这个程序设置 root 权限。在一个普通的用户下,运行这个程序。
代码:
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
int main(){
int fd;
fd = open("/tmp/zzz",O_RDWR|O_APPEND);
sleep(1);
setuid(getuid());
pid_t pid ;
if( ( pid = fork() ) < 0 )
perror("fork error");
else if( pid == 0 ){
// child process
write( fd , "shiyanlou!" , 10 );
}
int status=waitpid(pid,0,0);
close(fd);
return 0;
}
运行结果:
如图所示文件被修改了,原因在于设置 uid 前,zzz 文件就已经被打开了。只要将语句 setuid(getuid()) 移至调用 open 函数之前,就能避免这个问题。
3. 总结
Set-UID是Unix系统中的一个重要安全机制,允许程序在执行时以拥有者的权限运行。实验中观察到以下情况:
- 修改文件权限:
将passwd程序拷贝到/tmp/目录下后,原始目录中的suid位被设置,导致复制的文件失去了修改密码的权限。 - 对特定命令的影响:
将chsh、su和sudo等命令拷贝到用户目录下后,这些复制的程序不再具有root权限。 - /bin/bash的保护机制:
实验中观察到/bin/bash具有某种内在的保护机制,可以阻止Set-UID机制的滥用。这种保护机制可能包括限制Bash中的特权操作,以减少潜在的安全风险。
综上所述,实验结果表明Set-UID机制对于程序的权限管理起到了重要作用,但同时也存在潜在的安全风险。了解这些风险有助于采取适当的措施来保护系统免受潜在的攻击。同时,发现/bin/bash具有一定的保护机制,可以限制Set-UID机制的滥用,增强系统的安全性。