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

211–217 of 217 posts

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

#211

Post by grepfru_it »

CommitSyn wrote: post #193
grepfru_it wrote: post #166

Earlier quoted context omitted.

I went through that process when I first heard the announcement. The fixes have been applied to master which is tagged for a release. You can search issues by severity tag and it becomes pretty obvious which of the few issues is related to the problem (one of the contributors flat out stats a change must be merged for a major security fix). Went looking at PRs and came across a buffer overflow. I stopped at this poin…

This is a stupid question but is the patch not being released until Nov 1, or is the security patch already in the Ubuntu updates and they're just not publicly releasing the vuln until Nov 1?

I don’t think I was clear in my original post. The patch is in master but the latest release 3.0.7 has not been tagged yet and so releases have not been drafted. The patches maybe released early to large or popular organizations but I’m not sure of OpenSSL critical patch process

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

#212

Post by wlonkly »

Beltalowda wrote: post #176
tremon wrote: post #126

Earlier quoted context omitted.

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…

Unfortunately that shows the Go libraries involved, but not the C libraries those Go libraries depend on (right?). So that might tell me that a Go program includes 'crypto', but not whether or not that 'crypto' linked in OpenSSL 1.1.1 or OpenSSL 3.x.

So the static linking dependency analysis problem remains.

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

#213

Post by Beltalowda »

wlonkly wrote: post #212
Beltalowda wrote: post #176

Earlier quoted context omitted.

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…

Unfortunately that shows the Go libraries involved, but not the C libraries those Go libraries depend on (right?). So that might tell me that a Go program includes 'crypto', but not whether or not that 'crypto' linked in OpenSSL 1.1.1 or OpenSSL 3.x. So the static linking dependency analysis problem remains.

cgo stuff gets dynamically linked by default, although you can link it statically (usually); the OpenSSL bindings for Go seem to support it, but almost no one uses these[1].

You're right that these don't show up, but in practice it's mostly a non-issue for the most part as cgo isn't used that often and purely statically linked cgo even less so, and when it is it's often in the form of e.g. go-sqlite3 where the SQLite version is tied to the module version.

The problem is that "static linking" means "grab whatever is in /usr/lib/libfoo.a, whatever that may be". I'm not sure if there is a good way to solve this in a generic way that works everywhere, outside of keeping track of sums.

[1]: https://pkg.go.dev/github.com/spacemonkeygo/openssl?tab=impo...

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

#214

Post by s-macke »

xorcist wrote: post #90
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?

It is very unlikely that this affects OpenSSH regardless. Only the cryptographic primitives are used from OpenSSL, and none of the complexity of the SSL functions. The cryptographic functions themselves are small and extremely well tested.

I took ssh only as an example as curl has the same dependency.

But thanks to @Beltalowda it is obvious, that the lib64/openssl3 does not belong to openssl.

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

#215

Post by s-macke »

Beltalowda wrote: post #175
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.

Many thanks for the information! This is really confusing.

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

#216

Post by sodality2 »

rascul wrote: post #149
iamtedd wrote: post #147

Earlier quoted context omitted.

You're not convinced? About a security vulnerability... From an open-source project... That has a history of major security vulnerabilities... Because there's no detailed information yet... When industry best practice is to not give detailed information without a patch or workaround... And they're giving you a heads-up for required mitigation in three days... Rather than right now...

No, I'm not convinced that the vulnerability is something I need to care about, because there's no details about it. I can make that determination when I have details. I am well aware of that project's history. I see no information given that would imply this to be anything more special than a regular update for me, for which the process I have already streamlined. I understand the practice of not giving the details…

To provide a counter, it's the second total vuln to be labeled critical by OpenSSL - first was in 2014, and it was Heartbleed...

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

#217

Post by jimktrains2 »

insanitybit wrote: post #177
jimktrains2 wrote: post #152

Earlier quoted context omitted.

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.

Patches usually aren't released publicly until after the embargo period.
Post reply on HN