Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

21–30 of 112 posts

Re: OpenSSL Security Advisory

#21

Post by nine_k »

hannob wrote: post #13
VeejayRampay wrote: post #4

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact…

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

Re: OpenSSL Security Advisory

#22

Post by [deleted] »

hannob wrote: post #13
VeejayRampay wrote: post #4

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact…

[deleted]

Re: OpenSSL Security Advisory

#24

Post by bjourne »

nine_k wrote: post #21
hannob wrote: post #13

Earlier quoted context omitted.

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact…

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.

Re: OpenSSL Security Advisory

#25

Post by cm3 »

dijit wrote: post #6

Luckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49

Assuming we stay with a library written in C, a better approach would be for everyone to try to move to what's in BoringSSL, which deliberately removed most stuff, more than LibreSSL.

If we still stay with C, Ring would be a good replacement, which is partially/primarily written in Rust.

That said, LibreSSL's TLS abstractions look like a welcome improvement if you need a C API.

Re: OpenSSL Security Advisory

#26

Post by mbrock »

bjourne wrote: post #24
nine_k wrote: post #21

Earlier quoted context omitted.

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.

This kind of resource DoS attack doesn't seem like it's directly related to safe/unsafe. I think you would be just as likely to forget to put a resource limit if you were writing in Haskell.

Re: OpenSSL Security Advisory

#27

Post by pygy_ »

throwaway7767 wrote: post #11
dijit wrote: post #6

Luckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49

The interesting thing about LibreSSL is that it's got such a halo around it that people just assume it's not vulnerable to any OpenSSL bugs. Practically every OpenSSL bug posted here gets the standard "Luckily LibreSSL isn't affected by this kind of thing" response. On a couple of occasions I've taken the bait and linked to the LibreSSL source to show that the relevant bits are in fact not changed at all, so they wer…

> On a couple of occasions I've taken the bait and linked to the LibreSSL source to show that the relevant bits are in fact not changed at all, so they were both vulnerable.

That's not a bulletproof way to assess bugs in LibreSSL because its authors also removed vulnerabilities from general helpers functions, proactively fixing issues in the code that uses them.

Re: OpenSSL Security Advisory

#28

Post by barkingcat »

VeejayRampay wrote: post #4

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

Why would it end? There is no perfect software if that's what you're looking for.

Re: OpenSSL Security Advisory

#29

Post by cm3 »

VeejayRampay wrote: post #4

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

Short answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues.

Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had we as an industry taken security more seriously decades ago, we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production. We can extend 1960s kernel designs with all kinds of features, but without a coherent design it's impossible to provide the same assurance. This is why it's great that we have L4 descendants that incorporate a capability scheme and also support a multikernel scheme (ala Barrelfish) for making better use of a cluster of cpu cores.

Re: OpenSSL Security Advisory

#30

Post by danarmak »

bjourne wrote: post #24
nine_k wrote: post #21

Earlier quoted context omitted.

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.

Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.
Post reply on HN