6 ms·
The web pages and git aren't updated yet, here is the vulnerability straight from the .tar.gz on their FTP: Fixed two buffer overflows in punycode decoding fun
by formerly_proven 4y ago
The web pages and git aren't updated yet, here is the vulnerability straight from the .tar.gz on their FTP:
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])
-----------------------------------
Doesn't sound that 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) and 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.
- buro9 4y agoThe NixOS update has some details: https://github.com/NixOS/nixpkgs/pull/198999 https://github.com/NixOS/nixpkgs/pull/198999 ### Changes between 3.0.6 and 3.0.7 [1 Nov 2022] * 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]) *Paul Dale*
- secondcoming 4y agoThis does not seem to contain any extra information at all?
- Sarkie 4y agoit has more \r\n
- cesarb 4y agoFor context, when the parent comment was posted, the link to the announcements mailing list archive (which was the original link for this article, it seems to have been changed to the blog post since then) was timing out. It's true that the parent comment contains no extra information at all, but that's only if you managed to open the mailing list link.
- baggy_trough 4y agoMalicious email address in what, I wonder.
- deleted 4y ago[deleted]
- captn3m0 4y agosounds like the X.509 certificate?
- LawnGnome 4y agoCertificates, which makes this pretty nasty, because it implies that there's a potential RCE if you can trigger any sort of certificate parsing remotely. (Would sending a TLS client certificate when initiating a HTTPS request do this out of the box?)
- NovemberWhiskey 4y agoOnly if the server side accepted a client certificate during the handshake, and then either that certificate had a trust path to a root CA trusted by the server OR the server was not performing trust path validation. I think it's pretty nichey.
- slt2021 4y agoI was not able to find whether openssh can be exploited with this CVE by presenting malicious client auth certificate. would be glad if someone could clarify whether openssh has this vulnerability?
- formerly_proven 4y agoOpenSSH doesn't support X.509 certificates.
- xorcist 4y ago
- baggy_trough 4y agoNow in the change log: https://www.openssl.org/news/cl30.txt https://www.openssl.org/news/cl30.txt
- NovemberWhiskey 4y ago>Doesn't sound that critical to me. I agree; and it looks like the developers have had a change of heart as this is apparently only being categorized as "high" rather than "critical" severity now.
- homarp 4y ago>Doesn't sound that critical to me. https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... has 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.
- tedunangst 4y agoThat sounds bananas. It's okay to have a little stack overflow as a treat? So for some people, this still is a critical vuln. Is there a list of people for whom this is still urgent?
- jefftk 4y ago> It's okay to have a little stack overflow as a treat? They're still doing a CVE and publishing a fix, they're just calling it HIGH and not CRITICAL (definition at https://www.openssl.org/policies/general/security-policy.html https://www.openssl.org/policies/general/security-policy.htm...). More on their categorization, from when they decided to break CRITICAL out of HIGH: https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/ https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
- deleted 4y ago[deleted]
- orra 4y agoRight!? Just because several people have been unable to exploit this stack overflow in a week, doesn't prove the flaw is not exploitable.