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...
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
41–50 of 52 posts
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#42I'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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#43I 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).
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#44[deleted]
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#45I'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
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?
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#462026 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 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".
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#47Can 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 par…
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#48Earlier 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.
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 encourag…
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#49I'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
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.
Re: OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
#502026 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…
Humans are horribly unserious, yet extremely unfunny at the same time. What gives?