13 ms·
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
- selckin 8mo agoCan someone translate "Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable" to human?
- th0ma5 8mo ago[dead]
- woodruffw 8mo agoServices that process CMS[1] or PKCS#7 envelopes may be vulnerable to this bug. The most common example of these is S/MIME (for signed/encrypted email), but PKCS#7 and CMS show up in all kinds of random places. (Unless I'm missing something, a key piece of context here is that CMD/PKCS#7 blobs are typically allowed to select their own algorithms, at least within an allowlist controlled by the receiving party. So the fact that it depends on an AEAD-specific parameter encoding is probably not a huge hurdle for someone looking to exploit this.) [1]: https://datatracker.ietf.org/doc/html/rfc5652 https://datatracker.ietf.org/doc/html/rfc5652 [2]: https://datatracker.ietf.org/doc/html/rfc2315 https://datatracker.ietf.org/doc/html/rfc2315
- tptacek 8mo agoPKCS7 is a container format that pops up in a couple places in the TLS ecosystem (also in code signing); anywhere you need a secure blob that includes metadata. It's a very widely used format. AEAD ciphers are those that simultaneously encrypt and authenticate data. AES-GCM is the most popular; Chapoly is the 2nd most popular. AEAD ciphers are how modern programs do encryption. AEAD ciphers all rely on additional parameters, most commonly a nonce; it's critical to security that the nonce only ever be used once with a given key. You need the nonce to decrypt the AEAD ciphertext, so it's usually tacked on to the message (in more clever formats you can derive it contextually, but PKCS7 is a general-purpose format). In parsing PKCS7 messages, when OpenSSL comes across AEAD-encrypted blobs, it needs to parse out the nonce. AEAD nonces tend to have fixed sizes, but there are extended-nonce variants of AEADs, and the format allows for arbitrary-sized values. OpenSSL assumed a fixed nonce size, but parsed with a library that handled arbitrary-sized values. Stack overflow. A maliciously formatted Authenticode signature, certificate chain, OCSP response (I think?), all things that could trigger the bug.
- pseudohadamard 8mo agoThis is PKCS#7 (well, CMS) encryption, not signing, the only places you're likely to find that is in S/MIME encrypted (not signed) email, and how often do you see that used? In theory other protocols that use CMS as a container format like SCEP could be affected, but that doesn't do AuthEnv. It also signs the encrypted data so the attacker would have to be the authorised/trusted party you're communicating with. There's also CMC, but that doesn't do AuthEnv either, although one of its infinite options does allow for unsigned encrypted data.
- deleted 8mo ago[deleted]
- chc4 8mo ago2026 and we still have bugs from copying unbounded user input into fixed size stack buffers in security critical code. Oh well, maybe we'll fix it in the next 30 years instead.
- rvz 8mo ago2026 and why not vibe code our own cryptography library just like we are vibing lots of sandbox solutions? /s
- pixl97 8mo agoIt's 2023, why not use Rustls. It's 2014, why not use LibreSSL. You don't have to bring up AI, everyone just needs to leave OpenSSL to die.
- TacticalCoder 8mo ago> 2026 and why not vibe code our own cryptography library just like we are vibing lots of sandbox solutions? /s And make sure to make it a hybrid of PHP and JavaScript /s
- nly 8mo agoThe bug isn't actually the copy but the bounds check. If you had a dynamically sized heap allocated buffer as the destination you'd still have a denial of service attack, no matter what language was used.
- JohnLeitch 8mo agoAssuming you're talking about a heap buffer overrun, it's still possible to exploit for EoP in some cases.
- nly 8mo agoNo, I mean you'd just allocate a tonne of memory
- alanfranz 8mo agoIs this really exploitable? Is stack smashing really still a thing on any modern platform?
- alanfranz 8mo agoI’ll answer to myself: an RCE is very unlikely on any modern platform. DoS is possible. “ Impact summary: A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution.” From: https://openssl-library.org/news/secadv/20260127.txt https://openssl-library.org/news/secadv/20260127.txt
- woodruffw 8mo ago"Modern platform" is doing a lot of lifting; CMS and PKCS#7 rear their heads in all kinds of random places, like encryption/signing of OTA updates for routers. Those platforms are often (unreasonably) 10-20 years behind the norm for compile-time mitigations.
- b1temy 8mo agoThe link in the HN submission contains the same text and excerpt from your link. Additionally they note: - "While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk." IMO, probably in of itself, this alone is not able to do much besides maybe a crash / Denial of Service on modern systems. But it might be able to be used as part of a more advanced exploit chain, alongside other vulnerabilities, to potentially reach remote code execution, though this would be a much more sophisticated exploit and is maybe a bit of a reach. Still, I hesitate to call it impossible on modern systems due to the creativity of exploit developers.
- alanfranz 8mo agoYou are right. I linked a differently formatted article with the same content. I don’t know why I didn’t initially notice such text.
- 8mo ago
- jeffbee 8mo agoAnother "fix" in the long line of OpenSSL "fixes" that includes no changes to tests and therefore can't really be said to fix anything. Professional standards of software development are simply absent in the project, and apparently it cannot be reformed, because we've all been waiting a long time for OpenSSL to get its act together.
- kroeckx 8mo agoA test was added in this commit: https://github.com/openssl/openssl/commit/6297ac45d72ded9b45cad9a4fb2af6c29846d86c https://github.com/openssl/openssl/commit/6297ac45d72ded9b45...
- burnt-resistor 8mo agoOpenSSL and other similar security substandard projects have process deficiencies that lead to similar bugs over and over again. They never seem to learn the lesson that doing the same thing and expecting a different result is stupidity and/or insanity.
- notherhack 8mo agoLooks like Debian and some other distros are still on the vulnerable 3.5.4. Why did Openssl publish before the distros rolled to the fixed version?
- samueloph 8mo agoThis was patched on time: https://tracker.debian.org/news/1710762/accepted-openssl-354-1deb13u2-source-into-stable-security/ https://tracker.debian.org/news/1710762/accepted-openssl-354...
- TacticalCoder 8mo agoVery strange, as I type this both Bullseye and Bookworm are marked as fixed but Trixie isn't yet: https://security-tracker.debian.org/tracker/CVE-2025-11187 https://security-tracker.debian.org/tracker/CVE-2025-11187
- Sesse__ 8mo agobullseye and bookworm have too old versions to be vulnerable, it seems.
- TacticalCoder 8mo agoOh that's interesting: it indeeds shows "not affected" in the second table on the link I pasted but before that on the first table it says "Status // Fixed / Fixed". I never paid attention to the fact that one table had "Fixed" and the other "Not affected" for the same "Not affected" package.
- kroeckx 8mo agoThe correct URL is https://security-tracker.debian.org/tracker/CVE-2025-15467 https://security-tracker.debian.org/tracker/CVE-2025-15467 You're pointing to one of the other security issues for which a fix was released today.
- TacticalCoder 8mo agoTYVM for the proper URL kind sir!
- ofek 8mo agoI'd encourage folks to read the recently-published statement [1] about the state of OpenSSL from Python's cryptography project. [1]: https://news.ycombinator.com/item?id=46624352 https://news.ycombinator.com/item?id=46624352
- tptacek 8mo agoWe're recording a Security Cryptography & Whatever with them in an hour or so, if anyone's got questions they want us asking Alex and Paul. True facts: Paul co-created Frinkiac.
- snvzz 8mo agoInstead of everybody switching to LibreSSL, we had the Linux Foundation reward OpenSSL's incompetence with funding. We are still suffering from that mistake, and LibreSSL is well-maintained and easier to migrate to than it ever was. What the hell are we waiting for? Is nobody at Debian, Fedora or Ubuntu able to step forward and set the direction?
- m00dy 8mo agoPlease use Rust.
- johnisgood 8mo agoPlease use Ada / SPARK.
- 1over137 8mo agoHas anyone built OpenSSL with -fbounds-safety?
- pizlonator 8mo agoI just looked at the vuln in detail. If you are using OpenSSL compiled with Fil-C, then you're safe. This attack will be nothing more than a denial of service (the attacker won't get to actually clobber the stack, or heap, or anything).
- deleted 8mo ago[deleted]