OpenSSL 潜在严重远程代码执行漏洞
Potentially Critical RCE Vulnerability in OpenSSL

原始链接: https://research.jfrog.com/post/potential-rce-vulnerabilityin-openssl-cve-2025-15467/

## OpenSSL 漏洞:CVE-2025-15467 – 严重栈溢出风险 JFrog 安全研究团队发现 OpenSSL 3.0 至 3.6 版本中存在一个高危栈溢出漏洞 (CVE-2025-15467)。该漏洞可能被 NVD 评为“严重”,攻击者可以通过利用精心构造的 CMS AuthEnvelopedData 消息,特别是构造恶意 AEAD 参数(具体来说,是过大的初始化向量 (IV))来实现远程代码执行 (RCE)。 漏洞发生于 OpenSSL 在未进行长度验证的情况下,将 IV 复制到固定大小的栈缓冲区,导致在认证*之前*发生缓冲区溢出。这意味着攻击者无需加密密钥,只需能够发送特制的恶意消息即可。 受影响的应用包括使用 `CMS_RecipientInfo_decrypt` 等 API 以及 `openssl cms` 和 `openssl smime` 等工具的应用。FIPS 模块不受影响。 **建议立即修复:** 升级到 3.6.1、3.5.5、3.4.4、3.3.6 或 3.0.19。JFrog Xray 和 Catalog 已经标记了受影响的版本,以协助风险缓解。正在持续监控进一步的更新和利用途径。

黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 OpenSSL 潜在严重 RCE 漏洞 (jfrog.com) 7 分,由 beny23 发表于 3 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 whizzter 36 分钟前 [–] 之前讨论补丁发布:https://news.ycombinator.com/item?id=46782662 回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

The JFrog Security Research team is tracking a newly disclosed OpenSSL vulnerability, CVE-2025-15467, a stack overflow issue that may lead to remote code execution (RCE). While no official CVSS score has been assigned yet, it was rated with a “high” severity by OpenSSL and based on its characteristics, we assess that it may be rated as Critical by NVD.

OpenSSL recently patched 12 vulnerabilities, including 10 low, 1 moderate, and 1 high severity issue, but this stack overflow stands out due to its potential impact. An attacker can exploit the stack buffer overflow by sending a crafted CMS AuthEnvelopedData message with maliciously constructed AEAD parameters.

The following OpenSSL versions are vulnerable:
3.6, 3.5, 3.4, 3.3, 3.0

Versions 1.1.1 and 1.0.2 are not affected.

FIPS modules in 3.6, 3.5, 3.4, 3.3, and 3.0 are not affected, as the CMS implementation is outside the FIPS module boundary.

Our research team has managed to reproduce the vulnerability by calling the CMS_Decrypt API directly -

We have observed the following cases to be vulnerable to CVE-2025-15467 -

A. OpenSSL-based applications that call any of the following APIs -

  • CMS_RecipientInfo_decrypt
  • CMS_decrypt_set1_pkey_and_peer
  • CMS_decrypt_set1_pkey
  • CMS_decrypt
  • PKCS7_decrypt
  • EVP_CIPHER_asn1_to_param
  • CMS_EnvelopedData_decrypt

B. Applications that invoke any of the following OpenSSL tools -

  • openssl cms
  • openssl smime

Note that this is only an initial assessment and more attack vectors are likely to be relevant, stay tuned as we update this blog.

Our research team has successfully achieved code execution by exploiting the CVE. As always - real-world scenarios may require the attacker to bypass exploit mitigations such as Stack Canaries, ASLR and DEP - probably by exploiting a separate infoleak vulnerability.

Affected users should upgrade as follows:

  • 3.6 → 3.6.1
  • 3.5 → 3.5.5
  • 3.4 → 3.4.4
  • 3.3 → 3.3.6
  • 3.0 → 3.0.19

CMS (Cryptographic Message Syntax) is a standard for securely transmitting messages that ensures confidentiality, integrity, and authenticity. It is widely used in applications such as S/MIME for secure email communication, as well as in file storage and other scenarios where data protection is essential.

AuthEnvelopedData is a specific CMS structure designed to provide both encryption and authentication. Its key features include:

  1. Confidentiality: The content of the message is encrypted, so only the intended recipients, who possess the appropriate keys, can decrypt and read it.
  2. Integrity and Authentication: AuthEnvelopedData includes mechanisms to ensure that the message has not been altered in transit. This is typically achieved through a message authentication code (MAC) or an authentication tag, confirming that the data is intact and authentic.

A typical CMS AuthEnvelopedData message in OpenSSL contains:

  • Encrypted Content: The actual data or message that needs to be protected through encryption.
  • Recipient Information: Details about the intended recipients, usually including cryptographic keys or certificates that allow them to decrypt the message.
  • AEAD Cipher Parameters: The message may use authenticated encryption with additional data (AEAD) methods, such as AES-GCM, which provide both encryption and integrity protection in a unified process.
  • Initialization Vector (IV): A random value that is essential for many encryption algorithms, ensuring that each encryption operation produces unique ciphertexts, even for identical plaintexts.

When OpenSSL parses a CMS AuthEnvelopedData structure using AEAD ciphers, it extracts the IV (encoded in ASN.1 parameters) to prepare for decryption and authenticity verification.

The vulnerability occurs because the IV in the CMS AuthEnvelopedData structure can be oversized. OpenSSL copies the IV into a fixed-size stack buffer without verifying the length, causing a stack overflow that can lead to crashes or potentially RCE.

Importantly, the overflow occurs before any authentication, meaning an attacker does not need valid encryption keys. They only need to craft a malicious CMS message with an oversized IV to trigger the overflow.

This makes applications and services that parse untrusted CMS or PKCS#7 content with AEAD ciphers (e.g., S/MIME AuthEnvelopedData using AES-GCM) vulnerable. Exploitability for RCE depends on platform and toolchain mitigations, but the stack-based write primitive itself represents a significant risk.

From the vulnerability’s fix commit, it is clear that OpenSSL did not check whether the IV size exceeds the fixed-size stack buffer (EVP_MAX_IV_LENGTH) when copying it.

This stack overflow occurs before authentication, making it exploitable in scenarios where untrusted CMS messages are processed. While no official CVSS score has been released yet, the vulnerability is expected to be rated at least as a “high” severity issue by NVD, and potentially even a “Critical” severity issue, given the risk of RCE.

Organizations using affected OpenSSL versions should patch immediately and review systems that process S/MIME or PKCS#7 content to mitigate potential exploitation.

The JFrog Security Research team will continue to monitor this vulnerability for further updates and potential exploitation. Affected versions are already flagged in the JFrog Xray and JFrog Catalog databases, helping our customers identify and mitigate risk quickly.

联系我们 contact @ memedata.com