(In case the page goes down again, an archive is available at https://archive.ph/Igu2e.)
### Changes between 3.0.6 and 3.0.7 [1 Nov 2022]
)
X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)Severity: High
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.
Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.
Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.
In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
This issue was reported to OpenSSL on 17th October 2022 by Polar Bear. The fixes were developed by Dr Paul Dale.
We are not aware of any working exploit that could lead to code execution, and we have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022).
X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786)Severity: High
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service).
In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
This issue was discovered on 18th October 2022 by Viktor Dukhovni while researching CVE-2022-3602. The fixes were developed by Dr Paul Dale.
We have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022).
ReferencesURL for this Security Advisory: https://www.openssl.org/news/secadv/20221101.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html
I won’t call this a nothingburger but there are a few things that make it look a bit less spicy for people running servers:
It’s still obviously bad, but it doesn’t seem to be “internet crippling”
Well said! While there was a lot of anxiety around this issue since it was marked CRITICAL (a-la-heartbleed), the OpenSSL team did post a rationale in their blog (see next response by @freddyb) for the severity downgrade (which aligns with your explanation as well).
I don’t understand why the OpenSSL maintainers didn’t downgrade the pre-announcement. People cleared their diaries for this; a post-pre-announcement saying “whoops it’s only a high, you can stop preparing for armageddon” might have saved thousands of hours, even if it only came on Monday.
Aren’t the OpenSSL maintainers basically one guy fulltime and some part-timers? Why are they expected to perform at the level of a fully-funded security response team? If they can save thousands of hours, shouldn’t they be funded accordingly?
I mean, it’s absolutely true in general that people making money out of FOSS should fund its development and maintenance, and to the extent this isn’t already true of OpenSSL, of course I think it should be fixed. But I think it’s wrong to couch everything in terms of money. Voluntary roles exist in lots of communities, and their voluntary nature doesn’t negate the responsibility that comes with them. If it’s wrong for big tech to profit by extracting free labour out of such social contracts—and I do think it is—it doesn’t seem much better to just assimilate all socially mediated labour into capitalism and have done.
But I also just think that if one makes a mistake that wastes lots of people’s time, it’s a nice gesture to try to give them that time back when the mistake is realised.
I wonder what you would say if your employer responded like this when you asked why you didn’t get your paycheck?
Uh, what responsibility is that exactly? The OpenSSL people have gone above and beyond to handle this security issue and you’re complaining that they’re not fulfilling their ‘voluntary responsibility’ because they didn’t save a few hours of your time? Do you realize how entitled and churlish you sound? Do me a favour, don’t talk about Open Source until you develop a sense of gratitude for the immensity of the benefits you’re getting from the maintainers every day. And I’m not even talking about paying them money, since that seems too much to ask! Just some basic human respect and gratitude.
It’s not my time personally that’s at issue here. I respect that the OpenSSL people have handled this security issue, and that they’ve stepped up to maintain an important thing. I do think that position comes with a responsibility not to raise false alarms if possible.
The OpenSSL maintainers are, like us, members of a community in which we all contribute what we can. I don’t think that gratitude and criticism are mutually exclusive, but I am sorry if I seemed too complainy, and I appreciate the people in question were probably operating under no small amount of pressure.
People are very quick to assign new responsibilities to people who give them free stuff. Time and again I find this pretty incredible. Like, here are some people making a public good on their own dime. And users feel so incredibly comfortable jumping in with critiques. They didn’t do this, they should have done it like that. Pretty easy to sit back, do nothing, and complain about others’ hard work.
I heard third hand that the downgrade was done a couple hours before the release. Wouldn’t be that useful if it is indeed the case.
Well, a lot of corporate networks have internal trust chains and suites and often you have to skip validation to get past this step.
Still not Internet crippling though.
Two things about the ‘don’t use C’ bit at the end (a message that, in general, I’m totally on board with):
As a sysadmin who was “made [to] worry beyond normal” as part of your blog, I can assure you that it wasn’t that bad for me at least. All I did was accelerate work on my container CVE scanning/reporting infrastructure that was needed anyway.
To me it’s just one of those cases where false positives are fine since they’re MUCH better than false negatives. I’m also subscribed to CISA’s Known Exploited Vulnerabilities Catalog (which emails me like every week), so I’m long past alarm fatigue!
Blog post is up now. https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/
Looks like it’s probably mostly only exploitable as a DoS on Windows: https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/#main-takeaways
But this is a reminder of why the LGPL’s right to re-link with an updated version of a library is an important practical right. If you depend on using a proprietary Windows app that uses OpenSSL 3 to connect to untrusted TLS servers you can’t use that safely until your vendor ships a fix. You lack the mechanism and the right to repair it yourself.
I don’t want a bug in code that I write to be unfixable by the users of that code. That’s why I prefer to use a copyleft. It’s way easier than never writing bugs.
A good amount of open-source software based entities thrive on bugs not being fixable by the users, so they can make money from the Support contract (since the software is already open source). RedHat, for instance.
As a smaller company without dedicated sysadmins, we definitely got some alarm fatigue by this. The one week’s notice made it seem like another Heartbleed level bug with a catchy new name and dedicated website, and it really wasn’t.
I don’t know what the solution is, and I don’t know the processes here, but I wish the CRITICAL status would have been confirmed and downgraded to HIGH a week earlier.
Relevant quote from the OpenSSL Security Team’s blog post:
This really doesn’t seem as bad as it was being made out to be - the size of the overflow seems very limited (IE it’s not attacker get arbitrary control of the entire stack), the attack itself requires the server initiating client auth, etc
The initial headlines last week had me assuming unbound overflow that could be trivially initiated against any OpenSSL service.
Where’s the critical-severity vulnerability they announced a week ago?
duh, reading helps. Thanks!
Whee! Client side vuln!
Both client and server-side vulnerability, but several mitigating circumstances certainly blunt the impact.
Main submission: https://lobste.rs/s/vjemu5/openssl_security_advisory_01_november
Using OpenSSL’s own severity definition, I would have ranked this as MODERATE.
@pushcx: The following Markdown is parsed/rendered incorrectly, with the level 3 header’s content appended to the level 2 header’s content.
I’ve added an extra paragraph containing a zero width non-joiner here as a bodge.
We’re using the commonmarker gem, which wraps cmark-gfm. Maybe one of them has seen it and we can update to get a fix? Or maybe it’s an odd behavior that is forever enshrined in the spec as a sacrifice on the altar of backwards compatibility. I can’t guess.
Sorry, I had the wrong problem. This is a lobste.rs rendering issue. When lobste.rs converts
<h1>
and<h2>
elements to<strong>
elements, the line-breaking behavior of the header elements is lost. This is fine most of the time, as<p>
elements line-break, but it’s a problem here.https://github.com/lobsters/lobsters/blob/893b0c5235471154183ca8fa5304860aadd97ac2/extras/markdowner.rb#L16-L19