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

51–60 of 217 posts

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

#51

Post by littlestymaar »

valenterry wrote: post #26
fulafel wrote: post #17

Earlier quoted context omitted.

The start has happened, but it's happening unevenly with different users. Lots of TLS servers (in reverse proxies but also in backend apps and even Apache httpd[1]) are in memory safe languages. For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient…

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

I'm not a fan of Go but it is memory safe (with a very minor exception[1]), Zig isn't (it will likely end up safer than C, but it will be “modern c++”-safe but not memory safe.

[1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.

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

#52

Post by topspin »

sullivanmatt wrote: post #25

Ubuntu 22.04 & RHEL 9 are the major distros impacted. Docker images built on ubuntu:latest will also be impacted. The latest releases of Alpine/Debian/AL2 are all not impacted, they use 1.1.x lineage.

Amazon Linux 2022 Preview (the upcoming successor to Amazon Linux 2) is also using OpenSSL 3. Had to shut down one host I have using that for an ongoing project until Amazon makes another RC package update.

That was, as it turns out, the only OpenSSL 3 host I'm presently dealing with.

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

#53

Post by woodruffw »

fh973 wrote: post #42

Couldn't they be a bit more specific? No software uses all of openssl, there is software that uses it for other things than server-side TLS.

This is the challenge with embargoed disclosures: they have to be as generic as possible, to prevent people from sniffing the bug out.

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

#54

Post by fulafel »

littlestymaar wrote: post #51
valenterry wrote: post #26

Earlier quoted context omitted.

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

I'm not a fan of Go but it is memory safe (with a very minor exception[1]), Zig isn't (it will likely end up safer than C, but it will be “modern c++”-safe but not memory safe. [1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory language…

> this has ever been proven exploitable

I agree (typo exploit!)

See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

(And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)

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

#55

Post by valenterry »

nine_k wrote: post #39
valenterry wrote: post #26

Earlier quoted context omitted.

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

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 people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.

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

#56

Post by thayne »

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]…

Not to mention that a lot of places are still using openssl 1.1.1.

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

#58

Post by valenterry »

fulafel wrote: post #40
valenterry wrote: post #26

Earlier quoted context omitted.

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1]. Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years. [1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=3…

Sure, I agree - I don't think what you said contradicts my point.

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

#59

Post by userbinator »

Gigachad wrote: post #4

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

I want it to be never. Controversial opinion: as long as those who use "security" to oppress us have the upper hand, code written in "unsafe languages" will always leave a path to freedom from the authoritarian dystopia of corporations and governments who will seek to increase their control over our lives. We've already seen the battle start at DRM, jailbreaking/rooting, etc. IMHO the periodic but not-too-often occurrence of vulnerabilities like this, just like a nonzero amount of (cyber)crime, is a justifiable cost that we must continue to tolerate and pay for the sake of our freedom.

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

#60

Post by fulafel »

29athrowaway wrote: post #3

Quoted post unavailable.

We have https://github.com/rustls/rustls though it doesn't aim to be especially OpenSSL compatible.

It has C bindings used in eg in this Apache httpd mod_tls: https://www.memorysafety.org/blog/memory-safe-httpd/

Post reply on HN