Very strange, as I type this both Bullseye and Bookworm are marked as fixed but Trixie isn't yet:
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
21–30 of 52 posts
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#22Very 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
bullseye and bookworm have too old versions to be vulnerable, it seems.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#232026 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.
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.
Assuming you're talking about a heap buffer overrun, it's still possible to exploit for EoP in some cases.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#24Is this really exploitable? Is stack smashing really still a thing on any modern platform?
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#25Earlier quoted context omitted.
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.
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
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#26Very 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
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#27Earlier quoted context omitted.
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 pa…
> 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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#28Earlier quoted context omitted.
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.
Assuming you're talking about a heap buffer overrun, it's still possible to exploit for EoP in some cases.
[deleted]
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#29Another "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...