The web pages and git aren't updated yet, here is the vulnerability straight from the .tar.gz on their FTP:<p>Fixed two buffer overflows in punycode decoding functions.
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.<p>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.<p>An attacker can craft a malicious email address 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). ([CVE-2022-3786])<p>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 depending on stack layout for any given platform/compiler.
([CVE-2022-3602])<p>-----------------------------------<p>Doesn't sound <i>that</i> critical to me. CAs normally don't let you outright construct your own certificate, and I'd expect you'll have a hard time to get a certificate issued which is both for mail encryption (so you get an email name constraint) <i>and</i> TLS (SAN constraint). And servers without TLS client authentication, which is about 99.99 % of them, aren't affected. TLS client auth is usually only used in enterprise networks and typically terminated by middleboxes running ancient software anyway.
For anyone else with "mature" server configurations confused by the OpenSSL version number because you're on 1.1.x and wondering how to translate the patched 3.0.x version number to something that applies to you; it seems that you have nothing to worry about:<p>> This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected.<p>> We did release an update to OpenSSL 1.1.1, namely 1.1.1s, also on 1st November 2022, but this is a bug fix release only and does not include any security fixes.
From their blog [1] the vulnerability "was reported in private to OpenSSL on 17th October 2022 by Polar Bear who was performing an audit of OpenSSL code". OpenSSL 3.0 was released in September 2021.<p>Shouldn't fuzzing have caught this at some point? I was under the impression that OpenSSL was being fuzz tested constantly since Heartbleed.<p>[1] <a href="https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/" rel="nofollow">https://www.openssl.org/blog/blog/2022/11/01/email-address-o...</a>
I noticed that LibreSSL posted a patch release (3.6.1) does anyone know if this addresses similar issues?<p><pre><code> We have released LibreSSL 3.6.1, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.
It includes the following fixes:
- Custom verification callbacks could cause the X.509 verifier to
fail to store errors resulting from leaf certificate verification.
Reported by Ilya Shipitsin.
- Unbreak ASN.1 indefinite length encoding.
Reported by Niklas Hallqvist.
- Fix endian detection on macOS
Reported by jiegec on Github</code></pre>
OpenSSL blog post: <a href="https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/" rel="nofollow">https://www.openssl.org/blog/blog/2022/11/01/email-address-o...</a><p>Q: Are all applications using OpenSSL 3.0 vulnerable by default?<p>A: 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.<p>Q: Are there any mitigations until I can upgrade?<p>A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.
I liked this write up: <a href="https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/#exploitation-technical-details" rel="nofollow">https://securitylabs.datadoghq.com/articles/openssl-november...</a>
> An off by one error in the punycode decoder allowed for a single unsigned int
overwrite of a buffer which could cause a crash and possible code execution.<p><a href="https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b9feb3812bdc7781c784332" rel="nofollow">https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b...</a><p>A one character change.
Colm MacCárthaigh has a nice writeup on CVE−2022-3602 including steps to reproduce: <a href="https://github.com/colmmacc/CVE-2022-3602" rel="nofollow">https://github.com/colmmacc/CVE-2022-3602</a>
No RCE on Ubuntu:<p><pre><code> Ubuntu packages are built with stack protector, reducing the
impact of this CVE from remote code execution to a denial of
service.
</code></pre>
-- <a href="https://ubuntu.com/security/CVE-2022-3602" rel="nofollow">https://ubuntu.com/security/CVE-2022-3602</a>
Ubuntu 22.04 ships with OpenSSL 3.0.2. Now that it's November 1, I was expecting to see `openssl` in a `sudo apt upgrade` but it is not there.<p>Does anyone know when Ubuntu might ship the fix?
Sounds like this is mostly caught by stack overflow protections. From the release blog:<p>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.<p>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.<p>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.
This might be relevant: <a href="https://www.malwaretech.com/2022/11/everything-you-need-to-know-about-the-openssl-3-0-7-patch.html" rel="nofollow">https://www.malwaretech.com/2022/11/everything-you-need-to-k...</a>
There are probably many such vulnerabilities in this giant code base, being exploited by those who have resources to find them.<p>If OpenSSL is written in Rust, to what extent will the vulnerabilities be reduced (assuming that Rust is supported by the host, of course)?
Breaking news: software written in a language with error prone memory management has another security incident related to memory management.<p>Stay tuned for the next buffer overflow, use after free, and another easily preventable problem. We will run out of CVE numbers soon thanks to OpenSSL.<p>If there only were well-known solutions to this problem. Like programming languages that restrict what you can do in terms of memory management... Like Rust.<p>But hey, don't get distracted by automated memory management solutions, we are too busy fixing memory management problems manually.
Red Hat vulnerability page with a system detection script:<p><a href="https://access.redhat.com/security/vulnerabilities/RHSB-2022-004" rel="nofollow">https://access.redhat.com/security/vulnerabilities/RHSB-2022...</a>
<a href="https://twitter.com/cryptodavidw/status/1587505925731934208" rel="nofollow">https://twitter.com/cryptodavidw/status/1587505925731934208</a>'<p>> Can you imagine that 10 years ago, a paper came out called "The most dangerous code in the world: validating SSL certificates in non-browser software". And today we're still getting X.509 critical vulnerabilities in OpenSSL
(<a href="https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html" rel="nofollow">https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...</a>)
> the bugs were introduced as part of punycode decoding functionality<p>Did they handroll their own decoder, or did they use the reference code [0] in the RFC?<p>[0] <a href="https://www.rfc-editor.org/rfc/rfc3492#page-23" rel="nofollow">https://www.rfc-editor.org/rfc/rfc3492#page-23</a>
Shouldn't AI be able to track down these security problems in C and C++ code and patch them properly? It kind of seems like if current AI can't solve these problems which are strictly programmatic then what else can we expect them to solve. Or is even this some kind of NP level problem?
Reminder that rustls exists as a pretty mature TLS implementation in safe Rust (thus systematically avoiding issues like this). Thanks to Brian Smith for creating the webpki crate which was thoroughly engineered from the start to avoid stuff like this.<p>rustls has C bindings these days: <a href="https://github.com/rustls/rustls-ffi" rel="nofollow">https://github.com/rustls/rustls-ffi</a><p>I've started work on Python bindings too, with the idea that it probably wouldn't be crazy hard to do something that can pass as an `ssl.SSLSocket`. Please sponsor me on GitHub if that's something you'd like to use (<a href="https://github.com/sponsors/djc" rel="nofollow">https://github.com/sponsors/djc</a>).<p>Note, we're aware that by far the biggest impediment to adopting rustls is the lack of support for IP addresses in certificates (we currently need a DNS name). This work is funded and should be completed in the next few months.
<p><pre><code> * Fixed two buffer overflows in punycode decoding functions.
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.
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.
An attacker can craft a malicious email address 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).
([CVE-2022-3786])
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 depending on stack layout for any given platform/compiler.
([CVE-2022-3602])</code></pre>
Apparently the "Critical" vulnerability has been downgraded to "High" since the annoucement: <a href="https://www.openssl.org/news/vulnerabilities.html" rel="nofollow">https://www.openssl.org/news/vulnerabilities.html</a>
So, back in early 2000's, it was common knowledge that some US gov't agency (NSA?) had managed to get a saboteur in to the SSL standardization committee.<p>Once they were outed, it was clear that all they did was push as much complexity as possible into the spec, ensuring a steady stream of vulnerabilities like this.<p>For instance, instead of hardcoding things that are definitely fine, they would push through a configuration knob, or champion obscure extensions to the wire protocol in the name of "generality". Whenever someone else proposed a compliciation, they would fast track it as much as possible, and simplifications were black holed.<p>I can't find a reference anywhere. Does anyone know what I'm (mis)remembering?
> Q: Is this a branded vulnerability?<p>> A: The OpenSSL project has not named or created logos for either CVE. The best way to refer to them is via the CVE names to avoid confusion.<p>I chuckled a bit, but im also sad that we ended up in this situation. The obsession with brands is, to some extent, unhealthy.
>Q: Is this a branded vulnerability?<p>>A: The OpenSSL project has not named or created logos for either CVE. The best way to refer to them is via the CVE names to avoid confusion.<p>"I survived CVE-2022-3786 & CVE-2022-3602 and all I got was this crappy t-shirt."
Is this exploitable ?
With current mitigations (NX, Stack Canary, ASLR), I don't see how a buffer overflow on it's own could result in Remote Code Execution.
The most surprising to me is that NodeJS says they are affected <a href="https://nodejs.org/en/blog/vulnerability/openssl-november-2022/" rel="nofollow">https://nodejs.org/en/blog/vulnerability/openssl-november-20...</a>
Url changed from <a href="https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html" rel="nofollow">https://mta.openssl.org/pipermail/openssl-announce/2022-Nove...</a> to a post with more background.<p>(via <a href="https://news.ycombinator.com/item?id=33423271" rel="nofollow">https://news.ycombinator.com/item?id=33423271</a>, but we merged that thread hither)