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”

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.

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.

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:

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.

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?

Whee! Client side vuln!

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.

---

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