尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

libssh2 CVE-2026-55200:Exploitarium 首个已分配 CVE 的完整攻击面复盘

libssh2 CVE-2026-55200:Exploitarium 首个已分配 CVE 的完整攻击面复盘 libssh2 CVE-2026-55200Exploitarium 首个已分配 CVE 的完整攻击面复盘【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium在开源漏洞研究合集Exploitarium一个集中公开利用 PoC 与漏洞研究写作的归档仓库中libssh2-cve-2026-55200-poc 目录记录了该项目第一个正式分配 CVE 编号的成果CVE-2026-55200一个存在于 libssh2 传输层解析器的 SSH 包长度整数溢出漏洞。本文面向安全新手用通俗方式复盘这个漏洞的完整攻击面——从一行未检查的长度字段到本地 RCE远程命令执行验证。⚠️ 本文仅作安全研究学习用途。Exploitarium 作者明确要求请勿滥用这些 PoC仅可在自有系统、本地实验环境或明确授权的目标CTF/HTB 等上运行。一、漏洞背景libssh2 是什么哪里出了问题libssh2是被大量客户端/库依赖的 SSH 协议 C 语言实现。在 1.11.1 及更早版本中其传输层读取函数ssh2_transport_read()位于上游src/transport.c在处理整包解密路径时没有先校验攻击者可控的 SSHpacket_length字段是否超过协议规定的包体上限。用伪代码表示受影响的源码形态是total_num 4 packet_length 解码出的 SSH packet_length 字段 仅当 packet_length 1 时拒绝 total_num packet_length mac_len auth_len ← 32 位加法可能回绕 若 total_num 35000 或 total_num 0 才拒绝 按 total_num 分配内存问题在于加法在 32 位整数空间完成攻击者可以让结果回绕成一个很小的合法值骗过 35000 上限检查从而只分配一小块内存而后续解密写入仍按原始巨大的packet_length进行——经典的整数溢出导致的堆溢出Out-of-Bounds Write。二、核心攻击面复盘一次19 字节的魔法分配这是整个漏洞最精妙的部分值得每个新手细看 攻击者输入值packet_length0xffffffff4294967295mac_len0auth_len1632 位回绕过程packet_length mac_len auth_len 0xffffffff 0 16 ≡ 15 (mod 2^32) 4 15 19 → 通过 35000 上限检查只分配 19 字节于是实际分配仅 19 字节但原始packet_length仍是0xffffffff后续整包处理还会按派生长度如packet_length - 1风格写入——分配缺口高达约42 亿字节allocation_gap4294967275见本地验证证据 evidence/2026-06-23-local-harness-output.txt。这个验证数据非常直观vulnerable32_decisionaccepted ← 漏洞版本接受 vulnerable32_allocation19 ← 只分配 19 字节 fixed32_decisionrejected: out of boundary ← 修复版本拒绝 resultPASS 关于 64 位系统很多人以为 64 位上size_t是 8 字节就不会回绕。但补丁前的源码中该分支是先以 32 位/整型操作数完成加法再把结果赋给size_t所以 64 位 Linux 目标同样受影响——这一点在 libssh2-cve-2026-55200-poc/README.md 的 64-bit Note 中有详细说明。三、PoC 三层结构从算术验证到 RCE 证明该目录用三层递进的方式证明漏洞结构清晰很适合作为学习 PoC 工程的范本层级文件作用① 算术验证器poc/cve_2026_55200_probe.c独立的 C11 程序对比漏洞逻辑 vs 修复逻辑对同一输入的判断结果② 恶意 SSH 触发器poc/libpwn_cve_2026-55200_server.py最小恶意 SSH 服务器完成curve25519-sha256chacha20-poly1305协商后发送解密后packet_length0xffffffff的畸形加密包③ 本地 RCE 框架poc/libpwn_local_rce_harness.c poc/libpwn_local_rce_exploit.py模拟19 字节分配 → 覆盖回调指针 → 执行命令的受控目标生成 RCE 证明文件触发器的实战化程度值得一提它实现了最小 SSH 握手、密钥派生、服务端序列号管理与加密触发包发送自测与环回测试均可通过[self-test] PASS、[loopback-test] PASS。四、本地验证结果RCE 如何被证明本地 RCE 框架的思路作者强调这是受控证明目标不是通用万能利用目标对象中先有一个安全的回调函数指针紧邻一个命令缓冲区漏洞版本按 19 字节的小分配接收 180 字节攻击者数据溢出覆盖回调指针为exec_callback内部调用system()回调执行cmd /c echo libpwn-rce-verified ...proof.txt生成证明文件。最终输出exec_callback commandcmd /c echo libpwn-rce-verifiedrepo\poc\libpwn_rce_proof.txt RCE_PROOFPASS完整环境信息MinGW GCC 15.2.0 Python 3.13.12与逐步命令都保存在 evidence/2026-06-23-local-harness-output.txt保证结果可复现。五、修复方式与防御建议上游修复commit97acf3dfda80c91c3a8c9f2372546301d4a1a7a8PR #2052非常简洁——在加法之前拒绝超长的包长度if (packet_length LIBSSH2_PACKET_MAXPAYLOAD) { /* 直接拒绝 */ }对开发者和运维同学防御建议只有三条✅升级 libssh2 至包含该修复的版本受影响1.11.1 及以前✅ 对链接 libssh2 的服务CI/CD 系统、备份工具、Git 客户端等排查是否暴露 SSH 客户端入口攻击者可通过恶意 SSH 服务端如恶意 Git 远程仓库地址触发✅ 遵循先校验输入上限、再做算术的编码习惯——这正是本次漏洞的根因。六、在 Exploitarium 全仓库中的位置CVE-2026-55200 是作者公开的众多研究中第一个拿到正式 CVE 编号的。仓库根目录的 cves.md 已列出后续分配的 12 个 CVECVE-2026-58049 至 CVE-2026-58593覆盖 Firefox、FFmpeg、7-Zip、QEMU、Redis 等项目。值得一提的是作者对 libssh2 的研究不止于此紧接着还有第二个 PoC 目录 libssh2-publickey-list-calc-poc针对 publickey 子系统的两个堆溢出链Win32 分配回绕 Win64 悬空清理链两者可对照阅读理解 libssh2 解析器攻击面的全貌。仓库中所有材料均附Responsible Use声明Cybercrime is cringe——只做研究不做破坏。这也是 Exploitarium 这个项目存在的初衷用高质量、可复现的 PoC 把更多人引诱进漏洞研究领域。【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表