OpenSSL 3 Patch, Once Heartbleed-level 'Critical,' Arrives as a Lesser 'High' (arstechnica.com) 21
An OpenSSL vulnerability once signaled as the first critical-level patch since the Internet-reshaping Heartbleed bug has just been patched. It ultimately arrived as a "high" security fix for a buffer overflow, one that affects all OpenSSL 3.x installations, but is unlikely to lead to remote code execution. From a report: OpenSSL version 3.0.7 was announced last week as a critical security fix release. The specific vulnerabilities (now CVE-2022-37786 and CVE-2022-3602) had been largely unknown until today, but analysts and businesses in the web security field hinted there could be notable problems and maintenance pain. Some Linux distributions, including Fedora, held up releases until the patch was available. Distribution giant Akamai noted before the patch that half of their monitored networks had at least one machine with a vulnerable OpenSSL 3.x instance, and among those networks, between 0.2 and 33 percent of machines were vulnerable. But the specific vulnerabilities -- limited-circumstance, client-side overflows that are mitigated by the stack layout on most modern platforms -- are now patched, and rated as "High." And with OpenSSL 1.1.1 still in its long-term support phase, OpenSSL 3.x is not nearly as widespread. Malware expert Marcus Hutchins points to an OpenSSL commit on GitHub that details the code issues: "fixed two buffer overflows in puny code decoding functions." A malicious email address, verified within an X.509 certificate, could overflow bytes on a stack, resulting in a crash or potentially remote code execution, depending on the platform and configuration.
Re: (Score:1)
That's a lot of users.
Re: (Score:3)
Sort of. A lot of the included local software like wget uses gnutls, not OpenSSL. OpenSSL is used by Apache and Nginx, so major public-facing web servers running OpenSSL 3.0 are affected.
But web server operators are little more cautious with migration to newer OSes (even LTS to LTS releases). Ubuntu 20.04.5 LTS is still widely deployed and receives security updates until mid-2025 and it deploys OpenSSL 1.1.1, which is unaffected by this bug.
While the audience is growing, it's not at a major point where e
Guess we're nobody then (Score:3)
There is no OpenSSL 2. I think there was a FIPS module with that version, which is why they skipped that version.
Most of the people using OpenSSL have been forced to go to OpenSSL 3 due to the CVEs, at least in any software that has to worry about security audits.
Re: (Score:2)
Indeed, I just checked most of my systems (some latrest debian 11) and I get:
openssl version
OpenSSL 1.1.1n 15 Mar 2022
I'll check a dev station VM using Ubuntu 22.04 LTS when I fire it up since a user posted it might be used there above.
Slashdot has been useful today :)
Why hasn't everyone switched to LibreSSL? (Score:3)
After the Heatbleed debacle, the LibreSSL project [libressl.org] began, and in those early days they were blogging [opensslrampage.org] about what a mess the OpenSSL code base was, I thought everyone would switch pretty quick from OpenSSL to LibreSSL. Looks like not.
Whatever happened there?
Hmm, LWN.net says LibreSSL "languishes" on Linux:
https://lwn.net/Articles/841664/ [lwn.net]
I presume that this bug doesn't affect LibreSSL. If so, maybe it's time for a second look at LibreSSL.
Re:Why hasn't everyone switched to LibreSSL? (Score:4, Interesting)
macOS had switched to LibreSSL by at least 2018 (macOS Mohave), if not earlier.
Adoption in Linux is sometimes hindered by whether a particular license is considered compatible with the GPL - that may be the case with LibreSSL. Or it could be the Linux powers just don't like Theo. Or it could be obstinacy.
Re:Why hasn't everyone switched to LibreSSL? (Score:4, Insightful)
Because a lot of projects rely on FIPS due to US Government customers and libreSSL doesn't have that.
OpenSSL underwent a huge refactoring with OpenSSL 3.
Re: (Score:1)
After the Heatbleed debacle, the LibreSSL project began, and in those early days they were blogging about what a mess the OpenSSL code base was, I thought everyone would switch pretty quick from OpenSSL to LibreSSL. Looks like not.
Can you imagine what the world would be like if everyone just abandoned a project for some unproven other thing with no track record of its own every time there was a vulnerability?
LibreSSL managed to bork their secure random number generator so bad at one point it was reliably spitting out the same values across multiple rand calls.
Time to switch to schannel, NSS, bouncy castle, boring SSL, polar SSL or some random stack nobody ever heard of until you find one that is infallible. That does not seem like a
Re: (Score:2)
... and in those early days they were blogging [opensslrampage.org] about what a mess the OpenSSL code base was, ...
I'd never seen the blog, thanks!
It's hilarious reading if you start at the far end (earliest posts) [opensslrampage.org] and work your way forward from there...
Re: (Score:3, Insightful)
OpenSSL is time-proven with lots of effort poured in to it and it's a 100% critical library. You can't just replace that with some random whatever.
Plus OpenSSL supports lots of acceleration techniques not present in other libraries.
Those new libraries have had much worse vulnerabilities than anything in OpenSSL. Crypto is hard.
Re:Why hasn't everyone switched to LibreSSL? (Score:5, Informative)
Congratulations on being modded Insightful!
OpenSSL is time-proven with lots of effort poured in to it and it's a 100% critical library. You can't just replace that with some random whatever.
LibreSSL is a reworking of OpenSSL by the paranoid folks over at OpenBSD, a project known for being secure [openbsd.org].
LibreSSL was specifically intended to be a more-secure replacement for OpenSSL. I guess LibreSSL is not 100% drop-in compatible or else it would be more widely used in Linux.
Those new libraries have had much worse vulnerabilities than anything in OpenSSL. Crypto is hard.
Let's just check the score card, shall we?
CVEs for OpenSSL [cvedetails.com]
CVEs for LibreSSL [cvedetails.com]
It would be unfair to compare total number of CVEs because OpenSSL dates back to 1999. I'm interested in recent CVEs. Let's look at the last two years.
OpenSSL: 8 in 2021, 10 in 2022, total: 18
LibreSSL: 1 in 2021, 0 in 2022, toal: 1
The CVEs have a severity assigned on the 1 to 10 scale. LibreSSL's single CVE from the past two years is severity: 4.3
OpenSSL, on the other hand, has had 17 CVEs rated 4.3 or higher in the past two years. One of those was 7.5 and three of the issues this year were rated 10. (Including of course CVE-2022-2274 [cvedetails.com], the issue that prompted this Slashdot story.)
Please explain to us all how LibreSSL is "much worse" than OpenSSL in any way. Take your time, I'll wait.
Re: (Score:3)
LibreSSL is much worse in terms of portability/support for exotic host operating systems. It assumes a modern UNIX-like host. That's an intentional decision on their part, as it gets rid of a lot of alternate code paths, making it simpler to test and analyse (and hence, at least in theory, more secure). At this point, switching to LibreSSL is probably a good idea if you don't need to run on exotic sys
Re: (Score:2)
The GP post claimed "much worse vulnerabilities" and that was what I was thinking of. But fair enough, I did say "any way" and I didn't mention "vulnerabilities"; and your points about portability and certification are correct.
At this point, switching to LibreSSL is probably a good idea if you don't need to run on exotic systems
You and I are in agreement here. It looks like LibreSSL isn't a drop-in replacement for OpenSSL, but mission zero for a security library is not to make your security worse and Open
Re: (Score:2)
CVE is a measurement of reports, not code quality.
Reportedly LibreSSL is 2-3000 patches behind OpenSSL. How many are security fixes? Does anybody know? A lack of a CVE doesn't prove a lack of a problem.
It's a shame, but that's what LWN claims and they don't have an axe to grind.
Re: (Score:3)
Let's just check the score card, shall we?
CVEs for OpenSSL
CVEs for LibreSSL
It would be unfair to compare total number of CVEs because OpenSSL dates back to 1999. I'm interested in recent CVEs. Let's look at the last two years.
OpenSSL: 8 in 2021, 10 in 2022, total: 18
LibreSSL: 1 in 2021, 0 in 2022, toal: 1
While it's nice to see people trying to objectively measure things the "score card" approach is not a valid comparison. People are just not bothering to test and or submit duplicate CVEs to LibreSSL. For example the following:
https://ftp.openbsd.org/pub/Op... [openbsd.org]
None of these ported patches from OpenSSL to fix the same CVEs in LibreSSL are reflected as corresponding LibreSSL CVEs in the links you provided. People are testing and finding bugs in OpenSSL and simply not bothering to do or report the same with L
Re: (Score:2)
Thank you for raising some points I hadn't considered. If I could I would mod this post up.
I do think that overall LibreSSL is more secure than OpenSSL. I can well believe that there are still vulnerabilities that are common to both; but it's certain that there are vulnerabilities still in OpenSSL that have been fixed in LibreSSL, and I'd be very surprised if LibreSSL had any vulnerabilities that aren't in OpenSSL. The OpenBSD guys are pretty darn good at security.