16 ms·

OpenSSL 3.0.7 fixes X.509 email address buffer overflows

586 points by petecooper 4y ago

deleted 4y ago
[deleted]
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 ago
  The 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 ago
    This does not seem to contain any extra information at all?
    - Sarkie 4y ago
      it has more \r\n
    - cesarb 4y ago
      For 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 ago
  Malicious email address in what, I wonder.
  - deleted 4y ago
    [deleted]
  - captn3m0 4y ago
    sounds like the X.509 certificate?
  - LawnGnome 4y ago
    Certificates, 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 ago
      Only 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 ago
        I 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 ago
        OpenSSH doesn't support X.509 certificates.
        xorcist 4y ago
- baggy_trough 4y ago
  Now 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 ago
    That 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 ago
      Right!? Just because several people have been unable to exploit this stack overflow in a week, doesn't prove the flaw is not exploitable.
petecooper 4y ago
https://archive.ph/Igu2e https://archive.ph/Igu2e
deleted 4y ago
[deleted]
MallocVoidstar 4y ago
* 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])
- deleted 4y ago
  [deleted]
cp9 4y ago
woah at least a DOS with just a malicious email address and potentially an RCE. yiiiiiikes that's bad
- tialaramex 4y ago
  From what I am reading the address needs to be in a certificate you trust. So, then the question is, who is issuing certificates some lunatic wrote nonsense into, but which you trust? In many cases the answer will be "Nobody".
  - rtev 4y ago
    Yeah, I was expecting heartbleed and this is “denial of service if you manage to sneak a malformed certificate by a CA and it makes into an attack chain”. Other than the sheer number of devices vulnerable, I don’t see this as being that big a deal.
  - thephyber 4y ago
    I would approach the issue rom the opposite direction. What is the minimum failure of any CA required for me to get popped? If some malicious actor goes through the effort to get me, how many other clients/servers on the internet can get from the same CA breach / malicious cert? How would you know to un-trust a CA you already trust until after the incident (a malicious certificate issued) had already happened? Even if the incident happened, someone still needs to alert you to un-trust the CA involved. That takes time. History of mistakes / bad decisions by cert authorities: https://sslmate.com/resources/certificate_authority_failures https://sslmate.com/resources/certificate_authority_failures > who is issuing certificates some lunatic wrote nonsense into, but which you trust Do you know every CA your OS and each browser trusts out of the box? Have you done an audit of each one of them? Does an audit 100% prevent a breach from happening in the future? What are the odds that their policies are perfectly followed every time and that no employee in the right place can be bribed/blackmailed? Remember Cert Authorities are watering holes. Almost all of the internet trusts a few of them. By breaching one (which may be very significant, either technically or reputationally), the payoff can be massive.
m_eiman 4y ago
I suppose this is the "clear your schedule and be prepared to patch the entire world" version?
- datalopers 4y ago
  OpenSSL 3.x has a fairly small install base
- input_sh 4y ago
  Lots of distros don't use v3 yet and are not affected. This is definitely far from Heartbleed level of catastrophe.
  - TheRealDunkirk 4y ago
    Feh. I just upgraded my production and staging machines to Ubuntu 22, which no longer have v1, and which breaks compiling older (but still maintained) versions of Ruby. Everything is still running, but this change caught me flatfooted. I groused about Ubuntu, and someone told me that Fedora has also changed over. You say "lots" of distro's haven't. Which ones? (And, sure, I can already assume Debian stable, since that runs 7 years behind everything else, but what else?)
    - macintux 4y ago
      This is a good overview of what’s vulnerable: https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/R...
    - deleted 4y ago
      [deleted]
    - input_sh 4y ago
      I'm oversimplifying it a bit, but anything that hasn't reached stable this year is still using v1.1.1 (and therefore unaffected). Ubuntu v22.04 is vulnerable, but any before it is not. Debian is good (except bookworm which is currently in testing), Fedora (<36) is good, RHEL/CentOS (<9), Arch... So on top of being not as serious as Heartbleed, servers that are a bit longer in operation (but still well within their support cycle) don't need patching. https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software EDIT just to add this quote from their blog post (https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o...): > 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.
tajen 4y ago
The most surprising to me is that NodeJS says they are affected https://nodejs.org/en/blog/vulnerability/openssl-november-2022/ https://nodejs.org/en/blog/vulnerability/openssl-november-20...
- tempay 4y ago
  The offical NodeJS binaries statically link to OpenSSL so they have the be patched explicitly for OpenSSL vulnerabilities.
- joecool1029 4y ago
  Might be more surprising to you that it looks like you're shadowbanned with all your comments showing up dead (last 2 were vouched). I glanced at your post history and couldn't see why so you might want to send an email to hn@ycombinator.com.
- bilalq 4y ago
  They're only affected in the sense that newer versions of Node use OpenSSL 3.x. > Node.js v18.x and v19.x use OpenSSL v3. Therefore these release lines are impacted by this update. > Node.js 14.x and v16.x are not affected by this OpenSSL update. > At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users. > After assessing the impact on Node.js, it will be decided whether the issues fixed require immediate security releases of Node.js, or whether they can be included in the normally scheduled updates.
- fulafel 4y ago
  I wonder if they are built with stack protector turned on in the compiler flags.
miduil 4y ago
Diff of 3.0.6 and 3.0.7: https://gist.github.com/FiloSottile/611fc3fa95c3aceebf2580983f76148c https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098... via https://www.twitch.tv/filosottile https://www.twitch.tv/filosottile
- formerly_proven 4y ago
  Specifically https://gist.github.com/FiloSottile/611fc3fa95c3aceebf2580983f76148c#file-openssl-3-0-6-to-3-0-7-diff-L493 https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098... - if (written_out > max_out) + if (written_out >= max_out) return 0; Plus a second, less memeable fix.
  - jeffbee 4y ago
    - hedora 4y ago
      I don't think it is fair to blame the language for this. Look at the lines above the vulnerability: n = n + i / (written_out + 1); i %= (written_out + 1); Whatever buffer manipulation this is doing could be abstracted out into a library. (As studio.h does.) Also, since written_out probably varies from loop iteration to iteration, what does "n remainder i" even mean? Also, why don't they increment written_out before doing the arithmetic, and why do they increment i on line 523, when the only intermediate use of it is "i + 1"? I've written some crappy code in my time, but when things descended into that level of insanity, I either delegated to fuzz tested functions, or at least left a comment.
    - Hackbraten 4y ago
      You’re not wrong. Back in the day, you didn’t have alternatives with zero-cost abstractions like we have today. There are many valid reasons why one would make decisions to balance performance against memory-safety, especially 25 years ago – and given the fact that networking code tends to be part of hot paths where optimization matters.
    - 4y ago
petecooper 4y ago
[deleted]
- pvg 4y ago
  It's really better to just wait for the thing you want to be posted to actually appear on the web instead of using 'placeholders' or announcements with incomplete info. For HN purposes, at least, it's ok to wait since it's not a news ticker despite the word in the name.
  - petecooper 4y ago
    You're right. I'll delete it.
    - pvg 4y ago
      Would have been better to wait for something like the thing linked here https://news.ycombinator.com/item?id=33423271 https://news.ycombinator.com/item?id=33423271 for the submission in general Otherwise moderators have to run around cleaning stuff up, fixing titles, merging threads, posting notes about comments that make less sense due to merge, etc. Sorry this sounds so beratey, just worth keeping in mind next time.
      - petecooper 4y ago
        You're absolutely right. And I didn't take it as beratey, no drama.
- deleted 4y ago
  [deleted]
8K832d7tNmiQ 4y ago
When will this package got updated on GCP? Currently on Ubuntu 22.04 and we're still on 3.0.2 .
- baggy_trough 4y ago
  Last time we went through this (Heartbleed, I think) it took several hours.
- jacooper 4y ago
  Its going to be backport, so its going to be a fixed 3.0.2 not 3.0.7.
- Thaxll 4y ago
  https://ubuntu.com/security/CVE-2022-3786 https://ubuntu.com/security/CVE-2022-3786
nequo 4y ago
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. Does anyone know when Ubuntu might ship the fix?
- baggy_trough 4y ago
  I would expect there should be a patch sometime today, but maybe not for a few hours based on prior experience.
- _joel 4y ago
  Also be aware sometimes fixes are backported, so the version isn't 100% accurate, ymmv etc.
  - schlauerfox 4y ago
    Yes, it gets real confusing because they keep the major version the shipped with but usually add a letter or something to indicate the fix was backported to the older version without upgrading to a newer version number to prevent dependency issues. This got a heated debate on a project I was part of when a community member misunderstood this mechanism.
    - bityard 4y ago
      I _still_ have to go through this every time a clipboard warrior thinks they need to do a "security audit" in order to check a box for some meaningless certification or another. But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. And then I have to explain that their scanners are broken by virtue of using a cheap-to-get value (the version number) as a totally inadequate proxy for something else (exposure to a vulnerability) when the two have only a weak to no actual correlation in real life. And then they shut up. Until the next audit comes around...
lawgimenez 4y ago
This might be relevant: https://www.malwaretech.com/2022/11/everything-you-need-to-know-about-the-openssl-3-0-7-patch.html https://www.malwaretech.com/2022/11/everything-you-need-to-k...
tempay 4y ago
Apparently the "Critical" vulnerability has been downgraded to "High" since the annoucement: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
- ollien 4y ago
  Huh. I wonder why they decided to walk it back _after_ disclosure.
  - gjasny 4y ago
    This is answered in their blog entry: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... 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.
- deleted 4y ago
  [deleted]
baggy_trough 4y ago
OpenSSL blog post: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... Q: Are all applications using OpenSSL 3.0 vulnerable by default? 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. Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.
- NovemberWhiskey 4y ago
  Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. Paraphrasing... A: if you depend on mutual TLS; no.
  - couchand 4y ago
    Well, it also seems to require that you completely ignore the trust chain? Am I reading that right? > 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.
    - NovemberWhiskey 4y ago
      The point is the vulnerable code will execute any time a trusted certificate is being validated. If you have a service that depends on mTLS, then your service is (by definition) validating client certificates so you can't mitigate your exposure. There is a separable question of whether your service trusts certificates issued by a CA that might produce a certificate with a SAN of the necessary form to trigger the exploit.
      - couchand 4y ago
dochtman 4y ago
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. rustls has C bindings these days: https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi 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 (https://github.com/sponsors/djc https://github.com/sponsors/djc). 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.
- anonym29 4y ago
  Where's the language spec? The reference is nice but it's not a formal specification. So much undefined behavior - more than C! /s Edited to reflect sarcasm as rustaceans apparently can't infer it.
  - dochtman 4y ago
    In my understanding it would be hard to make the case that Rust actually has more undefined behavior than C -- most kinds of undefined behavior in C have been carefully avoided in Rust, although, yes, there is no piece of paper ratified by a bunch of national technology institutes that describes Rust. See also this recent blog post: https://blog.m-ou.se/rust-standard/ https://blog.m-ou.se/rust-standard/
    - anonym29 4y ago
      While the rust community might not believe their language needs a specification, some of their would-be customers have business requirements surrounding a specification that cannot be fulfilled with a reference. edit: clarity
      - dochtman 4y ago
wanto230 4y ago
[flagged]
hedora 4y ago
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. 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. 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. I can't find a reference anywhere. Does anyone know what I'm (mis)remembering?
- codys 4y ago
  There is this on IPSEC: https://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html https://www.mail-archive.com/cryptography@metzdowd.com/msg12...
- deleted 4y ago
  [deleted]
- _jal 4y ago
  Could be most any of this activity: https://blog.cryptographyengineering.com/2013/09/06/on-nsa/ https://blog.cryptographyengineering.com/2013/09/06/on-nsa/
- mkj 4y ago
  There's some more discussion of ipsec in the thread https://www.metzdowd.com/pipermail/cryptography/2020-July/036077.html https://www.metzdowd.com/pipermail/cryptography/2020-July/03... I'd be interested to see references to SSL too (from a historical perspective)
grepLeigh 4y ago
Hugops to anyone patching today. I'm currently rolling over-the-air updates to a fleet of hundreds of Raspberry Pis distributed around the world.
SoftTalker 4y ago
I noticed that LibreSSL posted a patch release (3.6.1) does anyone know if this addresses similar issues? 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
- NovemberWhiskey 4y ago
  No, these fixes look unrelated.
- iio7 4y ago
  LibreSSL is not affected by this. It was forked before this vulnerability was introduced into OpenSSL, i.e. it's a new bug.
  - nailer 4y ago
    Libre should delete the code that support X509 email addresses.
Faelian2 4y ago
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.
- deleted 4y ago
  [deleted]
- pjmlp 4y ago
  Not every systems has the necessary mitigations enabled.
mroche 4y ago
Red Hat vulnerability page with a system detection script: https://access.redhat.com/security/vulnerabilities/RHSB-2022-004 https://access.redhat.com/security/vulnerabilities/RHSB-2022...
- linsomniac 4y ago
  FYI: This detection script only runs on RHEL (and presumably variants?), it does a "rpm" and looks for specific packages, not scanning the system looking for the vulnerability.
  - mroche 4y ago
    Yes, this is a tool for users of RHEL systems to know whether or not they have a vulnerable version of OpenSSL on their systems. It's not a general PoC detection script.
- elric 4y ago
  Seems like RHEL/Centos/Rocky < 9 aren't affected (OpenSSL is too old to be vulnerable ... makes a change). Not seeing any OpenSSL updates on any of my Rocky 9 boxen just yet.
petecooper 4y ago
>Q: Is this a branded vulnerability? >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. "I survived CVE-2022-3786 & CVE-2022-3602 and all I got was this crappy t-shirt."
- deleted 4y ago
  [deleted]
l1n 4y ago
Sounds like this is mostly caught by stack overflow protections. From the release blog: 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.
- deleted 4y ago
  [deleted]
blueflow 4y ago
> Q: Is this a branded vulnerability? > 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. I chuckled a bit, but im also sad that we ended up in this situation. The obsession with brands is, to some extent, unhealthy.
- deleted 4y ago
  [deleted]
- nequo 4y ago
  It probably serves them better that they haven't. It'd turn it into a meme like Heartbleed that would not be forgotten for the next decade.
  - userbinator 4y ago
    This is nowhere near as severe as Heartbleed. That's why it's not considered Critical (and also why it hasn't been given a special name.)
- dom96 4y ago
  Maybe we should set up a naming system just like for COVID variants
- tptacek 4y ago
  No, it's not. Branded vulnerabilities are memorable. CVE numbers aren't.
  - ASalazarMX 4y ago
    It's not a real critical vulnerability unless it has a marketable name and a its own website. Technical names are boring. While it's cool to talk about heartbleed and people knowing what it was (it even had its own XKCD comic), I fear this marketing trend is detrimental because it's not really aimed at the people who apply the patches/mitigations.
  - _jal 4y ago
nurettin 4y ago
This vulnerability could actually be weponized against botnets that utilize older ssh clients.
- fulafel 4y ago
  OpenSSH doesn't use X.509 certs.
macintux 4y ago
Affected (and unaffected) software tracking page shared earlier today: https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/R...
- Kwpolska 4y ago
  (“Affected” defined as “uses OpenSSL 3.x”, not “can be exploited”)
gnfargbl 4y ago
No RCE on Ubuntu: Ubuntu packages are built with stack protector, reducing the impact of this CVE from remote code execution to a denial of service. -- https://ubuntu.com/security/CVE-2022-3602 https://ubuntu.com/security/CVE-2022-3602
- mkeedlinger 4y ago
  Anywhere I can learn more about what stack protection they have?
  - slt2021 4y ago
    https://lwn.net/Articles/584225/ https://lwn.net/Articles/584225/
    - mkeedlinger 4y ago
      Very interesting, thank you
  - 0xbadcafebee 4y ago
    https://wiki.ubuntu.com/Security/Features https://wiki.ubuntu.com/Security/Features - particularly the stack protector, heap protector, ASLR, PIE, stack clash protection, NX bit, kernel stack protector, kernel ASLR.
- deleted 4y ago
  [deleted]
- AtNightWeCode 4y ago
  That is a very clever feature. Cheap insurance.
pclmulqdq 4y ago
- deleted 4y ago
  [deleted]
- pjmlp 4y ago
  The DoJ security assessment about Multics refers to PL/I bounds checking capabilities as why it got a better evaluation mark than UNIX....
- botplaysdice 4y ago
  quick question, I didn't look into the detail of the issue and novice on Rust as well - question is to whom already checked detail of the vulnerability, is this bug kind of ones we can prevent if we're using Rust instead of C?
  - formerly_proven 4y ago
    Bog standard buffer overflow caused by incorrect bounds checking. Yes.
    - nequo 4y ago
      Indeed. For illustration, the Ubuntu commits that fix the two CVEs: https://git.launchpad.net/ubuntu/+source/openssl/commit/?h=applied/ubuntu/jammy-security&id=d6ccc4dfd3b75fa0323c9f49303f9d1610923036 https://git.launchpad.net/ubuntu/+source/openssl/commit/?h=a... - if (written_out > max_out) + if (written_out >= max_out) [...] https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=293ec060164a1f4cbf7a881165c923bbd9428229 https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=... - if (tmpptr != NULL) - PUSHC('.'); + PUSHC(tmpptr != NULL ? '.' : '\0'); - char a_ulabel[LABEL_BUF_SIZE]; + char a_ulabel[LABEL_BUF_SIZE + 1]; https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=3b0e1a39a7086f9fcfe9156f4a6d481953ec0af4 https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=... - || type->origin == EVP_ORIG_METH) { + || (type != NULL && type->origin == EVP_ORIG_METH) + || (type == NULL && ctx->digest != NULL + && ctx->digest->origin == EVP_ORIG_METH)) { - || impl != NULL) { + || impl != NULL + || (cipher != NULL && cipher->origin == EVP_ORIG_METH) + || (cipher == NULL && ctx->cipher != NULL + && ctx->cipher->origin == EVP_ORIG_METH)) {
seedless-sensat 4y ago
I liked this write up: https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/#exploitation-technical-details https://securitylabs.datadoghq.com/articles/openssl-november...
marcinguy 4y ago
[dead]
- hulitu 4y ago
  RCE.
- adamckay 4y ago
  There's a certain poetic irony in my opinion that to investigate whether you're vulnerable to a possible RCE CVE, you can curl directly into a shell.
  - brazzledazzle 4y ago
    Yeah that gave me pause.
psanford 4y ago
Colm MacCárthaigh has a nice writeup on CVE−2022-3602 including steps to reproduce: https://github.com/colmmacc/CVE-2022-3602 https://github.com/colmmacc/CVE-2022-3602
secondcoming 4y ago
> the bugs were introduced as part of punycode decoding functionality Did they handroll their own decoder, or did they use the reference code [0] in the RFC? [0] https://www.rfc-editor.org/rfc/rfc3492#page-23 https://www.rfc-editor.org/rfc/rfc3492#page-23
dang 4y ago
Url changed from https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html https://mta.openssl.org/pipermail/openssl-announce/2022-Nove... to a post with more background. (via https://news.ycombinator.com/item?id=33423271 https://news.ycombinator.com/item?id=33423271, but we merged that thread hither)
Arcuru 4y ago
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. Shouldn't fuzzing have caught this at some point? I was under the impression that OpenSSL was being fuzz tested constantly since Heartbleed. [1] https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o...
- userbinator 4y ago
  Shouldn't fuzzing have caught this at some point? Eventually, yes. Unfortunately, fuzzing is usually nondeterministic/pseudorandom so it won't necessarily go down the path that leads to the bug soon enough.
- bink 4y ago
  It sounds like the fuzzer would have had to use an arbitrary number of bytes containing '.' and the cert would've had to pass chain of trust verification. A fuzzer is only as strong as its implementation.
  - contravariant 4y ago
    I hope they're not just fuzzing random bytes, in theory that would take forever to trigger any code other than just rejecting the certificate.
    - whizzter 4y ago
      Iirc fuzzers would add randomness and measure occurences of newly entered codepaths and build out from previous randomness to reach more codepaths. However as you noted, in this case the cryptographic verification code would in practice always be hit before any sany progress could be done in fuzzing any deeper. To catch this they would've needed to make a specific fuzzing setup where the process prepared random certificates that are THEN signed and passed further and make the fuzzer short-circuit anything where the random cerificate failed the signing to actually test verification.
stabbles 4y ago
If you are tired of the frequency of CVEs in OpenSSL, consider sending a formal complaint to maintainers@openssl.org\0hunter2
- deleted 4y ago
  [deleted]
- snvzz 4y ago
  It'd be more productive to switch to libressl or bearssl.
billpg 4y ago
Exactly how panicked should I be right now?
- INTPenis 4y ago
  Extremely
  - marginalia_nu 4y ago
    You should rarely be extremely panicked. It's not a very useful state of mind.
- Sirened 4y ago
  Not terribly; not only is it a hard path to hit (you need the malicious certificate to be issued by a trusted CA) and you have to figure out how to turn a very constrained 4 byte stack buffer overflow into something more powerful. Compiler engineers have been well aware of stack buffer overflows for a long time and so a lot of modern compilers do cheeky things to mitigate these sorts of overflows, ranging from placing these buffers at the bottom of the frame (so a linear overflow doesn't hit anything) to stuff like stack cookies protecting the return address from linear, blind overflows. This isn't to say it's impossible to exploit (as the linked post shows) given some lucky compiler decisions on where other things are placed, but as it stands it's unlikely to be useable as is.
awinter-py 4y ago
woof sympathy to everyone else who joined both the openssl exploit + the rust bound checking stan drinking game for november rough afternoon ahead
aborsy 4y ago
There are probably many such vulnerabilities in this giant code base, being exploited by those who have resources to find them. If OpenSSL is written in Rust, to what extent will the vulnerabilities be reduced (assuming that Rust is supported by the host, of course)?
- nequo 4y ago
  rustls can serve as an alternative.[1] Dirkjan Ochtman, one of the main contributors, wrote about it in this thread.[2] [1] https://github.com/rustls/rustls https://github.com/rustls/rustls [2] https://news.ycombinator.com/item?id=33423296 https://news.ycombinator.com/item?id=33423296
ComputerGuru 4y ago
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: > This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected. > 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.
- TillE 4y ago
  I wish I'd continued using a scripted build of OpenSSL 1.1.x on all platforms instead of switching to vcpkg OpenSSL 3.0.x on newer platforms. There's been a lot of drama for no particular gain in our use case.
- NavinF 4y ago
  If anyone's wondering why OpenSSL skipped 2.0.0, see https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/
baby 4y ago
https://twitter.com/cryptodavidw/status/1587505925731934208 https://twitter.com/cryptodavidw/status/1587505925731934208' > 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 (https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...)
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
29athrowaway 4y ago
Breaking news: software written in a language with error prone memory management has another security incident related to memory management. 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. 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. But hey, don't get distracted by automated memory management solutions, we are too busy fixing memory management problems manually.
- necovek 4y ago
  I am sure your OpenSSL-like library in Rust with support for using from all other programming languages is coming out any day now?
  - 29athrowaway 4y ago
    Make fun all you want, bro. The days of juggling chainsaws are coming to an end. The NSA is crying.
  - steveklabnik 4y ago
    No need to wait, at least for TLS https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi
    - necovek 4y ago
      Thanks, that's honestly very nice! I look forward to hearing about it as it becomes more widely used!
- macintux 4y ago
  Yet every time C comes up in a discussion here, someone will insist that it’s fine, that only bad programmers make mistakes. I don’t know Rust, and I love C, but we’re well past the point where one can reasonably argue that careful use of C is good enough.
entropicgravity 4y ago
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?
herpderperator 4y ago
> 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. https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b9feb3812bdc7781c784332 https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b... A one character change.

586 points by petecooper 4y ago

deleted 4y ago

[deleted]

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 ago
The 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 ago
  This does not seem to contain any extra information at all?
  - Sarkie 4y ago
    it has more \r\n
  - cesarb 4y ago
    For 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 ago
Malicious email address in what, I wonder.
- deleted 4y ago
  [deleted]
- captn3m0 4y ago
  sounds like the X.509 certificate?
- LawnGnome 4y ago
  Certificates, 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 ago
    Only 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 ago
      I 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 ago
        OpenSSH doesn't support X.509 certificates.
        xorcist 4y ago
baggy_trough 4y ago
Now 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 ago
  That 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 ago
    Right!? Just because several people have been unable to exploit this stack overflow in a week, doesn't prove the flaw is not exploitable.

petecooper 4y ago

https://archive.ph/Igu2e https://archive.ph/Igu2e

deleted 4y ago

[deleted]

MallocVoidstar 4y ago

* 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])

deleted 4y ago
[deleted]

cp9 4y ago

woah at least a DOS with just a malicious email address and potentially an RCE. yiiiiiikes that's bad

tialaramex 4y ago
From what I am reading the address needs to be in a certificate you trust. So, then the question is, who is issuing certificates some lunatic wrote nonsense into, but which you trust? In many cases the answer will be "Nobody".
- rtev 4y ago
  Yeah, I was expecting heartbleed and this is “denial of service if you manage to sneak a malformed certificate by a CA and it makes into an attack chain”. Other than the sheer number of devices vulnerable, I don’t see this as being that big a deal.
- thephyber 4y ago
  I would approach the issue rom the opposite direction. What is the minimum failure of any CA required for me to get popped? If some malicious actor goes through the effort to get me, how many other clients/servers on the internet can get from the same CA breach / malicious cert? How would you know to un-trust a CA you already trust until after the incident (a malicious certificate issued) had already happened? Even if the incident happened, someone still needs to alert you to un-trust the CA involved. That takes time. History of mistakes / bad decisions by cert authorities: https://sslmate.com/resources/certificate_authority_failures https://sslmate.com/resources/certificate_authority_failures > who is issuing certificates some lunatic wrote nonsense into, but which you trust Do you know every CA your OS and each browser trusts out of the box? Have you done an audit of each one of them? Does an audit 100% prevent a breach from happening in the future? What are the odds that their policies are perfectly followed every time and that no employee in the right place can be bribed/blackmailed? Remember Cert Authorities are watering holes. Almost all of the internet trusts a few of them. By breaching one (which may be very significant, either technically or reputationally), the payoff can be massive.

m_eiman 4y ago

I suppose this is the "clear your schedule and be prepared to patch the entire world" version?

datalopers 4y ago
OpenSSL 3.x has a fairly small install base
input_sh 4y ago
Lots of distros don't use v3 yet and are not affected. This is definitely far from Heartbleed level of catastrophe.
- TheRealDunkirk 4y ago
  Feh. I just upgraded my production and staging machines to Ubuntu 22, which no longer have v1, and which breaks compiling older (but still maintained) versions of Ruby. Everything is still running, but this change caught me flatfooted. I groused about Ubuntu, and someone told me that Fedora has also changed over. You say "lots" of distro's haven't. Which ones? (And, sure, I can already assume Debian stable, since that runs 7 years behind everything else, but what else?)
  - macintux 4y ago
    This is a good overview of what’s vulnerable: https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/R...
  - deleted 4y ago
    [deleted]
  - input_sh 4y ago
    I'm oversimplifying it a bit, but anything that hasn't reached stable this year is still using v1.1.1 (and therefore unaffected). Ubuntu v22.04 is vulnerable, but any before it is not. Debian is good (except bookworm which is currently in testing), Fedora (<36) is good, RHEL/CentOS (<9), Arch... So on top of being not as serious as Heartbleed, servers that are a bit longer in operation (but still well within their support cycle) don't need patching. https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software EDIT just to add this quote from their blog post (https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o...): > 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.

tajen 4y ago

The most surprising to me is that NodeJS says they are affected https://nodejs.org/en/blog/vulnerability/openssl-november-2022/ https://nodejs.org/en/blog/vulnerability/openssl-november-20...

tempay 4y ago
The offical NodeJS binaries statically link to OpenSSL so they have the be patched explicitly for OpenSSL vulnerabilities.
joecool1029 4y ago
Might be more surprising to you that it looks like you're shadowbanned with all your comments showing up dead (last 2 were vouched). I glanced at your post history and couldn't see why so you might want to send an email to hn@ycombinator.com.
bilalq 4y ago
They're only affected in the sense that newer versions of Node use OpenSSL 3.x. > Node.js v18.x and v19.x use OpenSSL v3. Therefore these release lines are impacted by this update. > Node.js 14.x and v16.x are not affected by this OpenSSL update. > At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users. > After assessing the impact on Node.js, it will be decided whether the issues fixed require immediate security releases of Node.js, or whether they can be included in the normally scheduled updates.
fulafel 4y ago
I wonder if they are built with stack protector turned on in the compiler flags.

miduil 4y ago

Diff of 3.0.6 and 3.0.7: https://gist.github.com/FiloSottile/611fc3fa95c3aceebf2580983f76148c https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098... via https://www.twitch.tv/filosottile https://www.twitch.tv/filosottile

formerly_proven 4y ago
Specifically https://gist.github.com/FiloSottile/611fc3fa95c3aceebf2580983f76148c#file-openssl-3-0-6-to-3-0-7-diff-L493 https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098... - if (written_out > max_out) + if (written_out >= max_out) return 0; Plus a second, less memeable fix.
- jeffbee 4y ago
  - hedora 4y ago
    I don't think it is fair to blame the language for this. Look at the lines above the vulnerability: n = n + i / (written_out + 1); i %= (written_out + 1); Whatever buffer manipulation this is doing could be abstracted out into a library. (As studio.h does.) Also, since written_out probably varies from loop iteration to iteration, what does "n remainder i" even mean? Also, why don't they increment written_out before doing the arithmetic, and why do they increment i on line 523, when the only intermediate use of it is "i + 1"? I've written some crappy code in my time, but when things descended into that level of insanity, I either delegated to fuzz tested functions, or at least left a comment.
  - Hackbraten 4y ago
    You’re not wrong. Back in the day, you didn’t have alternatives with zero-cost abstractions like we have today. There are many valid reasons why one would make decisions to balance performance against memory-safety, especially 25 years ago – and given the fact that networking code tends to be part of hot paths where optimization matters.
  - 4y ago

petecooper 4y ago

[deleted]

pvg 4y ago
It's really better to just wait for the thing you want to be posted to actually appear on the web instead of using 'placeholders' or announcements with incomplete info. For HN purposes, at least, it's ok to wait since it's not a news ticker despite the word in the name.
- petecooper 4y ago
  You're right. I'll delete it.
  - pvg 4y ago
    Would have been better to wait for something like the thing linked here https://news.ycombinator.com/item?id=33423271 https://news.ycombinator.com/item?id=33423271 for the submission in general Otherwise moderators have to run around cleaning stuff up, fixing titles, merging threads, posting notes about comments that make less sense due to merge, etc. Sorry this sounds so beratey, just worth keeping in mind next time.
    - petecooper 4y ago
      You're absolutely right. And I didn't take it as beratey, no drama.
deleted 4y ago
[deleted]

8K832d7tNmiQ 4y ago

When will this package got updated on GCP? Currently on Ubuntu 22.04 and we're still on 3.0.2 .

baggy_trough 4y ago
Last time we went through this (Heartbleed, I think) it took several hours.
jacooper 4y ago
Its going to be backport, so its going to be a fixed 3.0.2 not 3.0.7.
Thaxll 4y ago
https://ubuntu.com/security/CVE-2022-3786 https://ubuntu.com/security/CVE-2022-3786

nequo 4y ago

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. Does anyone know when Ubuntu might ship the fix?

baggy_trough 4y ago
I would expect there should be a patch sometime today, but maybe not for a few hours based on prior experience.
_joel 4y ago
Also be aware sometimes fixes are backported, so the version isn't 100% accurate, ymmv etc.
- schlauerfox 4y ago
  Yes, it gets real confusing because they keep the major version the shipped with but usually add a letter or something to indicate the fix was backported to the older version without upgrading to a newer version number to prevent dependency issues. This got a heated debate on a project I was part of when a community member misunderstood this mechanism.
  - bityard 4y ago
    I _still_ have to go through this every time a clipboard warrior thinks they need to do a "security audit" in order to check a box for some meaningless certification or another. But of course THEY don't want to run the audit (sounds too much like work!) so they contract the audit out to a third-party that builds a database saying which versions of various software are vulnerable according to these CVEs. Of those, these contractors don't actually understand how Linux distributions are put together and their scanners _always_ flag fully patched and up-to-date machines as being vulnerable to X, Y, and Z. And then I have to explain that their scanners are broken by virtue of using a cheap-to-get value (the version number) as a totally inadequate proxy for something else (exposure to a vulnerability) when the two have only a weak to no actual correlation in real life. And then they shut up. Until the next audit comes around...

lawgimenez 4y ago

This might be relevant: https://www.malwaretech.com/2022/11/everything-you-need-to-know-about-the-openssl-3-0-7-patch.html https://www.malwaretech.com/2022/11/everything-you-need-to-k...

tempay 4y ago

Apparently the "Critical" vulnerability has been downgraded to "High" since the annoucement: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html

ollien 4y ago
Huh. I wonder why they decided to walk it back _after_ disclosure.
- gjasny 4y ago
  This is answered in their blog entry: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... 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.
deleted 4y ago
[deleted]

baggy_trough 4y ago

OpenSSL blog post: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... Q: Are all applications using OpenSSL 3.0 vulnerable by default? 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. Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.

NovemberWhiskey 4y ago
Q: Are there any mitigations until I can upgrade? A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. Paraphrasing... A: if you depend on mutual TLS; no.
- couchand 4y ago
  Well, it also seems to require that you completely ignore the trust chain? Am I reading that right? > 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.
  - NovemberWhiskey 4y ago
    The point is the vulnerable code will execute any time a trusted certificate is being validated. If you have a service that depends on mTLS, then your service is (by definition) validating client certificates so you can't mitigate your exposure. There is a separable question of whether your service trusts certificates issued by a CA that might produce a certificate with a SAN of the necessary form to trigger the exploit.
    - couchand 4y ago

dochtman 4y ago

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. rustls has C bindings these days: https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi 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 (https://github.com/sponsors/djc https://github.com/sponsors/djc). 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.

anonym29 4y ago
Where's the language spec? The reference is nice but it's not a formal specification. So much undefined behavior - more than C! /s Edited to reflect sarcasm as rustaceans apparently can't infer it.
- dochtman 4y ago
  In my understanding it would be hard to make the case that Rust actually has more undefined behavior than C -- most kinds of undefined behavior in C have been carefully avoided in Rust, although, yes, there is no piece of paper ratified by a bunch of national technology institutes that describes Rust. See also this recent blog post: https://blog.m-ou.se/rust-standard/ https://blog.m-ou.se/rust-standard/
  - anonym29 4y ago
    While the rust community might not believe their language needs a specification, some of their would-be customers have business requirements surrounding a specification that cannot be fulfilled with a reference. edit: clarity
    - dochtman 4y ago

wanto230 4y ago

[flagged]

hedora 4y ago

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. 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. 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. I can't find a reference anywhere. Does anyone know what I'm (mis)remembering?

codys 4y ago
There is this on IPSEC: https://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html https://www.mail-archive.com/cryptography@metzdowd.com/msg12...
deleted 4y ago
[deleted]
_jal 4y ago
Could be most any of this activity: https://blog.cryptographyengineering.com/2013/09/06/on-nsa/ https://blog.cryptographyengineering.com/2013/09/06/on-nsa/
mkj 4y ago
There's some more discussion of ipsec in the thread https://www.metzdowd.com/pipermail/cryptography/2020-July/036077.html https://www.metzdowd.com/pipermail/cryptography/2020-July/03... I'd be interested to see references to SSL too (from a historical perspective)

grepLeigh 4y ago

Hugops to anyone patching today. I'm currently rolling over-the-air updates to a fleet of hundreds of Raspberry Pis distributed around the world.

SoftTalker 4y ago

I noticed that LibreSSL posted a patch release (3.6.1) does anyone know if this addresses similar issues? 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

NovemberWhiskey 4y ago
No, these fixes look unrelated.
iio7 4y ago
LibreSSL is not affected by this. It was forked before this vulnerability was introduced into OpenSSL, i.e. it's a new bug.
- nailer 4y ago
  Libre should delete the code that support X509 email addresses.

Faelian2 4y ago

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.

deleted 4y ago
[deleted]
pjmlp 4y ago
Not every systems has the necessary mitigations enabled.

mroche 4y ago

Red Hat vulnerability page with a system detection script: https://access.redhat.com/security/vulnerabilities/RHSB-2022-004 https://access.redhat.com/security/vulnerabilities/RHSB-2022...

linsomniac 4y ago
FYI: This detection script only runs on RHEL (and presumably variants?), it does a "rpm" and looks for specific packages, not scanning the system looking for the vulnerability.
- mroche 4y ago
  Yes, this is a tool for users of RHEL systems to know whether or not they have a vulnerable version of OpenSSL on their systems. It's not a general PoC detection script.
elric 4y ago
Seems like RHEL/Centos/Rocky < 9 aren't affected (OpenSSL is too old to be vulnerable ... makes a change). Not seeing any OpenSSL updates on any of my Rocky 9 boxen just yet.

petecooper 4y ago

>Q: Is this a branded vulnerability? >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. "I survived CVE-2022-3786 & CVE-2022-3602 and all I got was this crappy t-shirt."

deleted 4y ago
[deleted]

l1n 4y ago

Sounds like this is mostly caught by stack overflow protections. From the release blog: 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.

deleted 4y ago
[deleted]

blueflow 4y ago

> Q: Is this a branded vulnerability? > 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. I chuckled a bit, but im also sad that we ended up in this situation. The obsession with brands is, to some extent, unhealthy.

deleted 4y ago
[deleted]
nequo 4y ago
It probably serves them better that they haven't. It'd turn it into a meme like Heartbleed that would not be forgotten for the next decade.
- userbinator 4y ago
  This is nowhere near as severe as Heartbleed. That's why it's not considered Critical (and also why it hasn't been given a special name.)
dom96 4y ago
Maybe we should set up a naming system just like for COVID variants
tptacek 4y ago
No, it's not. Branded vulnerabilities are memorable. CVE numbers aren't.
- ASalazarMX 4y ago
  It's not a real critical vulnerability unless it has a marketable name and a its own website. Technical names are boring. While it's cool to talk about heartbleed and people knowing what it was (it even had its own XKCD comic), I fear this marketing trend is detrimental because it's not really aimed at the people who apply the patches/mitigations.
- _jal 4y ago

nurettin 4y ago

This vulnerability could actually be weponized against botnets that utilize older ssh clients.

fulafel 4y ago
OpenSSH doesn't use X.509 certs.

macintux 4y ago

Affected (and unaffected) software tracking page shared earlier today: https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/R...

Kwpolska 4y ago
(“Affected” defined as “uses OpenSSL 3.x”, not “can be exploited”)

gnfargbl 4y ago

No RCE on Ubuntu: Ubuntu packages are built with stack protector, reducing the impact of this CVE from remote code execution to a denial of service. -- https://ubuntu.com/security/CVE-2022-3602 https://ubuntu.com/security/CVE-2022-3602

mkeedlinger 4y ago
Anywhere I can learn more about what stack protection they have?
- slt2021 4y ago
  https://lwn.net/Articles/584225/ https://lwn.net/Articles/584225/
  - mkeedlinger 4y ago
    Very interesting, thank you
- 0xbadcafebee 4y ago
  https://wiki.ubuntu.com/Security/Features https://wiki.ubuntu.com/Security/Features - particularly the stack protector, heap protector, ASLR, PIE, stack clash protection, NX bit, kernel stack protector, kernel ASLR.
deleted 4y ago
[deleted]
AtNightWeCode 4y ago
That is a very clever feature. Cheap insurance.

pclmulqdq 4y ago

deleted 4y ago
[deleted]
pjmlp 4y ago
The DoJ security assessment about Multics refers to PL/I bounds checking capabilities as why it got a better evaluation mark than UNIX....
botplaysdice 4y ago
quick question, I didn't look into the detail of the issue and novice on Rust as well - question is to whom already checked detail of the vulnerability, is this bug kind of ones we can prevent if we're using Rust instead of C?
- formerly_proven 4y ago
  Bog standard buffer overflow caused by incorrect bounds checking. Yes.
  - nequo 4y ago
    Indeed. For illustration, the Ubuntu commits that fix the two CVEs: https://git.launchpad.net/ubuntu/+source/openssl/commit/?h=applied/ubuntu/jammy-security&id=d6ccc4dfd3b75fa0323c9f49303f9d1610923036 https://git.launchpad.net/ubuntu/+source/openssl/commit/?h=a... - if (written_out > max_out) + if (written_out >= max_out) [...] https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=293ec060164a1f4cbf7a881165c923bbd9428229 https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=... - if (tmpptr != NULL) - PUSHC('.'); + PUSHC(tmpptr != NULL ? '.' : '\0'); - char a_ulabel[LABEL_BUF_SIZE]; + char a_ulabel[LABEL_BUF_SIZE + 1]; https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=3b0e1a39a7086f9fcfe9156f4a6d481953ec0af4 https://git.launchpad.net/ubuntu/+source/openssl/commit/?id=... - || type->origin == EVP_ORIG_METH) { + || (type != NULL && type->origin == EVP_ORIG_METH) + || (type == NULL && ctx->digest != NULL + && ctx->digest->origin == EVP_ORIG_METH)) { - || impl != NULL) { + || impl != NULL + || (cipher != NULL && cipher->origin == EVP_ORIG_METH) + || (cipher == NULL && ctx->cipher != NULL + && ctx->cipher->origin == EVP_ORIG_METH)) {

seedless-sensat 4y ago

I liked this write up: https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/#exploitation-technical-details https://securitylabs.datadoghq.com/articles/openssl-november...

marcinguy 4y ago

[dead]

hulitu 4y ago
RCE.
adamckay 4y ago
There's a certain poetic irony in my opinion that to investigate whether you're vulnerable to a possible RCE CVE, you can curl directly into a shell.
- brazzledazzle 4y ago
  Yeah that gave me pause.

psanford 4y ago

Colm MacCárthaigh has a nice writeup on CVE−2022-3602 including steps to reproduce: https://github.com/colmmacc/CVE-2022-3602 https://github.com/colmmacc/CVE-2022-3602

secondcoming 4y ago

> the bugs were introduced as part of punycode decoding functionality Did they handroll their own decoder, or did they use the reference code [0] in the RFC? [0] https://www.rfc-editor.org/rfc/rfc3492#page-23 https://www.rfc-editor.org/rfc/rfc3492#page-23

dang 4y ago

Url changed from https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html https://mta.openssl.org/pipermail/openssl-announce/2022-Nove... to a post with more background. (via https://news.ycombinator.com/item?id=33423271 https://news.ycombinator.com/item?id=33423271, but we merged that thread hither)

Arcuru 4y ago

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. Shouldn't fuzzing have caught this at some point? I was under the impression that OpenSSL was being fuzz tested constantly since Heartbleed. [1] https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o...

userbinator 4y ago
Shouldn't fuzzing have caught this at some point? Eventually, yes. Unfortunately, fuzzing is usually nondeterministic/pseudorandom so it won't necessarily go down the path that leads to the bug soon enough.
bink 4y ago
It sounds like the fuzzer would have had to use an arbitrary number of bytes containing '.' and the cert would've had to pass chain of trust verification. A fuzzer is only as strong as its implementation.
- contravariant 4y ago
  I hope they're not just fuzzing random bytes, in theory that would take forever to trigger any code other than just rejecting the certificate.
  - whizzter 4y ago
    Iirc fuzzers would add randomness and measure occurences of newly entered codepaths and build out from previous randomness to reach more codepaths. However as you noted, in this case the cryptographic verification code would in practice always be hit before any sany progress could be done in fuzzing any deeper. To catch this they would've needed to make a specific fuzzing setup where the process prepared random certificates that are THEN signed and passed further and make the fuzzer short-circuit anything where the random cerificate failed the signing to actually test verification.

stabbles 4y ago

If you are tired of the frequency of CVEs in OpenSSL, consider sending a formal complaint to maintainers@openssl.org\0hunter2

deleted 4y ago
[deleted]
snvzz 4y ago
It'd be more productive to switch to libressl or bearssl.

billpg 4y ago

Exactly how panicked should I be right now?

INTPenis 4y ago
Extremely
- marginalia_nu 4y ago
  You should rarely be extremely panicked. It's not a very useful state of mind.
Sirened 4y ago
Not terribly; not only is it a hard path to hit (you need the malicious certificate to be issued by a trusted CA) and you have to figure out how to turn a very constrained 4 byte stack buffer overflow into something more powerful. Compiler engineers have been well aware of stack buffer overflows for a long time and so a lot of modern compilers do cheeky things to mitigate these sorts of overflows, ranging from placing these buffers at the bottom of the frame (so a linear overflow doesn't hit anything) to stuff like stack cookies protecting the return address from linear, blind overflows. This isn't to say it's impossible to exploit (as the linked post shows) given some lucky compiler decisions on where other things are placed, but as it stands it's unlikely to be useable as is.

awinter-py 4y ago

woof sympathy to everyone else who joined both the openssl exploit + the rust bound checking stan drinking game for november rough afternoon ahead

aborsy 4y ago

There are probably many such vulnerabilities in this giant code base, being exploited by those who have resources to find them. If OpenSSL is written in Rust, to what extent will the vulnerabilities be reduced (assuming that Rust is supported by the host, of course)?

nequo 4y ago
rustls can serve as an alternative.[1] Dirkjan Ochtman, one of the main contributors, wrote about it in this thread.[2] [1] https://github.com/rustls/rustls https://github.com/rustls/rustls [2] https://news.ycombinator.com/item?id=33423296 https://news.ycombinator.com/item?id=33423296

ComputerGuru 4y ago

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: > This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected. > 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.

TillE 4y ago
I wish I'd continued using a scripted build of OpenSSL 1.1.x on all platforms instead of switching to vcpkg OpenSSL 3.0.x on newer platforms. There's been a lot of drama for no particular gain in our use case.
NavinF 4y ago
If anyone's wondering why OpenSSL skipped 2.0.0, see https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/

baby 4y ago

https://twitter.com/cryptodavidw/status/1587505925731934208 https://twitter.com/cryptodavidw/status/1587505925731934208' > 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 (https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...)

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

29athrowaway 4y ago

Breaking news: software written in a language with error prone memory management has another security incident related to memory management. 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. 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. But hey, don't get distracted by automated memory management solutions, we are too busy fixing memory management problems manually.

necovek 4y ago
I am sure your OpenSSL-like library in Rust with support for using from all other programming languages is coming out any day now?
- 29athrowaway 4y ago
  Make fun all you want, bro. The days of juggling chainsaws are coming to an end. The NSA is crying.
- steveklabnik 4y ago
  No need to wait, at least for TLS https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi
  - necovek 4y ago
    Thanks, that's honestly very nice! I look forward to hearing about it as it becomes more widely used!
macintux 4y ago
Yet every time C comes up in a discussion here, someone will insist that it’s fine, that only bad programmers make mistakes. I don’t know Rust, and I love C, but we’re well past the point where one can reasonably argue that careful use of C is good enough.

entropicgravity 4y ago

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?

herpderperator 4y ago

> 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. https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b9feb3812bdc7781c784332 https://github.com/openssl/openssl/commit/3b421ebc64c7b52f1b... A one character change.