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.
"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"
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.
Win32 API at some point started using the convention of having the buffer length be a reference. If the buffer is too small the API function updates the reference with the required buffer length and returns an error code.
I quite like that, within the confines of C. I prefer the caller be responsible for allocations, and this makes it harder to mess up.
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.
This 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.
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.)
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).
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.
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.
> 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.
"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.
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.
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.
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.
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.
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
We'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.
Instead 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?
How about standardizing on an API, then switching backends can be up to the administrator of the machine.
LibreSSL has put serious effort into making itself interchangeable with openssl.
OpenSSL as the incumbent has no incentive to do the same.
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.
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?
Humans are horribly unserious, yet extremely unfunny at the same time. What gives?
I particularly like the FIPS bit:
>The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.
"I hereby define the vulnerability to be outside the bit that I define to be secure, therefore we're not vulnerable".
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.
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
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.
Win32 API at some point started using the convention of having the buffer length be a reference. If the buffer is too small the API function updates the reference with the required buffer length and returns an error code.
I quite like that, within the confines of C. I prefer the caller be responsible for allocations, and this makes it harder to mess up.
Assuming you're talking about a heap buffer overrun, it's still possible to exploit for EoP in some cases.
No, I mean you'd just allocate a tonne of memory
Ah, okay. Thought you were talking about OOB heap write or something.
A denial of service attack is a million times better than an RCE attack.
2026 and why not vibe code our own cryptography library just like we are vibing lots of sandbox solutions? /s
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.
> 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
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?
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.
This 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.
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
[dead]
I 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).
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
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.
TYVM for the proper URL kind sir!
bullseye and bookworm have too old versions to be vulnerable, it seems.
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.
Is this really exploitable? Is stack smashing really still a thing on any modern platform?
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
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.
> 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.
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.
"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.
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.
Yes, but it would likely have to be chained with other bugs - at minimum, something that gives you an info leak.
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.
That depends on how aggressively the service is restarted.
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?
This was patched on time: https://tracker.debian.org/news/1710762/accepted-openssl-354...
Has anyone built OpenSSL with -fbounds-safety?
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.
A test was added in this commit: https://github.com/openssl/openssl/commit/6297ac45d72ded9b45...
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.
Please use Rust.
Please use Ada / SPARK.