OpenSSL 3.0.7 fixes X.509 email address buffer overflows

https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

by petecooper • 4 years ago

586 210 4 years 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• 4 years ago

The NixOS update has some details: 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*

secondcoming2• 4 years ago

This does not seem to contain any extra information at all?

baggy_trough5• 4 years ago

Malicious email address in what, I wonder.

captn3m0• 4 years ago

sounds like the X.509 certificate?

LawnGnome• 4 years 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?)

baggy_trough5• 4 years ago

Now in the change log: https://www.openssl.org/news/cl30.txt

NovemberWhiskey6• 4 years 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• 4 years ago

Doesn't sound that critical to me.

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.

tedunangst2• 4 years 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?

petecooper4• 4 years ago

https://archive.ph/Igu2e

MallocVoidstar• 4 years 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])

cp9• 4 years ago

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

tialaramex2• 4 years 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• 4 years 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• 4 years 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

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• 4 years ago

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

datalopers• 4 years ago

OpenSSL 3.x has a fairly small install base

input_sh2• 4 years ago

Lots of distros don't use v3 yet and are not affected.

This is definitely far from Heartbleed level of catastrophe.

TheRealDunkirk• 4 years 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?)

Sohcahtoa823• 4 years ago

In addition to very few distros using OpenSSL 3, your server is only affected if you do client certificate verification, which is exceptionally rare for public internet servers.

As a client, you're only affected if you connect to a malicious server.

ignaloidas• 4 years ago

Could in theory be utilized to move laterally in networks where client TLS is used for authentication, which I see used sometimes.

tajen• 4 years ago

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

tempay2• 4 years ago

The offical NodeJS binaries statically link to OpenSSL so they have the be patched explicitly for OpenSSL vulnerabilities.

joecool1029• 4 years 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• 4 years 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.

fulafel3• 4 years ago

I wonder if they are built with stack protector turned on in the compiler flags.

miduil• 4 years ago

Diff of 3.0.6 and 3.0.7: https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098...

via https://www.twitch.tv/filosottile

formerly_proven3• 4 years ago

Specifically https://gist.github.com/FiloSottile/611fc3fa95c3aceebf258098...

    -    if (written_out > max_out)
    +    if (written_out >= max_out)
             return 0;

Plus a second, less memeable fix.

jancsika2• 4 years ago

I don't understand this one:

     -                (written_out - i) * sizeof *pDecoded);
     +                (written_out - i) * sizeof(*pDecoded));

Edit: just to be clear-- I'm claiming there's no way the addition of parentheses could change the behavior of the program.

I guess I can understand resolving an ambiguity so that the reader doesn't have to look up precedence rules. But when combined with a high-profile bug in a critical piece of infrastructure it looks a bit like the software equivalent of not shaving one's beard in the hopes of winning a sports tournament.

hedora3• 4 years ago

From the variable names, it is clear that the old version was correct. Someone should revert this. :-)

petecooper4• 4 years ago

[deleted]

pvg2• 4 years 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.

petecooper4• 4 years ago

You're right. I'll delete it.

8K832d7tNmiQ• 4 years ago

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

baggy_trough5• 4 years ago

Last time we went through this (Heartbleed, I think) it took several hours.

jacooper• 4 years ago

Its going to be backport, so its going to be a fixed 3.0.2 not 3.0.7.

Thaxll• 4 years ago

https://ubuntu.com/security/CVE-2022-3786

nequo4• 4 years 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_trough5• 4 years ago

I would expect there should be a patch sometime today, but maybe not for a few hours based on prior experience.

_joel• 4 years ago

Also be aware sometimes fixes are backported, so the version isn't 100% accurate, ymmv etc.

schlauerfox• 4 years 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.

Shared404• 4 years ago

You can find info at https://ubuntu.com/security/cves for *buntu.

NegativeK• 4 years ago

https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.... is showing the patched version.

nequo4• 4 years ago

After an `apt update` on jammy, `apt changelog openssl` still shows 3.0.2-0ubuntu1.6 for me as the latest from July 4. Do you know if there is something that is holding it back from trickling down?

Edit (28 minutes later): I got the update now. Many thanks to Marc Deslauriers for his work!

TheHippo• 4 years ago

Ubuntu packages are built with stack protector, reducing the impact of this CVE from remote code execution to a denial of service.

timvisee• 4 years ago

I just received the updated packages!

NicolaiS• 4 years ago

openssl packaged as `3.0.2-0ubuntu1.7` fixes the issue. So `>1, <= 3.0.2-0ubuntu1.6` is vulnerable.

If you are using an APT mirror, you might not see the update yet. Consider adding `deb http://archive.ubuntu.com/ubuntu jammy-updates main restricted` to `/etc/apt/sources.list` to get the updated package

lawgimenez• 4 years ago

This might be relevant: https://www.malwaretech.com/2022/11/everything-you-need-to-k...

tempay2• 4 years ago

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

ollien• 4 years ago

Huh. I wonder why they decided to walk it back _after_ disclosure.

gjasny• 4 years ago

This is answered in their blog entry: 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.

baggy_trough5• 4 years ago

OpenSSL blog post: 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.

NovemberWhiskey6• 4 years 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.

couchand2• 4 years 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.

dochtman5• 4 years 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

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

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.

anonym294• 4 years 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.

dochtman5• 4 years 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/

Macha• 4 years ago

Of course you'd expect a formal specification to include details on what the fundamental data types actually are - C11 can't be nailed down on what char is, it defines it as a type large enough to store a member of the implementation-defined basic character set with implementation defined signedness. Which means you could have a valid implementation with anything from a 4-bit unsigned char to a 256 bit or larger signed char

hedora3• 4 years ago

What is performance like? We had to move off libressl because of performance, which makes me sad.

In particular, does it support all the common crypto accelerator CPU instructions? How does it fare on the microbenchmarks the various openssl forks ship?

dochtman5• 4 years ago

There are fairly comprehensive measurements from 2019:

https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html

I'm pretty sure current versions of rustls are faster than the ones from 2019, but I don't have an intuition for how OpenSSL performance has evolved in the past three years.

I'd like to do another comparison some time soon.

(Yes, the underlying ring crypto library should take advantages of specific instructions available on common CPU architectures.)

eptcyka• 4 years ago

Rustls only supports tls 1.3 and 1.2, as a design choice - so long as cutting older clients off is an acceptable choice, you should be using rustls.

martin1975• 4 years ago

There's a reason why IETF deprecated TLS 1.0 and 1.1. So your point is somewhat moot. If anyone's using either of these, they're just waiting to be exploited.

Sohcahtoa823• 4 years ago

TLS 1.2 has been supported by every major browser since 2014. Using a browser older than that is just simply irresponsible.

CameronNemo2• 4 years ago

The criticisms that I have heard regarding ring/rustls is that the crypto primitives are implemented in assembly and there is no portable reference implementations that can be used to verify them.

In contrast, EverCrypt is a formally proven TLS implementation. There is a portable implementation of all algorithms that is used to verify the correctness of the assembly implementations.

https://project-everest.github.io/

dochtman5• 4 years ago

Work is ongoing to use FiatCrypto-based implementations for the primitives, which is discussed a bit here:

https://www.crowdsupply.com/sutajio-kosagi/precursor/updates...

hedora3• 4 years 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• 4 years ago

There is this on IPSEC: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...

_jal3• 4 years ago

Could be most any of this activity:

https://blog.cryptographyengineering.com/2013/09/06/on-nsa/

mkj• 4 years ago

There's some more discussion of ipsec in the thread https://www.metzdowd.com/pipermail/cryptography/2020-July/03...

I'd be interested to see references to SSL too (from a historical perspective)

grepLeigh• 4 years 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.

SoftTalker2• 4 years 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

NovemberWhiskey6• 4 years ago

No, these fixes look unrelated.

iio7• 4 years 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• 4 years ago

Libre should delete the code that support X509 email addresses.

Faelian2• 4 years 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.

pjmlp• 4 years ago

Not every systems has the necessary mitigations enabled.

mroche2• 4 years ago

Red Hat vulnerability page with a system detection script:

https://access.redhat.com/security/vulnerabilities/RHSB-2022...

linsomniac• 4 years 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.

mroche2• 4 years 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• 4 years 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.

petecooper4• 4 years 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."

l1n• 4 years ago

Sounds like this is mostly caught by stack overflow protections. From the release blog:

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.

blueflow2• 4 years 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.

dom96• 4 years ago

Maybe we should set up a naming system just like for COVID variants

tptacek3• 4 years ago

No, it's not. Branded vulnerabilities are memorable. CVE numbers aren't.

ASalazarMX• 4 years 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.

_jal3• 4 years ago

Only for major problems, and even then it seems iffy. I have trouble remembering which specific issue Meltdown actually refers to a couple years on.

Personally, I'm totally fine with CVEs. (And if people to stop acting like QIDs are interchangeable, that would be great, too.)

blueflow2• 4 years ago

The branding does not help the patching, its for self-promotion of security people. Its incentives go into the wrong direction.

nequo4• 4 years 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.

userbinator2• 4 years 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.)

excalibur• 4 years ago

Since they declined to name it, we get to name it for them, right? Let's call it CertHurt.

mdaniel• 4 years ago

RCE-mail? Hopefully someone can work "Cert" in, but all my attempts broke up the meter of saying it

Of course, that's cheating a little since we now know that it's not _automatically_ an RCE

jabroni_salad• 4 years ago

NCSC is calling it SpookySSL but I think it is just for funsies. https://github.com/NCSC-NL/OpenSSL-2022

nurettin3• 4 years ago

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

fulafel3• 4 years ago

OpenSSH doesn't use X.509 certs.

macintux3• 4 years ago

Affected (and unaffected) software tracking page shared earlier today:

https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/R...

Kwpolska• 4 years ago

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

gnfargbl• 4 years 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

mkeedlinger2• 4 years ago

Anywhere I can learn more about what stack protection they have?

slt20212• 4 years ago

https://lwn.net/Articles/584225/

0xbadcafebee3• 4 years ago

https://wiki.ubuntu.com/Security/Features - particularly the stack protector, heap protector, ASLR, PIE, stack clash protection, NX bit, kernel stack protector, kernel ASLR.

AtNightWeCode2• 4 years ago

That is a very clever feature. Cheap insurance.

seedless-sensat• 4 years ago

I liked this write up: https://securitylabs.datadoghq.com/articles/openssl-november...

psanford• 4 years ago

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

secondcoming2• 4 years 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

dang• 4 years ago

Url changed from https://mta.openssl.org/pipermail/openssl-announce/2022-Nove... to a post with more background.

(via https://news.ycombinator.com/item?id=33423271, but we merged that thread hither)

Arcuru• 4 years 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-o...

userbinator2• 4 years 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• 4 years 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• 4 years 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.

fulafel3• 4 years ago

Fuzzing is searching the vast input space with various rough heuristics to try to weigh more error prone paths to generate test inputs for. It's incomplete by nature.

AtNightWeCode2• 4 years ago

This seems more difficult to find with fuzz tests than Heartbleed. Unit tests of all edge values would have found this. I think the solution is to use better tools and methodology.

The size of the code base is also just daunting and a security risk in itself.

stabbles• 4 years ago

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

snvzz2• 4 years ago

It'd be more productive to switch to libressl or bearssl.

billpg• 4 years ago

Exactly how panicked should I be right now?

INTPenis• 4 years ago

Extremely

marginalia_nu• 4 years ago

You should rarely be extremely panicked. It's not a very useful state of mind.

Sirened• 4 years 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• 4 years 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• 4 years 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)?

nequo4• 4 years 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

[2] https://news.ycombinator.com/item?id=33423296

ComputerGuru• 4 years 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• 4 years 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• 4 years ago

If anyone's wondering why OpenSSL skipped 2.0.0, see https://www.openssl.org/blog/blog/2018/11/28/version/

baby• 4 years ago

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

29athrowaway2• 4 years 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.

necovek4• 4 years 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?

29athrowaway2• 4 years ago

Make fun all you want, bro. The days of juggling chainsaws are coming to an end. The NSA is crying.

steveklabnik• 4 years ago

No need to wait, at least for TLS https://github.com/rustls/rustls-ffi

macintux3• 4 years 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• 4 years 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• 4 years 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/3b421ebc64c7b52f1b...

A one character change.

OpenSSL 3.0.7 fixes X.509 email address buffer overflows

Related Stories