Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patch OpenSSL on November 1 to avoid “critical” security vulnerability

globalsign.com

Post reply on HN
Print view View original

171–180 of 217 posts

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#171

Post by cesarb »

valenterry wrote: post #55
nine_k wrote: post #39

Earlier quoted context omitted.

What makes Zig safer than Go, to your mind?

Features such as sum types (enums) that you can pattern match on. Or generics (well now Go got them as well, for a reason). Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path. Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So p…

> Think Java: for each type you have to create a new file.

That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#172

Post by fulafel »

Ayesh wrote: post #109
fulafel wrote: post #41

Earlier quoted context omitted.

Yep, this is interesting, I wonder what we can deduce about the nature of the bug from the fact that 2 separate implementations, one that's mostly memory safe, are impacted. (Of course Go didn't announce it's about the same thing, so it might be random, or might be some security research that found different bugs) Might it be a crypto bug, or logic bug (eg in x.509)? Is there code that's used by both OpenSSL and Go (…

In the linked article, Global sign says they don't know what exactly the vulnerability is. I imagine the public root CAs to be informed if this was an x.509 related bug. But again, Global Sign is a pretty shitty CA to begin with, so I wouldn't be surprised if they were not informed intentionally.

I'm not sure why CAs would be invited to the embargo, they're in the business of signing certs and while they do process untrusted certs so do zillions of other cert using folks.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#173

Post by Ayesh »

fulafel wrote: post #172
Ayesh wrote: post #109

Earlier quoted context omitted.

In the linked article, Global sign says they don't know what exactly the vulnerability is. I imagine the public root CAs to be informed if this was an x.509 related bug. But again, Global Sign is a pretty shitty CA to begin with, so I wouldn't be surprised if they were not informed intentionally.

I'm not sure why CAs would be invited to the embargo, they're in the business of signing certs and while they do process untrusted certs so do zillions of other cert using folks.

Just an speculation; for an x.509/web of trust related vulnerability, I expect the CAs to be a prominent target. There are hundreds of them, and I'm pretty sure there are at least a few of them that use OpenSSL somewhere in their certificate issuing process. Just to avoid DigiNotar-like fiascos revoking certificates en-masse, it probably makes sense to give a head-start to CAs.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#174

Post by dochtman »

justinjlynn wrote: post #68
JSGdev wrote: post #19

Earlier quoted context omitted.

Yep we've been using rustls for most of a year no issues. Memory safety go brrr :) Would encourage others to take a look at it. Ring is a good base that's been audited and the lower attack surface from no old openssl bloat code makes a difference.

Ring, unfortunately, has quite toxic project leadership with a history of making hostile decisions towards their contributors and userbase ( see https://github.com/briansmith/ring/issues/774 for one example ). Something to be aware of if you're considering building with it.

Note that the ring maintainer has long since stopped yanking releases.

More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#175

Post by Beltalowda »

s-macke wrote: post #87

When I execute an ldd at /usr/bin/ssh I get libssl.so.10 => /lib64/libssl.so.10 libssl3.so => /lib64/libssl3.so libnss3.so => /lib64/libnss3.so What puzzles me is that I am using libssl.so.10 and libssl3.so at the same time. libssl3.so belongs to the nss package and not to the openssl package. Am I affected?

The libssl3.so shared object from NSS just has a similar name. This is very confusing, but NSS has been around for a long time, before OpenSSL became the de-facto standard (sort-of), and certainly long before OpenSSL 3, so now we're "stuck" with this confusion.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#176

Post by Beltalowda »

tremon wrote: post #126
g_p wrote: post #113

Earlier quoted context omitted.

Indeed - this is one of the positives of Go, as all the dependencies get linked statically, giving nice portable "single binary" solutions. Grepping function names seems a reasonable approach, as long as you're not trying to detect something that is obfuscating its use of libssl (i.e. by mangling strings together). It appears if you strip a binary, any definitive information about the libraries linked in statically i…

Unsure why people keep referring to static linking as a positive in this thread? Downstream consumers of statically-linked binaries have no practical way to scan their systems for known-vulnerable versions of libraries, that seems a profoundly negative consequence to me.

In Go you can use "go version -m my-go-binary" and get a list of dependencies and other build information. For example (may wrap a bit ugly on HN):

  [~]% go version -m =godoc
  /home/belta/bin/godoc: go1.18.3
          path    golang.org/x/tools/cmd/godoc
          mod     golang.org/x/tools      v0.1.12 h1:VveCTK38A2rkS8ZqFY25HIDFscX5X9OoEhJd3quQmXU=
          dep     github.com/yuin/goldmark        v1.4.13 h1:fVcFKWvrslecOb/tg+Cc05dkeYx540o0FuFt3nUVDoE=
          dep     golang.org/x/mod        v0.6.0-dev.0.20220419223038-86c51ed26bb4        h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=
          dep     golang.org/x/net        v0.0.0-20220722155237-a158d28d115b      h1:PxfKdU9lEEDYjdIzOtC4qFWgkU2rGHdKlKowJSMN9h0=
          dep     golang.org/x/sys        v0.0.0-20220722155257-8c9f86f7a55f      h1:v4INt8xihDGvnrfjMDVXGxw9wrfxYyCjk0KbXjhR55s=
          build   -compiler=gc
          build   CGO_ENABLED=0
          build   GOARCH=amd64
          build   GOOS=linux
          build   GOAMD64=v1
So scanning your binaries, if you want, is fairly easy.

Other than that, this is the "Great Static vs. Dynamic Linking Debate", which has been done quite a few times. I have little desire to repeat it, but both approaches have their advantages and downsides, and with good tooling (like the above) I think many downsides of static linking can be managed quite well.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#177

Post by insanitybit »

jimktrains2 wrote: post #152
saagarjha wrote: post #118

Earlier quoted context omitted.

I’m curious if someone is going to come forward with it diffed out anyways…

The idea/hope/point of the embargo is not keep the issue secret forever, but to keep it secret long enough to allow fixes to be released and that most people can update when/before the details become widely known. I wouldn't be surprised if there's a "proper announcement" of the actual issue shortly after patches are widely available.

The problem is that it's usually very easy to just watch commits to find patches.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#178

Post by yellow_lead »

altdataseller wrote: post #164
yellow_lead wrote: post #160

Earlier quoted context omitted.

From the article: >If you’re using version 1.1.1, this vulnerability doesn’t affect you, but there is a 1.1.1 update coming on Tuesday as well, version 1.1.1s, which you’re still going to need to update to anyway so you might as well schedule some time on Tuesday, too.

Yep, so I assume this applies to 1.0.x as well?

Sorry, I misunderstood your question. But it looks like this will only affect users running 3.0.0 - 3.0.6.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#179

Post by insanitybit »

detaro wrote: post #103
rascul wrote: post #102

This is basically useless without identifying the vulnerability.

It's not useless, and if it identified the vulnerability it'd massively increase the risk of it being used before patch release.

Attackers can just go look at the repo's commits. Holding back the information only hurts defenders.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#180

Post by Beltalowda »

justinjlynn wrote: post #68
JSGdev wrote: post #19

Earlier quoted context omitted.

Yep we've been using rustls for most of a year no issues. Memory safety go brrr :) Would encourage others to take a look at it. Ring is a good base that's been audited and the lower attack surface from no old openssl bloat code makes a difference.

Ring, unfortunately, has quite toxic project leadership with a history of making hostile decisions towards their contributors and userbase ( see https://github.com/briansmith/ring/issues/774 for one example ). Something to be aware of if you're considering building with it.

I read through that issue, and it doesn't seem so bad? There is a disagreement, but I don't really see anyone involved being "toxic"?
Post reply on HN