Lab 1
Set-UID Program Vulnerability
1 实验描述
Set-UID是Unix操作系统中一种重要的安全机制。运行Set-UID程序时,它将采用所有者的权限。例如,如果程序的所有者是root,那么任何人运行此程序时,程序在执行期间获得root权限。Set-UID允许我们做很多有趣的事情,但不幸的是,它也是很多坏事的罪魁祸首。 因此,本实验的目标有两个方面:
(1)欣赏其良好的一面:理解为什么需要Set-UID以及如何实现它。
(2)注意其不好的一面:了解其潜在的安全问题。
Task1:
- 利用“whereis”命令找到su文件所属位置路径2. 拷贝“su”到当前文件夹,并查看是否复制成功3. 运行当前文件夹中的su,发现无法认证4. 运行/bin文件夹中的su,发现可以获得super user权限
2. 与上述四步相似的过程测试其他命令
sudo:在当前文件夹下的sudo不可用,提示:必须属于用户ID 0 并且设置setuid位;但在/usr/bin下的可以正常用.
passwd:在当前文件夹下的passwd不可用,提示:认证令牌操作错误;但在/usr/bin下的
可以正常用,显示:已成功更新密码
chsh:在当前文件夹下的chsh不可用,提示:无法改变ID到root;但在/usr/bin下的可以正常用
可见,setuid机制是一种控制用户权限的机制,因为“passwd”、“chsh”、“su”、“suso”都需要使得用户在普通权限下临时具有root权限,从而可以访问和修改一些root权限下的文件。如果没有setuid程序,那么普通用户讲没有权限修改自己的密码,没有权限运行很多程序,不能安装软件等。所以setuid是必要的机制。
Task2
- 安装zsh
2. 拷贝/bin/zsh 到/tmp, 同时设置拷贝到tmp目录下的zsh为set-uid root权限
3. 然后以普通用户登录,运行/tmp/zsh。可见zsh是能获得root权限的,可见zsh是不安全的。
4.测试bash,操作同上,测试发现bash在同样情况下,无法获得root权限。由此可见bash比zsh要更为安全
Task3
1. 把默认的shell指向zsh
Task4
1.编写lab1-4.c
2.进行对lab1-4.c的攻击,编译lab1-4.c并且更改其权限,之后修改PATH中路径。运行程序发现可以获得root权限。
你能够设置这个Set-UID程序运行你自己的代码而不是/bin/ls吗?如果你能的话,你的代码具有root权限吗?描述并解释你的观察。
回答:可见能够设置这个Set-UID程序运行自己的代码而不是/bin/ls,基本思路是通过修改PATH变量。攻击者可以利用system查找程序时PATH的顺序来攻击。可见这样的程序是存在漏洞的
3.sh符号链接到bash
4.使用bash运行攻击程序,发现无法获得root权限
修改/bin/sh使得其返回到/bin/bash,重复上面的攻击,你仍然可以获得root权限吗?描述并解释你的观察。
回答:可见修改/bin/sh使得其返回到/bin/bash,重复上面的攻击,不可以获得root权限。bash有某种内在的保护机制可以防止这种攻击。
Task5
1.在执行这个任务之前,确保/bin/sh指向zsh
2. 编写lab1-5.c
3.模拟攻击,编译lab1-5.c并将test2设置为setuid root 程序
4创建rootfile.dat文件在里面写入数据
5.在执行test2时,在程序的后面添加rm –f rootfile.dat,这样system会继续执行该命令,并且删除文件
6.编辑lab1-5.c,将q值赋为1
7.重复上述攻击
无效
可见system的工作方式是将后续的命令传递给shell,这样就可能被利用shell漏洞攻击。而execve是创建子进程,参数是传给子进程的,因此可以防止此类攻击。
Task6
1. 建立一个动态链接库。把下面的程序命名为mylib.c。在函数库libc中重载了sleep函数。
2.编译mylib.c
3.编写myprog.c
4. 在普通用户编译myprog.c并运行,发现链接到的是mylib
5.在root下编译myprog.out,在普通用户下执行,发现是链接到真正的lib中
6.在root下编译myprog.out,并设置为setuid程序,在root下执行,发现时链接到mylib.c
7.在其他用户下执行,还是链接到真正的lib
可见只有用户自己创建的程序自己去运行才会链接到自己的sleep函数。
Task7
1. 编辑lab1-7.c
2.编译lab1-7.c
3.设置为setuid后查看/etc/zzz文件内容