Is this really exploitable? Is stack smashing really still a thing on any modern platform?
That depends on how aggressively the service is restarted.
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
11–20 of 52 posts
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#12Is 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
"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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#13Is this really exploitable? Is stack smashing really still a thing on any modern platform?
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#14Is 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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#15Earlier 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…
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#16Another "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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#172026 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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#182026 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.
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#192026 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.
2026 and why not vibe code our own cryptography library just like we are vibing lots of sandbox solutions? /s
> 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
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#20Looks 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?