5 ms·

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

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.

spijdar 6y ago
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 ;-)
tptacek 6y ago
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.
- bluejekyll 6y ago
  Not looking for an argument, just trying to incorporate some more perspective.
  - tptacek 6y ago
    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.

spijdar 6y ago

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 ;-)

tptacek 6y ago

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.

bluejekyll 6y ago
Not looking for an argument, just trying to incorporate some more perspective.
- tptacek 6y ago
  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.