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

161–170 of 217 posts

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

#161

Post by [deleted] »

justinjlynn wrote: post #82
tpxl wrote: post #80

Earlier quoted context omitted.

That looks reasonable to me. The author is blunt about how he does things and why he does them, while being polite. Don't know what 'yanking' a crate means specifically, but that seems like an ecosystem problem; in Java for example, maven dependencies are supposed to be immutable and the largest distributor (mvnrepository) doesn't allow updating a package.

Yanking crates makes them entirely unavailable for downstream users unless they've already locked the yanked version locally. This breaks dependencies and unlocked builds. Yanking crates is a last resort measure (a fundamentally broken release or a release for which you've issued a security advisory) and not something which should be done trivially regardless of whether or not it breaks all of your users for reasons…

[deleted]

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

#162

Post by [deleted] »

userbinator wrote: post #64
progbits wrote: post #61

Earlier quoted context omitted.

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...?

[deleted]

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

#163

Post by woodruffw »

danhor wrote: post #63
progbits wrote: post #61

Earlier quoted context omitted.

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

The idiom for this is “biting your nose off to spite your face.”

You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.

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

#164

Post by altdataseller »

yellow_lead wrote: post #160
altdataseller wrote: post #122

Earlier quoted context omitted.

What if you're using using the 1.0.x lineage? Does this vulnerability specifically impact you? ducks and covers

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?

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

#165

Post by jrootabega »

_hyn3 wrote: post #154
jrootabega wrote: post #110

Here's the official place where these are announced, if you feel a little uneasy getting urgent security advisories from tweets and blogs: https://mta.openssl.org/mailman/listinfo/openssl-announce

Your point stands, but FWIW, this is actually Globalsign GMO[0], one of the largest TLS certificate authorities (CA's), so certainly they have a vested interest in making sure OpenSSL is secure. (Globalsign also partnered with CloudFlare for TLS certificates[1]) 0. https://en.wikipedia.org/wiki/GlobalSign 1. https://techcrunch.com/2012/11/01/cloudflare-globalsign-make...

I don't think the post is inaccurate or the authors untrustworthy, but I don't think it's a good idea to rely on their blog to get OpenSSL alerts, especially when there is an official, high signal-to-noise, alternative. If someone reads this HN submission and wants to make sure they get alerted about the next critical vulnerability, they should subscribe.

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

#166

Post by grepfru_it »

saagarjha wrote: post #118
woodruffw wrote: post #53

Earlier quoted context omitted.

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

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

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 point you are welcome to reverse engineer the changes and create the exploit.. I moved onto more interesting problems

Edit: once upon a time I went to a google container security conference and the kubernetes vulnerability disclosure process was described. I noticed there is at least 12-18 hours from patching a vulnerability before binaries are generated and the public notice is made. More than enough time to identify, exploit, and 0day into the wild

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

#167

Post by adamckay »

rascul wrote: post #157
stoplying1 wrote: post #155

Earlier quoted context omitted.

"I'm good at DevOps and everyone else should be too", feels tangential, and isn't going to help you when your banking session gets compromised because your bank wasn't prepared to roll this out through any expedited process versus their regulatory compliant, slow process. (As an example/thought experiment. I make no claims about the vulnerability at hand.)

I don't know anything about the update processes banks use. I would hope they wouldn't have to jump through hoops to apply a security update. Didn't they learn this already?

What do you expect banks and other regulated industries do? YOLO patch whatever and whenever?

I don't work in a regulated industry where it's required, but we do similar with a proper change control process and there's not a single individual that's authorised to perform changes without oversight, (even if that oversight from senior leadership comes retrospectively).

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

#168

Post by Arch-TK »

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

Earlier quoted context omitted.

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.

While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without having a performance impact? While a language which prevents certain memory errors by design is going to be safe by design, it's entirely possible this bug is in code so hot that it has been repeatedly optimized further and further and that an equivalent implementation in rust would require an unsafe block. Now it is all great to respond to this by saying "safety should never preclude performance" but in that case, why would you write in rust when there are even safer languages such as spark? Moreover, if your secure solution is too slow, nobody will want to use it.

I do agree that OpenSSL is a pile of trash, but an overwhelming amount of the crust of OpenSSL is not C related.

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

#169

Post by rascul »

adamckay wrote: post #167
rascul wrote: post #157

Earlier quoted context omitted.

I don't know anything about the update processes banks use. I would hope they wouldn't have to jump through hoops to apply a security update. Didn't they learn this already?

What do you expect banks and other regulated industries do? YOLO patch whatever and whenever? I don't work in a regulated industry where it's required, but we do similar with a proper change control process and there's not a single individual that's authorised to perform changes without oversight, (even if that oversight from senior leadership comes retrospectively).

What did banks do with heartbleed, shellshock, spectre, etc?

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

#170

Post by apstls »

rascul wrote: post #138
detaro wrote: post #111

Earlier quoted context omitted.

... and an announcement like this is a fairly strong message of "assume you need to care"

I'm not going to assume anything in regards to a future release I have no details about.

The detail that it patches a critical vulnerability should be enough for you to assume you should care, assuming you care about security.
Post reply on HN