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

61–70 of 217 posts

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

#61

Post by progbits »

userbinator wrote: post #59
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 occur…

What are you on about? Using a library written in memory-safe language won't oppress you.

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

#62

Post by littlestymaar »

fulafel wrote: post #54
littlestymaar wrote: post #51

Earlier quoted context omitted.

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…

Oh, I wasn't aware of the second blog post, thanks.

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

#63

Post by danhor »

progbits wrote: post #61
userbinator wrote: post #59

Earlier quoted context omitted.

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

What are you on about? Using a library written in memory-safe language won't oppress you.

Software inhibiting user freedom (like drm) often gets broken using buffer overflows, string parsing mistakes, ... (as seen on many game consoles). Broken (drm) software allows for more user-freedom.

If this software was using Rust, it would be much harder to break them than is currently the case.

And tbh, I have to concur (somewhat). I have lost little-to-nothing due to software exploits, but have gained significantly. For example, reading epubs with my kindle or loading homebrew on game consoles.

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

#64

Post by userbinator »

progbits wrote: post #61
userbinator wrote: post #59

Earlier quoted context omitted.

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

What are you on about? Using a library written in memory-safe language won't oppress you.

Those who use them will, and have already been doing so even without memory-safe languages, one notable example being that company named after a fruit; but for a long time, there was always a way out.

The metaphor I like to use is "giving them better nooses to put around our necks."

...and I suppose you could argue that neither do guns kill people...?

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

#65

Post by bondant »

fulafel wrote: post #46
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.

For example, OpenSSH.

Does OpenSSH use OpenSSL? I thought they migrated to LibreSSL.

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

#66

Post by fulafel »

progbits wrote: post #61
userbinator wrote: post #59

Earlier quoted context omitted.

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

What are you on about? Using a library written in memory-safe language won't oppress you.

Someone else using it might though.

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

#67

Post by fulafel »

bondant wrote: post #65
fulafel wrote: post #46

Earlier quoted context omitted.

For example, OpenSSH.

Does OpenSSH use OpenSSL? I thought they migrated to LibreSSL.

The Ubuntu 22.04 LTS openssh-server package seems to depend on libss3 which is built from OpenSSL:

https://packages.ubuntu.com/jammy/openssh-server -> https://packages.ubuntu.com/jammy/libssl3 -> https://packages.ubuntu.com/source/jammy/openssl

Apparently there are some problems with LibreSSL on Linux: https://lwn.net/Articles/841664/

(Also, do we know that LibreSSL is unaffected?)

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

#68

Post by justinjlynn »

JSGdev wrote: post #19
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]…

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.

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

#69

Post by drran »

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…

Rust doesn't have GC, but it has very good automatic memory management. GC or memory management doesn't make programs immune to buffer overflows, which is the most common security vulnerability these days, while use-after-free is at 4th place.

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

#70

Post by 29athrowaway »

yjftsjthsd-h wrote: post #50
29athrowaway wrote: post #15

Earlier quoted context omitted.

The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable. Google: openssl "use-after-free" site:cvedetails.com/cve It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes. In Rust many of those errors become compile-time errors.

That's one possible reading of the situation, certainly. Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. Unfortunately TLS libraries are thin enough on the ground that we can't really pick out patterns. It's like saying that microkernels are bad because HURD has serious issues; it could be true, but comparing by the well-known problem child isn't…

> Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in.

There are well-known, proven solutions to the memory management problems that affect OpenSSL (a C library) in a regular basis, and there are languages that implement those solutions. Among them, Rust, Ada and others.

Post reply on HN