1. 28

(In case the page goes down again, an archive is available at https://archive.ph/Igu2e.)


OpenSSL Security Advisory [01 November 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).

References

URL 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

  1. 24

    Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication.

    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:

    • 3.x only
    • Most TLS servers aren’t doing client authentication
    • From the advisory, if you are doing client TLS, the vulnerability is post-chain validation: so you have to get a public CA to sign a bad certificate (and at least you’ll see them in CT logs, wonder if anyone has searched!) or you have to skip cert validation
    • Even then, you have to get past mitigations to turn a DOS into an RCE

    It’s still obviously bad, but it doesn’t seem to be “internet crippling”

    1. 8

      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).

      1. 6

        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.

        1. 7

          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?

          1. 2

            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.

            1. 1

              I think it’s wrong to couch everything in terms of money.

              I wonder what you would say if your employer responded like this when you asked why you didn’t get your paycheck?

              Voluntary roles exist in lots of communities, and their voluntary nature doesn’t negate the responsibility that comes with them.

              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.

              1. 1

                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?

                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.

                1. 1

                  I do think that position comes with a responsibility not to raise false alarms if possible.

                  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.

          2. 3

            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.

          3. 1

            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.

          4. 18

            Two things about the ‘don’t use C’ bit at the end (a message that, in general, I’m totally on board with):

            • Memory safety issues being exploitable is not an intrinsic property of C, it is a property of implementations of C. On any CHERI architecture, this bug could cause a crash only (or, rather, a signal whose default behaviour is terminate the process), not arbitrary code execution. Ask your CPU vendors when they plan on shipping CHERI support.
            • There are a number of safe string libraries available for C, any one of which would have avoided this. OpenSSL could even have implemented one itself. The problem is that OpenSSL is really hates building reusable abstractions and so instead does unsafe pointer arithmetic instead of using a string abstraction. Compare this to something like Dovecot, which is also written in C, but uses a bunch of safe abstractions and rejects patches that try to do anything that looks like this OpenSSL code. You can write the same kind of terrible thing in C++ or unsafe Rust and it’s just as bad an idea there too. The main difference is that C++ and Rust have standard-library string implementations that it’s safe to depend on.
            1. 13

              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!

                1. 6

                  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.

                  1. 5

                    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.

                  2. 6

                    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.

                    1. 5

                      Relevant quote from the OpenSSL Security Team’s blog post:

                      Q: The 3.0.7 release was announced as fixing a CRITICAL vulnerability, but CVE-2022-3786 and CVE-2022-3602 are both HIGH. What happened to the CRITICAL vulnerability?

                      A: CVE-2022-3602 was originally assessed by the OpenSSL project as CRITICAL as it is an arbitrary 4-byte stack buffer overflow, and such vulnerabilities may lead to remote code execution (RCE).

                      During the week of prenotification, several organisations performed testing and gave us feedback on the issue, looking at the technical details of the overflow and stack layout on common architectures and platforms.

                      Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution.

                      Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.

                      However as OpenSSL is distributed as source code we have no way of knowing how every platform and compiler combination has arranged the buffers on the stack and therefore remote code execution may still be possible on some platforms.

                      Our security policy states that a vulnerability might be described as CRITICAL if “remote code execution is considered likely in common situations”. We no longer felt that this rating applied to CVE-2022-3602 and therefore it was downgraded on 1st November 2022 before being released to HIGH.

                      CVE-2022-3786 was NOT rated as CRITICAL from the outset, because only the length and not the content of the overwrite is attacker controlled. Exposure to remote code execution is not expected on any platforms.

                      We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.

                      1. 5

                        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.

                        1. 3

                          Where’s the critical-severity vulnerability they announced a week ago?

                          1. 8

                            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.

                            1. 2

                              duh, reading helps. Thanks!

                          2. 3

                            Whee! Client side vuln!

                            1. 3

                              Both client and server-side vulnerability, but several mitigating circumstances certainly blunt the impact.

                              1. 2

                                Using OpenSSL’s own severity definition, I would have ranked this as MODERATE.

                                1. 1

                                  @pushcx: The following Markdown is parsed/rendered incorrectly, with the level 3 header’s content appended to the level 2 header’s content.

                                  ---
                                  
                                  ## OpenSSL Security Advisory [01 November 2022]
                                  
                                  ### X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)
                                  
                                  Severity: High
                                  

                                  I’ve added an extra paragraph containing a zero width non-joiner here as a bodge.

                                  1. 1

                                    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.

                                    1. 1

                                      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