三、Set

优质

小牛编辑

127浏览

2023-12-01

这个讲义的主要目标就是来讨论特权程序，为什么需要他们，他们如何工作，以及它们有什么安全问题。特权程序是可以给予用户额外权限的程序，这些权限超出了用户已有的权限。例如，Web 服务器是特权程序，因为他允许远程用户访问服务端的资源；Set-UID 程序也是个特权程序，因为他允许用户在程序执行期间获得 ROOT 权限。

这篇讲义中，我们会专注于 Set-UID 的机制，并且在我们的案例学习中使用它。但是，我们在这里讨论的许多安全原则也可以用在其他特权程序上。

1 Set-UID 机制如何工作

动机
- 你想让其他人能够搜索文件中的一些单词，但是不想让他们能够读取文件。如何实现它呢？
- 用户的密码储存在/etc/shadow中，普通用户不可读写。但是，passwd程序允许用户修改它们自己的密码。也就是，当用户执行passwd，它们可以突然修改/etc/shadow，并且用户只能修改/etc/shadow中的一项，但不是其他人的条目。如何实现？
Set-UID 程序
- 有效 UID 和真实 UID 的概念
- 对于非 Set-UID 程序，二者相同
- 对于 Set-UID 程序，前者是程序所有者的 UID，后者是程序用户的 UID。
有效 UID 和真实 UID
- 登录时期，真实 UID 和有效 UID，以及登录过程保存的 UID 都设为负责进程创建的用户的登录 UID。对于真实、有效和保存的组 ID 也一样。它们设为负责进程创建的用户的组 ID。
- 当进程调用exec系列函数之一，来执行文件（程序）时，进程相关的用户和组标识符会发生改变。如果执行的文件是个 Set-UID 文件，进程的有效和保存的 UID 会设为所执行文件的所有者。如果所执行文件是个 Set-GID 文件，有效 UID、保存的 UID 以及有效 GID、保存的 GID 不会改变。
- 访问控制基于有效 UID 和 GID。
为什么passwd、chsh和su程序需要为 Set-UID 程序？
Windows NT/2000 中有没有 Set-UID 程序？如果没有，相同问题在 Windows 中如何解决？
- Windows 没有 Set-UID 这个概念。不同的机制用于实现权限功能。开发者会将特权程序编写为服务，用户使用本地过程调用将命令行参数发给服务。
- 服务可以自动或手动启动。
- 每个服务都有安全描述符，制定了哪个用户允许启动、停止和配置该服务。
- 服务通常在本地系统账户下运行。
如何打开 Set-UID 位：
```
% chmod 4755 file ---> -rwsr-xr-x 
```

Set-UID 在 Minix 中如何实现？

/* This is the per-process information */ 
EXTERN struct fproc {
    uid_t fp_realuid; /* real user id */ 
    uid_t fp_effuid; /* effective user id */ 
    gid_t fp_realgid; /* real group id */ 
    gid_t fp_effgid; /* effective group id */ 
    ...
}

Set-UID 机制的恶意使用：
- 攻击者可以使用你的账户十秒。它能够植入后门，以便之后再回到你的账户吗？
```
% cp /bin/sh /tmp 
% chmod 4777 /tmp/sh
```
  由此，攻击者创建了 Set-UID Shell 程序，你是这个程序的所有者。因此，当攻击者之后再运行 Shell 时，它使用你的权限运行。
问题：
- 普通用户是否可以调试 Set-Root-UID 程序？
- 普通用户是否可以使用chown来将文件所有者修改为任何用户？

2 Set-UID 程序的漏洞

2.1 隐藏的输入：环境变量

特权程序必须对所有输入进行安全检查。输入检查实际上是访问控制的一部分，特权程序必须这么做，来确保程序的安全。很多安全问题都是输入检查的错误造成的。

如果输入在程序中显式存在，程序员可能记得执行输入检查；如果输入隐式存在，输入检查可能会忘记，因为程序员可能不知道这个输入的存在。环境变量就是这类输入。

每个 Unix 进程都在特定环境下运行。环境由环境变量表组成，每个变量都有赋值。一些程序内部使用这些环境变量，Shell 程序就是这些程序的例子。换句话说，一些环境变量的值可以 Shell 程序的行为。

由于环境变量由用户控制，如果程序依赖这些变量，用户可以间接影响这类程序的行为，通过修改一些环境变量的值。因此，理解特权程序是否依赖任何环境变量的值就十分重要。一种程序可能被环境变量影响的方式，就是在程序中显式使用环境变量的值。在 C 语言中，程序可以使用getenv来访问环境变量的值。但是，也有许多例子，程序隐式使用环境变量。这就是我们在许多 Set-UID 程序中看到的漏洞。我们会在这一节中展示几个例子。

PATH环境变量
- 在 Shell 中执行命令式，Shell 会使用PATH环境变量搜索所有命令，它包含一个目录列表。Shell 程序通过目录列表（和他们在PATH环境变量的相同顺序）来搜索。第一个匹配命令名称的程序会被执行。
- 下面会发生什么？要注意system (const char *cmd)库函数首先调用/bin/sh程序，之后让 Shell 程序执行cmd。
```
system ("mail");
```
攻击者可以将PATH修改成这个，并使当前目录下的mail被执行。
```
PATH=".:$PATH"; export PATH
```
拿超人来比喻的话，如果超人的指令是“左转”（坏人在左边而好人在右边，你可以假设他要攻击坏人）。如果攻击者准确知道左转指令什么时候以及在哪里执行，他就可以做出与上面类似的攻击。因为“左边”是个相对的方向，并不是绝对方向。如果攻击者事先在你想要左转的地方，放置一个旋转设备，并将你旋转 180 度，只要你踏上了它，“左转”就变成了转到好人那里。如果你遵循了指令，你最后就会攻击好人。
IFS环境变量
- IFS变量决定了哪些字符被解释为空白字符。它代表了内部字段分隔符。假设我们设置它来包含斜杠字符：
```
IFS="/ \t\n"; export IFS 
PATH=".:$PATH"; export PATH
```
- 现在从 Bourne Shell 中调用任何使用绝对PATH的程序（李儒system）。它现在解释为下面的东西，它会在当前用户目录下，尝试执行命令行调用bin：
```
system("/bin/mail root"); ---> system(" bin mail root");
```
- IFS 的 bug 现在已经在 Shell 中禁止了；所引用的新的 Shell 进程不会继承 IFS 变量。
- 假设在超人的故事中。超人知道使用“左转”指令的风险，所以它将其改为“转到北边”，它现在是个绝对方向。这仍然存在漏洞，因为“北”由磁场决定，不幸的是，磁场可以通过攻击者放置的磁铁来影响。
LD_LIBRARY_PATH环境变量
- Linux 中，除非编译时期通过-static显式指定，所有 Linux 程序需要在运行时期链接到动态链接库。动态链接器或加载器ld.so/ld-linux.so加载程序所需的共享库，准备要运行的程序，之后运行它。你可以使用下面的命令来观察程序需要什么共享库。
```
% ldd /bin/ls
```
- LD_LIBRARY_PATH是一个环境变量，被动态链接器或加载器（ld.so/ld-linux.so）使用。它含有一个目录列表，让链接器或者加载器在搜索共享库时寻找。可以列出多个目录，以冒号（:）分隔。对于任何可执行文件，这个列表放在现存的编译器加载路径，以及任何系统默认加载路径的前面。
- 基本上每个 Unix 程序都依赖于libc.so，并且每个 Windows 程序都一拉李雨 DLL。如果这些苦可以替换为恶意的副本，恶意代码就可以在共享库函数被调用时执行。
- 由于LD_LIBRARY_PATH可以由用户充值，攻击者可以修改这个变量，并强制库加载器在攻击者的目录中搜索库，从而加载攻击者的恶意库。
```
% setenv LD_LIBRARY_PATH .:$LD_LIBRARY_PATH
```
- 为了使 Set-UID 程序更加安全，不受LD_LIBRARY_PATH环境变量的影响，运行时的链接器或加载器（ld.so）会忽略环境变量，如果程序是个 Set-UID 程序。
- 防护应用也可以静态链接到可信库来避免这个问题。
- 在 Windows 主机上，通常在加载 DLL 的时候，在搜索系统目录之前，会搜索当前目录中的 DLL。如果你点击 Word 文档来启动 Office，会在包含该文档的目录下搜索 DLL。
LD PRELOAD环境变量
- 许多 Unix 系统允许你“预加载”共享库，通过设置环境变量LD PRELOAD。这些用户指定的库会在所有其它库之前加载。这可以用于选择性重载其他库中的函数。例如，如果你已经构建了一个库，你可以使用下列命令预加载它：
```
% export LD_PRELOAD=./libmylib.so.1.0.1
```
  如果libmylib.so.1.0.1包含函数sleep，它是个标准的libc函数，当程序执行并调用sleep时，libmylib.so.1.0.1中的函数会被调用。
这里是一个程序，重载了libc中的sleep：
```
#include <stdio.h> 
void sleep (int s) { 
    printf("I am not sleeping!\n"); 
}
```
我们可以使用下列命令编译程序（假设上面的程序名为name.c）：
```
% gcc -fPIC -g -c a.c 
% gcc -shared -o libmylib.so.1.0.1 a.o -lc
```
现在，我们运行下列程序：
```
int main() { 
    sleep(1); 
    return 0; 
}
```
如果环境变量LD PRELOAD设为libmylib.so.1.0.1，标准libc中的sleep没有使用，反之我们共享库中的sleep函数会调用，并且打印"I am not sleeping!"。
为了确保 Set-UID 程序安全，不受LD PRELOAD环境变量的控制，运行时链接器或加载器（ld.so）会忽略这个环境变量，如果程序是 Set-Root-UID 程序，除非真实 UID 也为 0。

2.2 调用其它程序

当特权程序调用其它程序时，必须注意是否调用了非预期的程序。我们知道，环境变量是个我们需要注意的地方，也有一些我们需要注意的其它地方。

如果 Set-UID 程序执行下面的事情，会发生什么？

// The contents of User_Input are provided by users. 
sprintf(command, "/bin/mail %s", User_Input); 
system(command);

User_Input可能包含 Shell 的特殊字符（例如| & < >）。要记住，system调用实际上先调用 Shell，之后让 Shell 程序执行/bin/mail。如果我们不注意，攻击者就可以执行其它程序，通过让User_Input是下面的字符串：
```
xyz@example.com ; rm -f /* ; /bin/sh
```

2.3 其它知名的漏洞模式

除了上面的输入校验漏洞，也有一些其他的知名漏洞模式。我们会在单独的章节中讨论它们。这里是这些模式的总结：

缓冲区溢出
竞态条件
格式化字符串

2.4 杂项漏洞

有许多其他漏洞，并不易于归纳进上面讨论的任何分类。一些可能被归纳为更广泛的“呼入椒盐漏洞”，但是由于他们的独特特性，我们在这里单独讨论它们。我们不能枚举所有漏洞。我们只能给出一些示例，来展示程序员在程序逻辑中的不同错误，并且展示这些错误如何变为漏洞。

lpr漏洞：它在/tmp目录下生成临时文件。文件名称应该是随机的，但是，由于伪随机数生成的错误，文件名称每一千次就会发生重复。这个程序是 Set-UID 程序。将可预测的文件名称链接到/etc/passord会导致lpr覆盖/etc/passord。
chsh漏洞：chsh让用户输入 Shell 程序的名称s，并在/etc/passwd中保存输入。chsh并不会做清晰的检查。程序假设用户的输入只有一行，不幸的是，这个假设可以为假：用户可以键入联行输入，其中第二行是类似xyz::0:0::的东西美丽如，用户可以插入一个新的超级用户账户（UID：0），不带密码。
sendmail漏洞
- sendmail：（1）入境的邮件会添加在/var/mail/wedu。（2）如果/var/mail/wedu的所有者不是 Wedu，sendmail会使用chown将所有者修改为 Wedu。
- 你能利用它来读取 Wedu 的邮件吗？
- 你能利用它来给 Wedu 造成更大的损失吗？

3 提升 Set-UID 程序的安全性

exec函数
- exec函数系列通过将当前进程映像包装为新的，来运行紫禁城。有许多exec函数的版本，工作方式不同。它们可以归类为：
  - 使用/不适用 Shell 来启动新程序。
  - 通过 Shell 处理命令行参数（Shell 可以引入比我们预期的更多功能。要注意 Shell 是个强大程序）。
- 启动子进程涉及到依赖问题以及属性继承，我们之前看到它可能存在问题。函数execlp和execvp使用 Shell 来启动程序。它们使程序的执行依赖于当前用户安装的 Shell。例如，依赖于PATH和其它环境变量的值。函数execv跟家安全，因为它不向代码引入任何这种依赖。
- system（CMD）调用向 Shell 传递字符串来执行子进程（即作为单独派生的进程）。它是个用于执行 EXEC 函数的方便的前端。
- popen的标准实现也与之相似。这个函数打开到新锦成管道，以便执行命令，并读取任何输出作为文件流。这个函数也启动 Shell 来解释命令字符串。
如何安全地调用程序？
- 避免任何 Shell 的调用。不使用system，而是execve：execve不调用 Shell，system调用。
- 避免execlp (file, ...)和execvp(file,...)，它们的语义类似于 Shell。它们使用文件内存作为 Shell 的标准输入，如果文件不是有效的可执行目标文件。
- 小心可能使用 Shell 实现的函数。
  - Perl 的open函数可以执行命令，通常通过 Shell 来这么做。
提升system的安全性
- 要记住system首先调用/bin/sh。在 Ubuntu 中，它使用参数sh, -c和用户提供的字符串来调用execv /bin/sh。
- 在一些 Ubuntu 的早起版本中（例如 9.11），/bin/sh（实际上是 Bash）忽略 Set-UID 位选项。因此，在 Set-UID 中调用system（CMD）时，CMD 不会使用 Root 权限执行，除非 CMD 本身也是个 Set-UID 程序。下面代码在 Bash 中丢弃了 Set-UID 位。
```
if (running_setuid && privileged_mode == 0) 
    disable_priv_mode ();

... 
void disable_priv_mode () { 
    setuid (current_user.uid);
    setgid (current_user.gid); 
    current_user.euid = current_user.uid; 
    current_user.egid = current_user.gid;
}
```
- 但是，上面的保护看似破坏了一些需要使用system的 Set-UID 程序。因此，从某个版本起，由于添加了其它条件（对于 11.04 和 12.04），保护被移除了。
```
if (running_setuid && privileged_mode == 0 && act_like_sh ==0) 
    disable_priv_mode ();
```
  如果 Bash 通过/bin/sh符号链接调用，act_like_sh设为 1，因此权限没有禁用。但是，如果你直接将 Bash 变成 Set-UID 程序并尝试运行，保护仍然会有效，并且权限会丢弃。

4 最小权限原则

最小权限原则（最早由 Saltzer 和 Schroeder 提出）：

每个程序和系统用户都应该具有完成任务所必需的最小权限集合。

限制代码运行所需的安全权限，有一个非常重要的原因，就是降低你的代码在被恶意用户利用时，造成的损失。如果你的代码仅仅使用最小权限来执行，恶意用户就难以使用它造成损失。如果你需要用户使用管理员权限来执行代码，任何代码中的安全缺陷，都会通过利用该缺陷的恶意用户，潜在造成更大的损失。

编写特权程序时的问题：

程序需要该权限吗？
- 如果程序不需要任何特殊权限来运行，它不应该是个特权程序。
程序需要所有权限吗？
- 我们只给予程序完成任务所需的最小权限集合。
- 许多操作系统不向我们提供多种选择；我们可以选择包含所有 Root 权限的集合，或者不包含任何权限的集合。多数 Unix 系统就是这样，你要么是 Root 要么不是，没有中间值。
- 多数现代 Unix 系统（和 Windows）引入了更多选择。这些系统将 Root 权限划分为多种字权限。使用这种自粒度，我们就可以更好应用最小权限原则。
程序现在需要权限吗？
- 程序通常偶尔不需要特定权限，它们在这个时候就变得不必要了。我们应该暂时禁用它们来满足最小权限原则。这么做的好处就是，放置程序犯下意外的错误，使之不能对需要禁用权限的事情造成损失。下面的图像展示了这个要点。
- 稍后，禁用的权限可能就必要了，我们之后可以开启它。
- 要记住，开启或禁用权限可以在特定场景下降低损失，当攻击者不能像漏洞程序注入代码的时候。如果攻击者可以向漏洞程序注入代码，注入的代码自己就能够开启权限。
程序在未来需要权限吗？
- 如果权限不再需要了，它就是不必要的，应该永久溢出，所以最小权限集合应基于未来的需求来调整。

Unix 为我们提供了什么机制，来实现最小权限原则？

实用的系统调用：setuid()，seteuid()，setgid()，和setegid()。
seteuid(uid)：它为调用进程设置有效 UID。
- 如果调用进程的有效 UID 是超级用户，uid参数可以是任何东西。这通常由超级用户用来暂时让渡/获取权限。但是，进程的超级用户权限并没有丢失，进程可以拿回来。
- 如果调用进程的有效 UID 不是超级用户，UID 参数只能是有效 UID，真实 UID，以及保存的 UID。这通常由特权程序使用来恢复他的权限（原始的特权有效 UID 保存在保存的 UID 中）。
setuid(uid)：它设置了当前进程的有效 UID。如果调用者的有效 UID 是 Root，也会设置真实和保存的 UID。
- 如果调用进程的有效 UID 是超级用户，真实、有效和保存的 UID 全部会设为uid参数。之后，程序就不能够拿回 Root 权限（假设 UID 不是 Root）。这用于永久让渡高权限的访问权。
- 想要暂时放弃 Root 权限的 Set-Root-UID 程序，假设身份是非 Root 用户，之后不能使用setuid来拿回权限。你可以使用seteuid调用来完成它。
- 如果调用进程的有效 UID 不是超级用户，但是 UID 是调用进程的真实 UID 或者保存的 UID，那么有效 UID 会设置为uid。这类似于seteuid。
示例（在 Fedora 中）：进程使用有效 UID = 0 来运行，真实 UID= 500，在调用它们之后，有效和真实 UID 是什么？
- setuid(500); setuid(0);：答案：500/500（第一个调用生成 500/500，第二个调用失败）。
- seteuid(500); setuid(0);：答案：0/500（第一个调用生成 500/500，第二个调用生成 0/500）。
- seteuid(600); setuid(500);：答案：500/500（第一个调用生成 600/500，第二个调用生成 500/500）。
- seteuid(600); setuid(500); setuid(0);：答案：0/500（第一个调用生成 600/500，第二个调用生成 500/500，第三个调用生成 0/500）。