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

101–110 of 112 posts

Re: OpenSSL Security Advisory

#101

Post by ori_b »

nly wrote: post #89
ori_b wrote: post #81

Earlier quoted context omitted.

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

I am not aware of a general purpose language that is expressive enough to auto vectorize generic code without basically writing in vector intrinsics.

Re: OpenSSL Security Advisory

#102

Post by [deleted] »

nly wrote: post #89
ori_b wrote: post #81

Earlier quoted context omitted.

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

[deleted]

Re: OpenSSL Security Advisory

#103

Post by cperciva »

tedunangst wrote: post #100
cperciva wrote: post #87

Earlier quoted context omitted.

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.

Could be biased, but I think we're more careful about bundling breaking changes in security patches though.

If you try at all, then you're trying harder than OpenSSL. But that doesn't necessarily help if there has been so much code churn over the past 5 years that we can't figure out how or if we should apply the security patch.

Re: OpenSSL Security Advisory

#104

Post by autognosis »

chrismonsanto wrote: post #92
banachtarski wrote: post #78

Earlier quoted context omitted.

> Use a language that makes a bunch of security flaws impossible The implicit assumption here is that the language isn't at the same time introducing a number of other vulnerabilities. Is there a language you would like to suggest?

"Actually, more static analysis makes things less secure" That is a preposterous argument.

I agree. But who are you talking to? I didn't see that argument made.

Re: OpenSSL Security Advisory

#105

Post by ninja-wannabe-7 »

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's too easy to just blame C, it's their slap-dash, design-by-committee kitchen-sink features, lack of process, absense of rigor and generally amateurish "engineering," if it can be called that, of a now critical security framework. Why isn't every release first run through valgrind tools and some commercial C bug-finding tools used by embedded / safety-critical systems and why aren't there proofs of it's correctness? They have and/or could get the money/resources.

Re: OpenSSL Security Advisory

#106

Post by ben_bai »

wbl wrote: post #97
bjourne wrote: post #95

Earlier quoted context omitted.

Integer overflow checking, for example.

Integer overflow cannot result in memory safety violations in Rust.

But it can overflow, which will result in a different value that the programmer might expect, which can give an attacker a nice "information leak" or worse. This could be a security bug!

Re: OpenSSL Security Advisory

#107

Post by seanwilson »

banachtarski wrote: post #78
seanwilson wrote: post #35

Earlier quoted context omitted.

> 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 attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. This reasoning doesn't make s…

> Use a language that makes a bunch of security flaws impossible The implicit assumption here is that the language isn't at the same time introducing a number of other vulnerabilities. Is there a language you would like to suggest?

I'd wager the vast, vast majority of Java, Python and OCaml projects would have significantly less security exploits compared to an equivalent C project. Simply making buffer overflows impossible (as much as they can be) takes a huge burden away from you.

Re: OpenSSL Security Advisory

#108

Post by gajjanag »

ben_bai wrote: post #106
wbl wrote: post #97

Earlier quoted context omitted.

Integer overflow cannot result in memory safety violations in Rust.

But it can overflow, which will result in a different value that the programmer might expect, which can give an attacker a nice "information leak" or worse. This could be a security bug!

Exactly. Memory safety is a very nice property, but is not complete by itself. This primary emphasis on memory safety was part of a critique of Rust by Andrei Alexandrescu: https://www.quora.com/Which-language-has-the-brightest-futur....

And even wrt memory, Rust (with the standard library) is not free of its own warts, see the OOM situation. See e.g https://news.ycombinator.com/item?id=10545877 for a discussion on this.

Just to be clear: I generally like the ideas of Rust. I just dislike its presentation by some as a magic solution to all kinds of concerns.

Re: OpenSSL Security Advisory

#109

Post by ComodoHacker »

adekok wrote: post #54
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. A…

>Why? We have a requirement for code quality.

With all respect to your project, I bet wider adoption of OpenSSL and consequently more interest from "interested" parties plays a bigger part here.

Re: OpenSSL Security Advisory

#110

Post by adekok »

ultramancool wrote: post #79
cortesoft wrote: post #62

Earlier quoted context omitted.

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.

There's definitely some truth to this, FreeRADIUS is just not that valuable of a target since not many people have RADIUS exposed to the world, however if you look at other highly valuable targets like OpenSSH, which is probably in the top 10 if not the most valuable target in the world, you see far fewer significant exploits. It's definitely possible to have better quality than OpenSSL and a lot of OpenSSL's issues…

For the record, the fixes for that CVE contain new CVEs.

https://www.openssl.org/news/secadv/20160926.txt

No one can reasonably say that the practices of the OpenSSL programmers result in secure code. No one can reasonably say that lots of people examining it later for defects is a good idea.

We have lots of legacy code in C. The only sane way to maintain it is tests: unit tests, functional tests, and static code analysis.

> a lot of OpenSSL's issues are due to legacy code

i.e. the OpenSSL people don't care to actively maintain / clean up their software.

What a depressing statement to make.

Post reply on HN