[HN Gopher] OpenSSL: Stack buffer overflow in CMS AuthEnvelopedD...
___________________________________________________________________
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
Author : MagerValp
Score : 64 points
Date : 2026-01-27 16:56 UTC (6 hours ago)
(HTM) web link (openssl-library.org)
(TXT) w3m dump (openssl-library.org)
| selckin wrote:
| Can 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?
| woodruffw wrote:
| Services 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
|
| [2]: https://datatracker.ietf.org/doc/html/rfc2315
| tptacek wrote:
| PKCS7 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.
| chc4 wrote:
| 2026 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 wrote:
| 2026 and why not vibe code our own cryptography library just
| like we are vibing lots of sandbox solutions? /s
| pixl97 wrote:
| It'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 wrote:
| > 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 wrote:
| The 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 wrote:
| Assuming you're talking about a heap buffer overrun, it's
| still possible to exploit for EoP in some cases.
| nly wrote:
| No, I mean you'd just allocate a tonne of memory
| JohnLeitch wrote:
| Ah, okay. Thought you were talking about OOB heap write
| or something.
| tialaramex wrote:
| The actual vulnerability is indeed the copy. What we used to
| do is this:
|
| 1. Find out how big this data is, we tell the ASN.1 code how
| big it's allowed to be, but since we're not storing it
| anywhere those tests don't matter
|
| 2. Check we found at least some data, zero isn't OK, failure
| isn't OK, but too big is fine
|
| 3. Copy the too big data onto a local buffer
|
| The API design is typical of C and has the effect of
| encouraging this mistake int
| ossl_asn1_type_get_octetstring_int(const ASN1_TYPE *a, long
| *num, unsigned char *data, int max_len)
|
| That "int" we're returning is either -1 or the claimed length
| of the ASN.1 data without regard to how long that is or
| whether it makes sense.
|
| This encourages people to either forget the return value
| entirely (it's just some integer, who cares, in the happy
| path this works) or check it for -1 which indicates some
| fatal ASN.1 layer problem, give up, but ignore other values.
|
| If the thing you got back from your function was a Result
| type you'd know that this wasn't OK, because it isn't OK. But
| the "Eh, everything is an integer" model popular in C
| discourages such sensible choices because they were harder to
| implement decades ago.
| wat10000 wrote:
| A denial of service attack is a million times better than an
| RCE attack.
| pjmlp wrote:
| I recall Hoare,
|
| "A consequence of this principle is that every occurrence of
| every subscript of every subscripted variable was on every
| occasion checked at run time against both the upper and the
| lower declared bounds of the array. Many years later we asked
| our customers whether they wished us to provide an option to
| switch off these checks in the interests of efficiency on
| production runs. Unanimously, they urged us not to they already
| knew how frequently subscript errors occur on production runs
| where failure to detect them could be disastrous. I note with
| fear and horror that even in 1980 language designers and users
| have not learned this lesson. In any respectable branch of
| engineering, failure to observe such elementary precautions
| would have long been against the law."
|
| -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
|
| Guess what 1980's language he is referring to.
|
| Then in 1988,
|
| https://en.wikipedia.org/wiki/Morris_worm
|
| It has been 46 years since the speech, and 38 since the Morris
| worm.
|
| How many related improvements have been tackled by WG14?
| alanfranz wrote:
| Is this really exploitable? Is stack smashing really still a
| thing on any modern platform?
| alanfranz wrote:
| I'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
| woodruffw wrote:
| "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 wrote:
| The 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 wrote:
| You are right. I linked a differently formatted article
| with the same content. I don't know why I didn't initially
| notice such text.
| JohnLeitch wrote:
| > though this would be a much more sophisticated exploit
| and is maybe a bit of a reach.
|
| Not necessarily. I have successfully exploited stack buffer
| overflows in major products despite stack canaries, ASLR,
| and DEP. It largely depends on context; if the vector is
| something that can be hit repeatedly, such a webform that
| that takes a cert or whatever, that simplifies things a lot
| versus something like a file format exploit, where you
| probably only get one chance. While I haven't analyzed this
| vulnerability, I would absolutely assume exploitability
| even if I couldn't see a way myself.
| buckle8017 wrote:
| That depends on how aggressively the service is restarted.
| chc4 wrote:
| OpenSSL is used by approximately everything under the sun. Some
| of those users will be vendors that use default compiler flags
| without stack cookies. A _lot_ of IoT devices for example still
| don 't have stack cookies for any of their software.
| JohnLeitch wrote:
| It depends on what mitigations are in place and the arrangement
| of the stack. Even with stack canaries, having an unfortunate
| value on the stack e.g. a function pointer can still be quite
| dangerous if it can be overwritten without hitting any of the
| stack canaries.
| MajesticHobo2 wrote:
| Yes, but it would likely have to be chained with other bugs -
| at minimum, something that gives you an info leak.
| jeffbee wrote:
| Another "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 wrote:
| A test was added in this commit:
| https://github.com/openssl/openssl/commit/6297ac45d72ded9b45...
| burnt-resistor wrote:
| OpenSSL 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 wrote:
| Looks 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 wrote:
| This was patched on time:
| https://tracker.debian.org/news/1710762/accepted-openssl-354...
| TacticalCoder wrote:
| Very 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
| Sesse__ wrote:
| bullseye and bookworm have too old versions to be vulnerable,
| it seems.
| TacticalCoder wrote:
| Oh 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 wrote:
| The correct URL is 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 wrote:
| TYVM for the proper URL kind sir!
| ofek wrote:
| I'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
| m00dy wrote:
| Please use Rust.
| 1over137 wrote:
| Has anyone built OpenSSL with -fbounds-safety?
___________________________________________________________________
(page generated 2026-01-27 23:01 UTC)