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

81–90 of 112 posts

Re: OpenSSL Security Advisory

#81

Post by ori_b »

nixos wrote: post #64
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 would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production You're writing on a computer magnitudes faster than the fastest computers of the 70s, with significant compiler improvement to boot. Until about 10 years ago, hand crafted Assembler was still faster than C, and the speed improvements were actually needed. This "let's write…

> Until about 10 years ago, hand crafted Assembler was still faster than C, and the speed improvements were actually needed.

It still is, especially when it comes to vectorization.

Re: OpenSSL Security Advisory

#82

Post by Alupis »

OrpheanBeholder wrote: post #17
throwaway7767 wrote: post #11

Earlier quoted context omitted.

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…

No one is claiming that LibreSSL has fixed all the OpenSSL bugs, the parent certainly didn't. LibreSSL has historically been vulnerable to less of the bugs than OpenSSL and, for a long time, none of the sev:high bugs.

> LibreSSL has historically been vulnerable to less of the bugs than OpenSSL and, for a long time, none of the sev:high bugs.

You say this like LibreSSL has been out for a long time. It's just barely crossed it's 2 year mark... and for most of it's life, it's difficult to call it "production ready".

Coupled with its low adoption rate (really only some select BSD's, and some adventurous linux folks), it's not surprising more vulnerabilities haven't been discovered (yet).

The OpenBSD folks do good work, but let's not pretend they are infallible.

Re: OpenSSL Security Advisory

#83

Post by adekok »

cortesoft wrote: post #62
adekok wrote: post #54

Earlier quoted context omitted.

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. A…

I would posit another reason you don't have as many issues; you don't have as many people trying to find them. I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.

1) Which product is more likely to be secure?

a) one which has tests, no build warnings, and is run through 3 different static analysis tools?

b) one which has none of those things?

2) Also, which of these products is more likely to be secure?

a) one which has a lot of third-party analysis?

b) one which has some third-party analysis?

3) Are these two questions the same?

My answer to (3) is "no".

While best combination of answers would be 1(a) and 2(a), OpenSSL is at 1(b) and 2(a). I'd bet they still have more security issues than FreeRADIUS, which is at 1(a) and 2(b).

That's all I meant.

Re: OpenSSL Security Advisory

#84

Post by astrodust »

cperciva wrote: post #71

OK, now we can go ahead with FreeBSD 11.0-RELEASE. In my time as security officer, it was a rare and surprising occurrence when we didn't need to hold an upcoming release due to a pending OpenSSL advisory. It got to the point of the release engineer saying "I think we're ready to start the release builds tomorrow, any news from OpenSSL" and me replying "nothing yet, but I'm sure it will come" -- their timing was abso…

LibreSSL isn't up to speed yet? http://www.libressl.org

Re: OpenSSL Security Advisory

#85

Post by astrodust »

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…

It's easy to interpret these arguments as "C sucks, let's use Rust" instead of "C is a very mature language with enormously complicated code-bases in play running mission critical software which is not trivially replaced by something like Rust but which could stand to benefit from building things into the compiler to check for mistakes like the Rust compiler does."

Compiling C code is easy, but auditing C code is hard. Getting Rust code to compile without getting berated about every little thing is hard, but at least you're confident then you've got everything right.

Re: OpenSSL Security Advisory

#86

Post by astrodust »

ctz wrote: post #69
fredmorcos wrote: post #31

Earlier quoted context omitted.

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've spent a career of 12 years writing, reviewing and breaking C in high-security products such as HSMs. I'm still to see real world, secure C. Maybe you could point me towards the numerous real world examples of people getting this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote qmail'. (Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of t…

DJB wrote Qmail, then abandoned it like an unwanted child. He might be a good programmer, but he's a really bad maintainer.

OpenSSL was all but abandoned as well. At least now there's a lot of attention being focused on making it better and more maintainable.

There's numerous tire fires out there: ImageMagick, OpenSSL, some Linux kernel drivers, and other projects people just take for granted without pitching in to help fix things.

Re-writing in Rust is a form of helping, and maybe in the process we'll find bugs in the originals or wholesale replace them with something better.

Re: OpenSSL Security Advisory

#87

Post by cperciva »

astrodust wrote: post #84
cperciva wrote: post #71

OK, now we can go ahead with FreeBSD 11.0-RELEASE. In my time as security officer, it was a rare and surprising occurrence when we didn't need to hold an upcoming release due to a pending OpenSSL advisory. It got to the point of the release engineer saying "I think we're ready to start the release builds tomorrow, any news from OpenSSL" and me replying "nothing yet, but I'm sure it will come" -- their timing was abso…

LibreSSL isn't up to speed yet? http://www.libressl.org

It certainly wasn't when I was Security Officer -- it didn't exist yet.

I believe some people are working on bringing libressl into the FreeBSD base system, but there are some challenges; for example, FreeBSD supports stable branches for 5 years, while libressl follows OpenBSD's "break everything once a year" model.

Re: OpenSSL Security Advisory

#88

Post by sctb »

rustywut wrote: post #75
bjourne wrote: post #48

Earlier quoted context omitted.

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. :)

Your points seem valid, I don't know why you're getting downvoted. Butt hurt Rust lovers I guess?

Since this account seems to have been created solely to violate the guidelines with, we've banned it. We're happy to unban accounts if you email hn@ycombinator.com and we believe you'll post only civilly and substantively in the future.

Re: OpenSSL Security Advisory

#89

Post by nly »

ori_b wrote: post #81
nixos wrote: post #64

Earlier quoted context omitted.

>we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production You're writing on a computer magnitudes faster than the fastest computers of the 70s, with significant compiler improvement to boot. Until about 10 years ago, hand crafted Assembler was still faster than C, and the speed improvements were actually needed. This "let's write…

> Until about 10 years ago, hand crafted Assembler was still faster than C, and the speed improvements were actually needed. It still is, especially when it comes to vectorization.

And in other areas, but that's largely because C isn't expressive enough, not because we lack the engineering know-how to compile fast vectorisation code.

Re: OpenSSL Security Advisory

#90

Post by josefx »

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.

> Libraries like that would probably benefit most from using a language with strict static analysis, like Rust.

Wont help when developers then go out of their way to write a large amount of unsafe code. OpenSSL went out of its way to reimplement the C standard library wrong, making it impossible to use with analysis tools like valgrind or a checked malloc and generally confusing developers. iirc it even used malloc(pop)/ free(push) as a stack to pass data around at some point.

Post reply on HN