SET-UID程序漏洞实验

爱被打了一巴掌 2021-07-28 22:44 359阅读 0赞

**第一部分** **实验描述**

Set-UID 是Unix系统中的一个重要的安全机制。当一个Set-UID程序运行的时候，它被假设为具有拥有者的权限。例如，如果程序的拥有者是root，那么任何人运行这个程序时都会获得程序拥有者的权限。Set-UID允许我们做许多很有趣的事情，但是不幸的是，它也是很多坏事情的罪魁祸首。因此本次实验的目标有两点：

一．欣赏好的方面，理解为什么Set-UID是需要的，以及它是如何被执行的。

二．注意坏的方面，理解它潜在的安全性问题。

**第二部分** **实验内容**

这是一个探索性的实验，你的任务在Linux环境中和Set-UID机制玩游戏，写一份报告描述你的发现，你被要求在Linux中完成以下的实验。

**2.1** 猜测为什么“passwd”，“chsh”，“su”，和“sudo”命令需要Set-UID机制，如果它们没有这些机制的话，会发生什么，如果你不熟悉这些程序，你可以通话阅读使用手册来熟悉它，如果你拷贝这些命令到自己的目录下，这些程序就不会是Set-UID程序，运行这些拷贝的程序，观察将会发生什么。

**解答：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70][]

从上面的运行结果可以看出：拷贝到/home/seed下的passwd程序，没有了root权限，这样就没有了修改密码的权限。

示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 1][]  
对于“chsh”，“su”，和“sudo”命令，把这些程序拷贝到用户目录下，同样不再具有root权限。

**2.2** **在linux****环境下运行Set-UID** **程序，同时描述并且解释你的观察结果**

**2.2.1** 以root方式登录，拷贝/bin/zsh 到/tmp, 同时设置拷贝到tmp目录下的zsh为set-uid root权限，然后以普通用户登录，运行/tmp/zsh。你会得到root权限吗？请描述你的结果。

**解答：**

可以获得root权限，示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 2][]

**2.2.2** 代替拷贝/bin/zsh到tmp目录，这次拷贝/bin/bash到/tmp目录，同时设置/tmp目录下的bash为Set-UID root权限，然后以普通用户登录，运行/tmp/bash。你会得到root权限吗？请描述你的结果。

**解答：**

获得不了root权限，示意图如下，从实验中可以看出/bin/bash有某种内在的保护机制可以阻止Set-UID机制的滥用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 3][]

**2.3** 从题目2.2可以看出，/bin/bash有某种内在的保护机制可以阻止Set-UID机制的滥用。为了能够体验这种内在的保护机制出现之前的情形，我们打算使用另外一种/bin/zsh。在一些linux的发行版中（比如Redora和Ubuntu），/bin/sh实际上是/bin/bash的符号链接。为了使用zsh，我们需要把/bin/sh链接到/bin/zsh。

下面的指令将会把默认的shell指向zsh：

$ su

Password: (enter root password)

\# cd /bin

\# rm sh

\# ln -s zsh sh

**解答：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 4][]

**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命令使用相对路径，而不是绝对路径。

int main()

system("ls");

return 0;

**2.4.1** 你能够设置这个Set-UID程序运行你自己的代码而不是/bin/ls吗？如果你能的话，你的代码具有root权限吗？描述并解释你的观察。

**解答：**

可以具有root权限，我是这样做的：首先把/bin/sh拷贝到/tmp目录下面重命名为ls  将环境变量PATH设置为当前目录/tmp，运行编译的程序system。就可以获得root权限：

**（首先确保/bin/****目录下的sh** **符号链接到zsh****，如果链接到bash****，这种方式是获取不到root****权限的，原因正如上面所叙述的那样，/bin/bash****有某种内在的保护机制可以阻止Set-UID****机制的滥用）**

示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 5][]

**2.4.2** 现在，修改/bin/sh使得其返回到/bin/bash，重复上面的攻击，你仍然可以获得root权限吗？描述并解释你的观察。

**解答：**

获取不到，原因我已经在2.4.1中已经做了说明，示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 6][]

**2.5 sytem()****和execve()****的不同**

在你执行这个任务之前，确保/bin/sh指向zsh，事件背景：Bob在为一家审计代理处工作，他正在调查一家公司是否存在诈骗行为。为了这个目的，他需要阅读这家公司在Unix系统中的所有文件；另一方面，为了保护系统的可靠性，他不能修改任何一个文件。为了达到这个目的，Vince——系统的超级用户为他写了一个SET-ROOT-UID程序，并且给了Bob可以执行它的权限。这个程序需要Bob在命令行中打出一个文件名，然后运行/bin/cat命令显示这个文件。既然这个程序是以root权限运行的，它就可以显示Bob想看的任何一个文件。然而，既然这个程序没有写操作，Vince很确信Bob不能用这个程序修改任何文件。

#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 ;
    }

(a) 令q = 0。这种方式，程序会使用system()调用命令行。这个命令安全码？如果你是Bob，你能对系统的完整性妥协吗？你能重新移动一个对你没有写权限的文件吗?

**解答：**

这个命令不安全，Bob可能会出去好奇或者个人利益驱使会阅读或者修改只有root用户才可以运行的一些文件，示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 7][]  
(b) 如果令q=1；在(a)中的攻击还会有效吗？请描述并解释你的观察。

解答：

不会有效，在(a)中之所以有效，是具有root权限的system在执行了cat file文件后，还会接着执行mv file file\_new命令。

而当令q=1, execve()函数会把file; mv file file\_new 看成是一个文件名，系统会提示不存在这个文件。示意图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 8][]

**2.6 LD\_PRELOAD****环境变量**

为了保证Set-UID程序在LD\_PRELOAD环境的操纵下是安全的，动态链接器会忽略环境变量，但是在某些条件下是例外的，在下面的任务中，我们猜测这些特殊的条件到底是什么。

(a)   让我们建立一个动态链接库。把下面的程序命名为mylib.c。在函数库libc中重载了sleep函数：

\#include <stdio.h>

void sleep (int s)

printf("I am not sleeping!\\n");

(b)   我们用下面的命令编译上面的程序(-W1中1是一，-lc中l是字母l)：

% gcc -fPIC -g -c mylib.c

% gcc -shared -W1,-soname,libmylib.so.1 \\

\-o libmylib.so.1.0.1 mylib.o –lc

% export LD\_PRELOAD=./libmylib.so.1.0.1

(d)编译下面的myprog(把这个程序和libmylib.so.1.0.1放在同一个目录)

// myprog.c

int main()

sleep(1);

return 0;

请在下面的条件下运行这些程序，并观察结果。基于这些观察告诉我们链接器什么时候会忽略LD\_PRELOAD环境变量，解释原因。

**一.** **把myprog****编译成一个普通用户下的程序在普通用户下运行**

分析：它会使用LD\_PRELOAD环境变量，重载sleep函数，执行结果如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 9][]

**二．****把myprog****编译成一个Set-UID root****的程序在普通用户下运行**

分析：

在这种情况下，忽略LD\_PRELOAD环境变量，不重载sleep函数，使用系统自带的sleep函数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 10][]

**三。** **把myprog****编译成一个Set-UID root****的程序在root****下运行**

分析：在这种情况下，使用LD\_PRELOAD环境变量，使用重载的sleep函数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 11][]

**四．  ****在一个普通用户下把myprog****编译成一个Set-UID** **普通用户的程序在另一个普通用户下运行**

分析：在这种情况下，忽略LD\_PRELOAD环境变量。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 12][]  
  
**总结：只有用户自己创建的程序自己去运行，才会使用LD\_PRELOAD****环境变量，重载sleep****函数，否则的话忽略LD\_PRELOAD****环境变量，不会重载sleep****函数。**

**2.7** **消除和清理特权**

为了更加安全，Set-UID程序通常会调用setuid()系统调用函数永久的清除它们的root权限。然而有些时候，这样做是远远不够的。编译接下来的这个程序，给这个程序设置root权限。在一个普通的用户下，运行这个程序。描述你所观察到的情况，/etc/zzz这个文件会被修改吗？解释你的观察。

程序代码：

#include <stdio.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    
    void main()
    {
      int fd;
      //Assume that /etc/zzz is an important system file,
      //and it is owned by root with permission 0644
      fd = open("/etc/zzz", O_RDWR | O_APPEND);
      // Simulate the tasks conducted by the program
      sleep(1);
      // After the task, the root privileges are no longer needed,
       //it’s time to relinquish the root privileges permanently.
      setuid(getuid()); // getuid() returns the real uid
      if (fork())
      { // In the parent process
       close (fd);
       exit(0);
      }
      else
      { // in the child process
      //Now, assume that the child process is compromised, malicious
      //attackers have injected the following statements
      //into this process
       write (fd, "Malicious Data", 14);
      close (fd);
      }
    }

**解答：**

**![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 13][]**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70]: /images/20210728/36b8410d6d0943b0a201f72d6283dfea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 1]: /images/20210728/549f4043734a43bf87d518e11ee5a2a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 2]: /images/20210728/56b215ff2a104ec59cc7237b08de0b97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 3]: /images/20210728/dc502fa9b2fa4e2894abb40340e63d28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 4]: /images/20210728/fc964d5d8c344dc98c781ad0956e57b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 5]: /images/20210728/ead11d7ad0b74fe4a74915bfc7e7c2c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 6]: /images/20210728/7ef1bf687a1c4abf9a956190f5cb0ebd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 7]: /images/20210728/dbaa56c5011a4d77824e11823de6698a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 8]: /images/20210728/3ac88f9cef1b403b9e9fbae24ea369e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 9]: /images/20210728/89530f2882474b7dae1bbec7b28c3459.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 10]: /images/20210728/30915eb812fd4e018da3f222d1b1e2f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 11]: /images/20210728/f7eb73d1b3b244419309ff0fae1f8fae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 12]: /images/20210728/0af652a42d704584aaf150fc83ea884a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 13]: /images/20210728/eb4ef1971854455ab1eac61f75d2178d.png