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

51–60 of 112 posts

Re: OpenSSL Security Advisory

#51

Post by dimino »

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…

OpenSSL considers this a "high" severity issue.

Re: OpenSSL Security Advisory

#52

Post by adekok »

robryk wrote: post #42

Why is the severity of the first vulnerability high? It allows a denial of service on the server's side by a client and nothing else. The second vulnerability seems to be very similar in severity, except that it can be used both against clients and servers, and yet it is of just moderate severity. What am I missing?

Presumably because fewer applications use SSL_peek().

But yes, that issue is a serious problem, too.

Re: OpenSSL Security Advisory

#53

Post by sitkack »

cm3 wrote: post #29
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 can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we could load a library in another process and make cross-process calls to it.

Re: OpenSSL Security Advisory

#54

Post by adekok »

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.

I maintain a project (http://freeradius.org) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible.

Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code.

All commits MUST build cleanly without warnings on multiple operating systems, and under multiple compilers. We have test cases for a large chunk of the code base. We scan all releases through three different static analysis tools.

Security is important. We make it important because we care. I wish other projects would do the same.

Re: OpenSSL Security Advisory

#55

Post by cm3 »

gbrown_ wrote: post #43
cm3 wrote: post #25

Earlier quoted context omitted.

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.

> a better approach would be for everyone to try to move to what's in BoringSSL Google don't recommend you do this. https://boringssl.googlesource.com/boringssl/ BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. > which deliberately removed most s…

That's right, but I know several project maintainers who are looking moving to it because BoringSSL's scope is smaller and is sufficient for their projects' needs. That's why I think the BoringSSL's API status will evolve with time. And Ring is based on it, so...

Then there's ocaml-tls which aims to provide a drop-in implementation of the OpenSSL API too.

We're finally seeing much activibity, and in that sense, I'm glad that Heartbleed happened, but it should have been earlier :).

Re: OpenSSL Security Advisory

#56

Post by lawnchair_larry »

fredmorcos wrote: post #31
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.

I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not…

I think the the opposite has been shown. It's not really a complaint, it's a reflection on the facts. C is my favorite language, and a spade is a spade.

Re: OpenSSL Security Advisory

#57

Post by willtim »

amenod wrote: post #49
fredmorcos wrote: post #36

Earlier quoted context omitted.

(Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak p…

I would agree with you if it wasn't for Rust. If you don't know it yet, I would advise you read up about it - it is ideal for replacing C, being equal at speed and better at safety from common programming errors.

There are others too, e.g. ATS

Re: OpenSSL Security Advisory

#58

Post by throwaway12344 »

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.

If you don't know what you're talking about, please refrain from commenting. It only proves your ignorance. In the Rails land (as your profile says you are), you wouldn't have these issues, and quite frankly these types of thing seem to be beyond you at this point. You're in no position to criticize the OpenSSL project.

Re: OpenSSL Security Advisory

#59

Post by ygjb-dupe »

sitkack wrote: post #53
cm3 wrote: post #29

Earlier quoted context omitted.

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 can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we coul…

> The single biggest win is if we could load a library in another process and make cross-process calls to it.

What?

Setting aside the fact that this can already be done in numerous different ways on many platforms, how is this a win?

It's hard enough for developers to write correct code, let alone maintaining the correctness of that code while loading and executing unknown code from other parties (see web browsers, and the last 20 years of security bugs related to plugins, extensions, addons, etc).

Re: OpenSSL Security Advisory

#60

Post by danarmak »

bjourne wrote: post #48
danarmak wrote: post #30

Earlier quoted context omitted.

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.

You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)

The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).
Post reply on HN