It would be good to know if this vulnerability was related to memory safety before pinning it on memory safety. You can get cryptography just as wrong in Rust or Go.

While this is a true statement, it doesn't feel accurate. Rust's type system offers a significant number of features over that of C beyond just memory safety. These come in the form of safe unions (with Rust enums), Generics with ZeroSizedTypes for ensuring states of computation happen in the proper order, safe destructuring of values such that the wrong field isn't referenced.

Point being, a Rust library that incorporates these type of safety measures can help significantly reduce programming errors beyond just memory safety issues.

If you're looking for me to argue with you that C is an acceptable substitute for languages like Rust and Go, you're barking up the wrong tree. It's not. But that doesn't mean we can simply bucket every vulnerability in a memory-unsafe program as a casualty of memory-unsafety, especially in programs like OpenSSL, which host a large domain of other vulnerabilities that are equally present in Rust and Go code.

Not looking for an argument, just trying to incorporate some more perspective.

Cryptography might be the one single place where I'd look askance at replacing memory-unsafe code with memory-safe de novo implementations. Fortunately, you mostly don't have that dilemma; there are good options in Go and Rust. But a lot of energy goes into auditing the cryptography code in OpenSSL. Certainly, you might reasonably pick OpenSSL over some random high-level implementation nobody is auditing.

That's why I think it's worth calling this out.

Odds are, it's some dumb memory corruption thing. But we don't know yet. OpenSSL sev:hi tends to mean "dubiously exploitable crasher", and good crypto bugs in OpenSSL tend to be sev:med.

Memory errors and the sort of logic errors you described are one source of program errors, but I think the more devious ones are much higher level. There's a general taboo surrounding rolling your own crypto for a reason -- there are too many high level footguns that have nothing to do with raw program logic that can make a crypto system insecure or vulnerable to some kind of exploit, not necessarily relating to the code at all! Problems in randomness, distribution, other things beyond my pay grade.

Rust being higher level will prevent errors, yes, but crypto is hard on a whole other level. It's worth "waiting and seeing" what sort of vuln this is before jumping all in on the rust train this time ;-)

No argument from me that you can easily go wrong in any language, but I would argue that Rust has features other than memory safety that can also assist in building more reliable/secure software.

Such as?

The Rust type system can define parts of the state machine that can help guarantee certain states are true at compile time.

This is very helpful for not using cryptography libraries incorrectly, or not accidentally using the wrong data at different points of implementing functions.

Generally more applicable to higher level use cases, the ring[1] library is a great example of how the algorithms (same impls as OpenSSL) are exposed to end users.

[1]: https://github.com/briansmith/ring

I like Ring but I don't think there's a lot of evidence that Rust's type system has effectively prevented cryptography errors, either in protocol state machines or in primitive implementations.

The challenge in avoiding cryptography mistakes is that you have to understand the errors before you can avoid them. Short of formal analysis with provers, I don't think there's a level of programming rigor that gets you away from most (maybe any?) of the last 10-15 years of (say) {TLS,JWT} bugs.

I look forward to discussing that on the 25th when we have more information.

Evidence of this nature will always be difficult, though, since it’s very difficult to prove a negative. We can only prove that some specific issue hasn’t yet occurred.

Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).

Any respectable C compiler does this.

What C compiler has pattern matching and ADTs?

Every C compiler these days will warn about unchecked enums in switch statements. This is, effectively, what the comment was saying.

Pattern matching has nothing to do with security or program safety.

Like the one OpenSSL is being compiled with?

From what I remember, you can't write a secure cryptography library in pure Rust because it has no guarantees that would stop timing-based vulnerabilities.

Neither does C. Timing is not considered "observable behavior" in the C standard, so compilers don't have to preserve it.

It looks like at least libsodium implements constant-time array comparison in C.

https://github.com/jedisct1/libsodium/blob/ae4add868124a32d4...

Edit: I'm not disagreeing that C compilers are free to optimize stuff like this out; this comment is for people who (like me) thought that serious projects always used assembly for constant time operations.

There's nothing that guarantees that's constant-time. It's just written in a way that's likely to be constant-time, and observed to be constant-time with current compilers, but there's no reason why a specification-compliant compiler couldn't make it variable-time tomorrow.

You can do exactly the same in Rust. Rust isn't any help there, but it doesn't obstruct you either.

We've had code in OpenSSL written in C that was constant time until a newer version of both gcc and clang recognized (mask & a | ~mask & b) as a conditional assign and could do things like turn it into a branch.

Edit: It can turn "b = foo(); c = (mask & a | ~mask & b)" into "if (mask) c = a; else c = foo();"

And indeed the XOR method is also how it's implemented in Rust.

https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#226-244 - the impl for [u8], where the per-element ct_eq is

https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#259-272 - the impl for u8

Which is prime example as to how C does not consider timing to be observable behavior. What the code does is that it tries to specify the operation in sufficiently complex way that makes compiler give up on any optimizations.

Note how this problem of "sufficient complexity" is an asymmetric problem between code author and compiler. A rather simple transformation implemented by the author to make the code constant-time may require NP-hard effort for the compiler to undo.

(but then the compiler may still do other unrelated transformations that end up making the code non-constant time again)

> Can't believe that, in God's year 2021, 3rd millennia, Earth, we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats.

I suppose the flip side of this view is just how easy it is to underestimate what a truly enormous amount of work it would take to completely reimplement all these 'chainsaw juggling feats' that are used all over the place, day in and day out.

This is why we need simple systems above all. That also means having protocols and in general technologies that are as simple as possible while of course being useful. Especially in basic infrastructure, the cost of every new feature should be evaluated as a priority. The cost of bugs also should be considered. Libraries the world basically depends on should be an example how to do these things right.

The reality is, we see constant stream of patches to bugs we know for certain are security related to basically any software we use all the time. Am I the only one to think every such patch should be delivered with sweat running down our backs asking ourself how this could have happened at all in such critical software? Instead we introduce regular patch days, responsible disclosure and other protocols that don't solve the issue itself, that basically our software stacks are not maintainable at all if we are being frank.

In my opinion, we will have no dependable security until a handful of skilled engineers are together able to understand the systems we use fully. One can understand the more low level stuff, the other maybe the middle etc. with some reasonable overlaps so the security of the stack as a whole can be reasonable evaluated and maintained. This is currently just not realistic with any team size, when even the firmware of our CPUs has to be patched constantly. I mean, when you launch e.g. Gmail, who really understands everything from the JavaScript until basically the lowest level firmware in a clients computer? I guess, nobody and not even any team on the planet comes even close to grasping the full depth and breadth of the stack. Therefore the security and other quality related aspects cannot be evaluated without broad oversimplification that really doesn't add anything to the discussion.

If we don't wont to really change our ways, we should at least be frank and say that the software we actually use will never be fully secure, correct or dependable. Just as much as bridges fall, dams break and fallen power-lines create widespread fires we are just not able to handle this stuff reliably. If that is not scary enough, just imagine the software and other infrastructure handling security at nuclear power plants, processing centres and weapons. (And no, engineers are not the only ones having no clue. Doctors, medics etc. don't have a clue either as we see with the pandemic, still unsolved diseases everywhere, even stuff like hearing loss from stress is not understood well.)

The problem is not the language! If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.

The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.

> if there is a bug in a security library nobody dies in the end

The University Hospital Düsseldorf (UKD) in Germany suffered a ransomware attack on September 10, 2020. The attackers exploited a vulnerability in the Citrix ADC that had been known since January but the hospital, unfortunately, had not got around to implementing the fix.

Unfortunately, one patient with a life-threatening illness was diverted to a distant hospital after UKD was deregistered as an emergency care facility. The additional hour’s travel may have been the cause of the patient’s death. On September 18, 2020, German prosecutors launched an official negligent homicide investigation which, if confirmed, would make the patient’s death the first known case of death by hacking.

:|

Is Citrix ADC a security library?

It’s a network security appliance - undoubtedly contains multiple security libraries.

That's like having a field full of mines and then arguing that the field is not dangerous because you have a map of the mines. If you have to develop strict coding standards not just to write reliable code but to avoid the pitfalls of a language that others don't have, then that proves that the language sucks.

We have languages that can provide certain levels of MISRA safety even if you are a novice programmer.Blaming the users for not following the correct guidelines (that barely anyone follows except for the people paid to follow them) completely misses the point.

Planes actually have major portions of the software written in non-C languages such as ADA - see https://www.manufacturing.net/aerospace/news/21175187/airbus...

And are very proud of it. Medical equipment is not all implemented in embedded C systems.

And since modern embedded systems can easily run python or embedded JS versions, well, perhaps certain critical libs can actually get implemented in something that does not deal with memory... and the 5-10% penalty in performance is not going to be something anyone really notes.

Even safety critical software can run reliably for the range of inputs that it's likely to ever see, but contain security holes.

For something like OpenSSL, it must produce a correct output for every single possible input. Even safety critical software may extremely rarely fail in unusual conditions. For security sensitive software though, all it takes is a single possible input that will trigger a bug, because the attacker is not a random process.

Writing secure software in C is extremely difficult.

> The problem is not the language!

It is. A language that lets you write unsafe code is an unsafe language.

> If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.

Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada.

And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario.

> The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones.

Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.

> A language that lets you write unsafe code is an unsafe language.

Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.

Yes, and unsafe Rust is an unsafe language. It's easy enough to detect it's use in a project so that it can be considered a language on it's own.

Static analysis tools should also be a normal part of the development process regardless of the language being used. Unfortunately, the good tools cost money and that discourages developers (and managers) from using them.

Out of interest, when would you say a language at fault for a security problem?

yes, the problem is not the language. The problem is that OpenSSL has just became so important that It shouldn't not rely on C language any more. We have so much better tools now.

As one of the OpenSSL maintainers, I would like to move away from C and probably to rust. But the problem is that C is the most portable language, and rust's platform support just isn't close enough.

We don't know what the vulnerability is yet. Sure it could be a buffer overflow, readily possible in a language like C, or could be a bug in the crypto/implementation itself, no memory safe language will save you there.

so..`yholio` Rants asside what is your valuable contribution to the library or creating a new impecable one? I'm acutally glad we have such powerfull library available for free and using open source code so we can audit it and find bugs

> open source code so we can audit it and find bugs

Open source didn’t stop Heartbleed

But it did, eventually.

All bleeds stop eventually.

"what is essentially a portable assembly language" amen to that :)

I just started wondering, if things were any better if security libraries were written in higher level languages, depending on on a huge run-time support system that is written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory and so on... :)

Please don't break the site guidelines like this, regardless of how wrong another comment is or you feel it is. We ban accounts that do that. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here, we'd be grateful.

How else do you expect that national security agencies do their job? :^)

Go seems to have it's own SSL lib

https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ

I dont see why this is being downvoted, in context of the parent comment

> we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats.

Ok. So I'm pointing out that Go actually doesn't do such a "silly" thing...

What 'til you see a Solidity [0] smart contract...

[0] - JS ¯\_(ツ)_/¯

Nonsense. Solidity is a statically-typed programming language.

>in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex

Do you imagine a future where nobody is able to drive cars? Not even for fun?

I want all serious software that's written in C to be replaced with something like Rust, but I write C for fun. It's fun to do dangerous things. It's just bad to have danger as the modus operandi.

I like doing dangerous things for fun too. (See also: my 50 mph scooter.)

I think we should mitigate risk in serious software in many holistic ways such as formal verification, fuzzing, anomaly detection, good/defensive coding standards, code reviews, and so forth. Such can be accomplished in C, but it maybe easier in languages such as Rust. The advantage of C is ubiquitous portability, which is necessary for widely-used libraries.

Sure, it’s important for a library to have C source code for portability. That doesn’t exclude implementing the code in another language (such as F*/FStar or Dafny) that has stronger out-of-the-box safety guarantees, then compiling it to portable C source code for distribution.

You're right there's a lot of tools out there to help with writing secure code in C. I suppose I feel safer knowing Rust enforces some memory safey, but that isn't guaranteed either -- you could just use unsafe{} blocks everywhere.

I don’t think many people begrudge people who ride horses for fun or write security software in assembly for fun.

1. There is no such thing as a safe or unsafe language. Safety is relative and impossible to guarantee. Even "memory safety" often just means "memory tradeoffs".

2. Inline assembly is often a necessary evil to create implementations of crypto libraries in C... not using it would be worse.

3. It's all machine code under the covers. Whether one developer poorly juggles chainsaws or your high-level language poorly juggles chainsaws is not a question of better or worse, but taste.

4. It's X.509. It sucks in every language.

5. Just because it's in C doesn't mean it sucks. There are alternative libraries that intentionally avoid sucky design. (https://nacl.cr.yp.to/internals.html)

6. Show me another language that's as portable and powerful as C, and cryptographers will probably start using it.

It's swiss-army chainsaw juggling with a kitchen-sink of unnecessary features, bloat, and poor coding hygiene.

C isn't the problem per se, it's the lack of quality, formal rigor, and testing that these slap-dash developers foist on the world. It's a steaming pile, and people wonder why it has security vulnerabilities over and over again. It's doing the same damn thing and expecting a different result: C maybe part of it, but its developers just aren't that great.

Can't wait for your PR!

As mentioned down-thread, LibreSSL patched a use-after-free just last week.

It's a fork of swiss-army chainsaw juggling with training wheels. It is a slowly-dying project because it's not keeping up and distros are dropping it. It's not a viable alternative.

And yet, it's managed to avoid many of the OpenSSL CVEs.

It's not a "viable alternative" because nobody cares enough to test their code against it.