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.
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 things as vulns. More severe stuff still happens, but I'm pretty positive there is a decline in severe issues.
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.
I've almost never seen unnecessary unsafe code being used in Rust. I've seen it very few times for performance, but it's carefully done.
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 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.
So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.
I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice.
Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang.
Non-C SSL implementations in memory-safe languages exist.
Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?
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. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment.
We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.
It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.
This is a false choice. Go and Rust are not replacements for each other. They both have qualities which make each better suited for different environments.
Rust is actually capable of replacing all uses of C, Go's runtime will generally be an impediment to using it in certain cases.
Also I would argue that there are entire classes of bugs that are still available in Go that are not in Rust, that make it less suited for security. Null pointer exceptions, and unchecked errors are the two that come to mind.
This reasoning doesn't make sense. Use a language that makes a bunch of security flaws impossible (barring OS and compiler bugs anyway) so that you can concentrate properly on the possible security flaws left. Why deliberately make life hard for yourself if there are other language choices (assuming there are other choices to C in what you're doing)?
Even the best developers make mistakes. When you're picking your stack for security sensitive work you should be picking the stack that minimises the chance of mistakes and the impact of those mistakes. C is at high risk of making mistakes and those mistakes have a high chance of being exploitable.
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?
That is a preposterous argument.
(Incidentally, I don't have a quarrel with C specifically. All memory-unsafe languages expand the range of terrible vulnerabilities available to the engineer. This is not defensible these days, in my view.)
> So please, pave the road and show us the safer OpenSSL-rust you have.
My contribution here is https://github.com/ctz/rustls
> Kerberos
>broken, obsolete, badly designed, underspecified, dangerous and/or insane
Which list does Kerberos fit in?
So .. progress is being made.
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.
Not to mention I would argue memory exhaustion bugs like this happen in memory safe garbage collected languages frequently too.
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.
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.
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.
I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.
https://www.openssl.org/news/secadv/20160926.txt
<sigh>
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.
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.
With all respect to your project, I bet wider adoption of OpenSSL and consequently more interest from "interested" parties plays a bigger part here.
What an utterly ridiculous thing to say.
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.
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).
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 a text editor which is pretty much an advanced nano/pico in JS and have it take up 145MB" is only possible when everyone has a supercomputer in their hands anyways
It still is, especially when it comes to vectorization.