实验2：SET-UID程序漏洞实验

SET-UID程序漏洞实验

1、实验描述

Set-UID 是Unix系统中的一个重要的安全机制。当一个Set-UID程序运行的时候，它被假设为具备拥有者的权限。例如，若是程序的拥有者是root，那么任何人运行这个程序时都会得到程序拥有者的权限。Set-UID容许咱们作许多颇有趣的事情，可是不幸的是，它也是不少坏事情的罪魁祸首。

所以本次实验的目标有两点：

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

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

2、实验内容

这是一个探索性的实验，你的任务是在Linux环境中和Set-UID机制”玩游戏“，你须要在Linux中完成接下来的实验任务：

2.1 猜想为何“passwd”，“chsh”，“su”，和“sudo”命令须要Set-UID机制，若是它们没有这些机制的话，会发生什么，若是你不熟悉这些程序，你能够通话阅读使用手册来熟悉它们，若是你拷贝这些命令到本身的目录下，这些程序就不会是Set-UID程序，运行这些拷贝的程序，观察将会发生什么。

从上面的截图能够看出：将passwd拷贝到/tmp/下，权限发生了变化（在原目录下suid位被设置），复件没有了修改密码的权限。

对于“chsh”，“su”，和“sudo”命令，把这些程序拷贝到用户目录下，一样再也不具备root权限。

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

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

如图所示，得到了权限

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

可见，一样的操做，运行复制的zsh能够得到root权限，而bash不能。

2.3 从上面步骤能够看出，/bin/bash有某种内在的保护机制能够阻止Set-UID机制的滥用。为了可以体验这种内在的保护机制出现以前的情形，咱们打算使用另一种shell程序——/bin/zsh。在一些linux的发行版中（好比Redora和Ubuntu），/bin/sh其实是/bin/bash的符号连接。为了使用zsh，咱们须要把/bin/sh连接到/bin/zsh。

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

$sudo su Password: #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命令使用相对路径，而不是绝对路径。

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

2.4.1 你可以设置这个Set-UID程序运行你本身的代码而不是/bin/ls吗？若是你能的话，你的代码具备root权限吗？描述并解释你的观察。

能够具备root权限，把/bin/sh拷贝到/tmp目录下面重命名为ls（先要确保/bin/目录下的sh 符号连接到zsh，而不是bash），将环境变量PATH设置为当前目录/tmp，运行编译的程序test。就能够得到root权限：

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

可见修改sh链接回bash，运行test程序不能使普通用户得到root权限。

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

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

这个命令不安全，Bob可能会出于好奇或者我的利益驱使阅读或者修改只有root用户才能够运行的一些文件。好比截图中：file文件只有root用户有读写权限，但普通用户经过运行该程序，阅读并重命名了file文件：

第二次作：

2.5.2 若是令q=1；刚才的攻击还会有效吗？请描述并解释你的观察。

修改成q=1后，不会有效。前面步骤之因此有效，是由于system()函数调用/bin/sh，连接至zsh，具备root权限执行了cat file文件后，接着执行mv file file_new命令。

而当令q=1, execve()函数会把file; mv file file_new 当作是一个文件名，系统会提示不存在这个文件：

如图所示文件被修改了，缘由在于设置uid前，zzz文件就已经被打开了。只要将语句setuid(getuid())移至调用open函数以前，就能避免这个问题。

 

2.6 LD_PRELOAD环境变量

 

为了保证Set-UID程序在LD_PRELOAD环境的操纵下是安全的，动态连接器会忽略环境变量，可是在某些条件下是例外的，在下面的任务中，咱们猜想这些特殊的条件究竟是什么。

 

一、让咱们创建一个动态连接库。把下面的程序命名为mylib.c，放在/tmp目录下。在函数库libc中重载了sleep函数：

 

#include <stdio.h>

 

void sleep (int s)

 

{

 

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

 

}

 

二、咱们用下面的命令编译上面的程序（注意区别l和1）：

 

gcc -fPIC -g -c mylib.c

 

gcc -shared -Wl,-soname,libmylib.so.1 \

 

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

 

三、把下面的程序命名为myprog.c，放在/tmp目录下：

 

int main()

 

{

 

   sleep(1);

 

   return 0;

 

}

请在下面的条件下运行这些程序，并观察结果。基于这些观察告诉咱们连接器何时会忽略LD_PRELOAD环境变量，解释缘由。

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

可见，它会使用LD_PRELOAD环境变量，重载sleep函数

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

在这种状况下，忽略LD_PRELOAD环境变量，不重载sleep函数，使用系统自带的sleep函数：

 

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

在这种状况下，使用LD_PRELOAD环境变量，使用重载的sleep函数：

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

在这种状况下，不会重载sleep函数：

出现了权限不够的问题有待解决。

由以上四种状况可见：只有用户本身建立的程序本身去运行，才会使用LD_PRELOAD环境变量，重载sleep函数，不然的话忽略LD_PRELOAD环境变量，不会重载sleep函数。

2.7 消除和清理特权

为了更加安全，Set-UID程序一般会调用setuid()系统调用函数永久的清除它们的root权限。然而有些时候，这样作是远远不够的。在root用户下，在/tmp目录新建一个空文件zzz。在root用户下将下面代码命名为test.c，放在/tmp目录下，编译这个程序，给这个程序设置root权限。在一个普通的用户下，运行这个程序。描述你所观察到的状况，/tmp/zzz这个文件会被修改吗？解释你的观察。

代码：

 

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

void main()

{

  int fd;

  //Assume that /tmp/zzz is an important system file,

  //and it is owned by root with permission 0644

  fd = open("/tmp/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, "shiyanlou!", 10);

  close (fd);

  }

}

 

如图所示文件被修改了，缘由在于设置uid前，zzz文件就已经被打开了。只要将语句setuid(getuid())移至调用open函数以前，就能避免这个问题。

 

 3、实验感想

  在自学或者听老师讲课时，只是明白了这一部分知识的理论状况。作实验时才能更清楚的理解到这些知识的应用层面。

 不少在学习时不是很明白的知识，概念，或者某个语句的应用，在实验中能获得充分的应用。

此次实验室学习了Set-UID的应用，利用他赋予用户root权限，其中仍然有一些语句不是很明白，还须要多加学习。

1.将含有set-uid机制的文件移入本身文件夹内，将不能运行其正常功能。但若在root权限下移入，将能够获得root权限，运行这个文件；

2.bash有一种保护机制，使得其在root下移入别的文件夹也不能得到root权限；

3..chmod u+s zsh  设置zsh为set-uid root权限；

4./bin/目录下的sh 符号连接到zsh，将环境变量PATH设置为当前目录/tmp，运行编译的程序test，就能够得到root权限，若修改sh链接回bash，运行test程序不能使普通用户得到root权限；

四、只有用户本身建立的程序本身去运行，才会使用LD_PRELOAD环境变量，重载sleep函数，不然的话忽略LD_PRELOAD环境变量，不会重载sleep函数；

五、将语句setuid(getuid())移至调用open函数以前，能在一个普通的用户下，防止tmp/zzz这个文件会被修改。