SET-UID程序漏洞实验
作业信息
| 这个作业属于哪个课程 | <2020-2021-1Linux内核原理与分析）> |
|---|---|
| 这个作业要求在哪里 | <2020-2021-1Linux内核原理与分析第十一周作业> |
| 这个作业的目标 | <理解linux中setuid的作用以及setuid是如何执行的> |
| 作业正文 | <本博客链接> |
实验简介
Set-UID 是 Unix 系统中的一个重要的安全机制。当一个 Set-UID 程序运行的时候，它被假设为具有拥有者的权限。
例如，如果程序的拥有者是root，那么任何人运行这个程序时都会获得程序拥有者的权限。Set-UID 允许我们做许多很有趣的事情，但不幸的是，它也是很多坏事情的罪魁祸首。
实验内容
这是一个探索性的实验，你的任务是在Linux环境中和Set-UID机制“玩游戏”，你需要在 Linux 中完成接下来的实验任务。
没有setuid机制的情况
猜测为什么“passwd”，“chsh”，“su”，和“sudo”命令需要Set-UID机制，如果它们没有这些机制的话，会发生什么。
如果你不熟悉这些程序，可以通过阅读使用手册来熟悉它们。如果你拷贝这些命令到自己的目录下，这些程序就不会是Set-UID程序。
cp /usr/bin/passwd /tmp/passwd
ls -la /usr/bin/passwd
ls -la /tmp/passwd
/tmp/passwd
/usr/bin/passwd
从上面的截图可以看出：将 passwd 拷贝到 /tmp/ 下，权限发生了变化（在原目录下 suid 位 被设置），复件没有了修改密码的权限。
对于 chsh，su，和 sudo 命令，把这些程序拷贝到用户目录下，同样不再具有 root 权限。
运行setuid程序
以 root 方式登录，拷贝 /usr/bin/zsh 到 /tmp, 同时设置拷贝到 tmp 目录下的 zsh 为 set-uid root 权限，然后以普通用户登录，运行 /tmp/zsh。由下图可知，获得了root权限
拷贝 /bin/bash 到 /tmp 目录，同时设置 /tmp 目录下的 bash 为 Set-UID root 权限，然后以普通用户登录，运行 /tmp/bash。由下图可知，没有获得root权限
可见，同样的操作，运行复制的 zsh 可以获得 root 权限，而 bash 不能。
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
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;
}
设置这个 Set-UID 程序运行自己的代码而不是 /bin/ls 获得root权限
把 /bin/sh 拷贝到 /tmp 目录下面重命名为 ls（先要确保 /bin/ 目录下的 sh 符号链接到 zsh，而不是 bash），将环境变量 PATH 设置为当前目录 /tmp，运行
编译的程序 test。就可以获得 root 权限：
先恢复环境变量 PATH ，然后修改 /bin/sh 使得其返回到 /bin/bash，重复上面的攻击：
可见修改 sh 连接回 bash，运行 test 程序不能使普通用户获得 root 权限
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.
");
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，你能对系统的完整性妥协吗？你能重新移动一个对你没有写权限的文件吗?
这个命令不安全，Bob 可能会出于好奇或者个人利益驱使阅读或者修改只有 root 用户才可以运行的一些文件。
比如截图中：file 文件只有 root 用户有读写权限，但普通用户通过运行该程序，阅读并重命名了 file 文件：
修改为 q=1 后，不会有效。前面步骤之所以有效，是因为 system() 函数调用 /bin/sh，链接至 zsh，具有 root 权限执行了 cat file 文件后，
接着执行 mv file file_new 命令。
而当令 q=1, execve() 函数会把 file; mv file file_new 看成是一个文件名，系统会提示不存在这个文件：
LD_PRELOAD 环境变量
为了保证 Set-UID 程序在 LD_PRELOAD 环境的操纵下是安全的，动态链接器会忽略环境变量，但是在某些条件下是例外的，在下面的任务中，我们猜测这些特殊的条件到底是什么。
1、让我们建立一个动态链接库。把下面的程序命名为 mylib.c，放在 /tmp 目录下。在函数库 libc 中重载了 sleep 函数：
#include <stdio.h>
void sleep (int s)
{
printf("I am not sleeping!
");
}
2、我们在终端用下面的命令编译上面的程序（注意区别字母 l 和数字 1 ）：
gcc -fPIC -g -c mylib.c
gcc -shared -Wl,-soname,libmylib.so.1
-o libmylib.so.1.0.1 mylib.o –lc
3、把下面的程序命名为 myprog.c，放在 /tmp 目录下：
int main()
{
sleep(1);
return 0;
}
把 myprog 编译成一个普通用户下的程序在普通用户下运行
可见，它会使用 LD_PRELOAD 环境变量，重载 sleep 函数：
把 myprog 编译成一个 Set-UID root 的程序在普通用户下运行
在这种情况下，忽略 LD_PRELOAD 环境变量，不重载 sleep 函数，使用系统自带的 sleep 函数：
把 myprog 编译成一个 Set-UID root 的程序在 root 下运行
在这种情况下，使用 LD_PRELOAD 环境变量，使用重载的 sleep 函数：
在一个普通用户下把 myprog 编译成一个 Set-UID 普通用户的程序在另一个普通用户下运行
在这种情况下，不会重载 sleep 函数：
由以上四种情况可见：只有用户自己创建的程序自己去运行，才会使用 LD_PRELOAD 环境变量，重载 sleep 函数，否则的话忽略 LD_PRELOAD 环境变量，不会重载 sleep 函数。
消除和清理特权
为了更加安全，Set-UID 程序通常会调用 setuid() 系统调用函数永久的清除它们的 root 权限。然而有些时候，这样做是远远不够的。在 root 用户下，
在 /tmp 目录新建一个空文件 zzz。在 root 用户下将下面代码命名为 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 函数之前，就能避免这个问题。
实验收获
在linux中每个进程有三个用户标识符：
real uid : 真实用户ID.
saved uid : 已保存用户ID
effective uid : 有效用户ID
真实用户ID(real uid)是login时的用户.而在运行过程中,
用于所有的安全检查的是有效用户ID(effective uid).
一般情况下:
real uid = saved uid = effective uid
在某些场合下,使用用setuid,setruid函数可以改变effective uid,从而使得程序运行时具有特殊的权限.常见的例子是linux系统中的passwd命令,
由于所有的用户信息包括用户密码都保存在/etc/passwd文件中,而/etc/passwd文件只有root权限可以读写,若想让每个用户都只可以修改自己的密码,就必须
让普通用户暂时获得有限的读写/etc/passwd的权限.用setuid就可以解决这个问题.
Linux setuid(uid)函数:
(1)如果由普通用户调用,将当前进程的有效ID设置为uid.
(2)如果由有效用户ID符为0的进程调用,则将真实,有效和已保存用户ID都设
置为uid.
Linux的setuid函数和Unix中的setuid函数的行为是不同的.
Unix中.setuid(uid)函数的行为:
(1)如果进程没有超级用户特权,且uid等于实际用户ID或已保存用户ID,则只
将有效的用户ID设置为uid.否则返回错误.
(2)如果进程是有超级用户特权,则将真实,有效和
已保存用户表示符都设置为uid.
这里主要的区别在于普通用户调用时的行为.产生这个问题的原因是POSIX和BSD的实现差异,而linux却同时支持这两者.BSD中使用setreuid(uid_t ruid, uid_t euid)
来设定真实用户ID(real uid)和有效用户ID(effective uid).这个函数在由有效用户ID符为0的进程调用时,不会改变已保存用户ID.函数seteuid(uid_t uid)等价
于setreuid(-1,uid),只改变有效用户ID(effective uid).