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

91–100 of 217 posts

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

#91

Post by justinjlynn »

drran wrote: post #89
justinjlynn wrote: post #81

Earlier quoted context omitted.

That's a rather charitable interpretation of events. Events which didn't need to happen. Events which happened for dubious reasons and which depended dubious reasoning.

Demand your money back!

Oh no. Just because they donate their time and effort the community can't criticise them; even if how they work and interact with the community hurts and embarrasses the community... it was all free after all and the community added nothing to it! /s

That's really not how it works when you work with others and use other's resources and time. Nobody's entitled to their effort, but they're also not immune to criticism from others for that effort if they hold that effort out for others - if they expect immunity because it's 'free' they're just wasting people's time and preventing the development of a solution which doesn't.

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

#92

Post by g_p »

jbverschoor wrote: post #88

What's the 'best' way to find out if there are binaries in which libssl is statically linked?

If you're using distro packages, their own "packaging policy" should offer some level of assurance via policy about static linking (since as far as I know, all major distros dynamically link, to make this kind of bugfix easier).

If you're talking non distro packages (proprietary, or anything built manually from PPA or equivalent, or binaries dumped inside containers), this won't help.

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

#93

Post by yakubin »

fulafel wrote: post #79
Lex-2008 wrote: post #74

Earlier quoted context omitted.

The globalsign atricle says: > If you’re using version 1.1.1, this vulnerability doesn’t affect you AFAIK, LibreSSL forked even before that - when OpenSSL was version 1.0 or 0.9 even. So likely not affected - unless a similar issue appeared there after the fork.

Parallel forks sometimes keep incorporating quite a lot of changes from each other, in the *BSD fork tradition. I'd also guess that LibreSSL is not affected but it's not a foregone conclusion. In the previous OpenSSH vs OpenSSL 3 bug it went like this: > The issue has been identified in OpenSSL version 3.0.4, which was released on June 21, 2022, and impacts x64 systems with the AVX-512 instruction set. OpenSSL 1.1.1…

I'd expect higher quality code review from OpenBSD folks (who maintain LibreSSL), compared to OpenSSL.

Also, an interesting talk: LibreSSL: The first 30 days, and what the Future Holds from BSDCan: https://www.youtube.com/watch?v=oM6S7FEUfkU>

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

#95

Post by jeroenhd »

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 wouldn't call it toxic per se. It's a very business oriented approach.

Using ring without a support contract is clearly a terrible decision. It's not a library any open source project or other library should depend on. Doing so will break your builds and the builds of others that use your library.

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

#96

Post by jbverschoor »

g_p wrote: post #92
jbverschoor wrote: post #88

What's the 'best' way to find out if there are binaries in which libssl is statically linked?

If you're using distro packages, their own "packaging policy" should offer some level of assurance via policy about static linking (since as far as I know, all major distros dynamically link, to make this kind of bugfix easier). If you're talking non distro packages (proprietary, or anything built manually from PPA or equivalent, or binaries dumped inside containers), this won't help.

Sure, but there might also be binaries outside the distro which link things statically, because makes distribution easier.

This is one of the "benefits" of go, where afaik many things are linked statically.

I'm currently playing around with grepping some function-names to find out if something uses libssl, and then check if ldd to see if libssl is loaded dynamically or not.

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

#97

Post by mmwelt »

woodruffw wrote: post #22
mmwelt wrote: post #9

> And by widely leveraged, I mean almost completely ubiquitous, if you’re using HTTPS, chances are you’re using OpenSSL. Almost everyone is. This is probably a bit of an exaggeration. There are quite a few other SSL implementations that actually are also "widely leveraged"[1]. In particular, LibreSSL was forked and cleaned up after Heartbleed. Google uses BoringSSL. GnuTLS is widely used and unrelated to OpenSSL. [1]…

Is GnuTLS widely used? People bring it up, but I've never actually seen it in a codebase (and I deal with a lot of x509 + PKCS code). I've seen more wolfSSL and mbedTLS than GnuTLS.

One probably important project that uses it is OpenConnect, as the VPN servers would probably be listening on a port reachable on the open internet.

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

#98

Post by ancarda »

frankjr wrote: post #94

This is supposedly the commit which fixes the bug https://github.com/openssl/openssl/commit/3df6aed7826640d944...

I don't know a lot about C or the internals of OpenSSL, but going by the commit message, does this mean we should disable TLSv1.3 until we've had a chance to patch OpenSSL?

Edit: Actually, reading through the code a few times, maybe TLSv1.2 should be disabled?

I really wish we had some way to protect ourselves until the patch is widely available.

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

#99

Post by jeroenhd »

drran wrote: post #73
justinjlynn wrote: post #68

Earlier quoted context omitted.

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.

It looks like author of ring library tries to protect their user base from security vulnerabilities, but hit by bug(?) in cargo, which changed from warning to error for yanked libraries. Anyway, no promises until API version 1.0.

I don't really get the reasoning (if there's a security bug, surely you know you've fixed it?). I fully support taking down versions that have known vulnerabilities, like the broken OpenSSL crate mentioned in that discussion.

The bug in cargo made the issues worse but not by much. Pulling crates/packages from the repository will break the build for almost everyone because updating your dependencies to the latest version, especially with an API that is not backwards compatible, takes time. The author suggests bumping versions until the application compiles again and that approach an easily take an afternoon if one of your dependencies hasn't updated yet.

It's the equivalent of the curl team deciding to pull all non-modified distributions of curl more than two versions old, or Angular/React/Svelte/Whatever doing the same, because they don't know if those versions are vulnerable or not.

There would be chaos as suddenly Linux distributions could no longer be built, reproducible builds would probably fail in the forked copies, most web applications would fail to start.

Nobody is asking the author to support older versions, or to not break the API between versions. The API is unstable, it's not had a 1.0 release and it probably never will. All people ask is leaving the old versions up so other projects can still build.

Since the project is open source, I suppose it's possible for someone else to created a ring-unpulled crate that's just the ring crate but with old versions still up. Should be doable with nothing more than a bash script running on a server somewhere.

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

#100

Post by jeroenhd »

Gigachad wrote: post #4

How many times does this have to happen before we start rejecting components written in unsafe languages?

We have no indication that memory safety is even involved in this bug. For all we know, it could be a timing vulnerability that allows factoring key material, data being copied from the wrong object, or a protocol flow bug that let's the attacker bypass validation. You can create a vulnerability by adding || where you meant && in any programming language, even Rust without unsafe code enabled.
Post reply on HN