9 ms·

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,

• tptacek 6y ago
  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.
  • dochtman 6y ago
    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.
    • wglb 6y ago
      Such as?
      • dochtman 6y ago
        Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
        • junon 6y ago
          Any respectable C compiler does this.
          • sshine 6y ago
            Like the one OpenSSL is being compiled with?
          • SubjectToChange 6y ago
            What C compiler has pattern matching and ADTs?
            • junon 6y ago
              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.
      • bluejekyll 6y ago
        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 https://github.com/briansmith/ring
        • tptacek 6y ago
          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.
          • bluejekyll 6y ago
            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.
  • hn8788 6y ago
    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.
    • SAI_Peregrinus 6y ago
      Neither does C. Timing is not considered "observable behavior" in the C standard, so compilers don't have to preserve it.
      • creata 6y ago
        It looks like at least libsodium implements constant-time array comparison in C. https://github.com/jedisct1/libsodium/blob/ae4add868124a32d4e54da10f9cd99240aecc0aa/src/libsodium/sodium/utils.c#L179-L201 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.
        • Arnavion 6y ago
          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 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 https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#259-272 - the impl for u8
        • dfox 6y ago
          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.
          • dvdkhlng 6y ago
            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)
  • bluejekyll 6y ago
    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
• oolonthegreat 6y ago
  "what is essentially a portable assembly language" amen to that :)
• ancarda 6y ago
  >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.
  • tshaddox 6y ago
    I don’t think many people begrudge people who ride horses for fun or write security software in assembly for fun.
  • airhead969 6y ago
    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.
    • ancarda 6y ago
      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.
    • profquail 6y ago
      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.
• rafaelturk 6y ago
  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
  • colejohnson66 6y ago
    > open source code so we can audit it and find bugs Open source didn’t stop Heartbleed
    • zokier 6y ago
      But it did, eventually.
      • eurasiantiger 6y ago
        All bleeds stop eventually.
• airhead969 6y ago
  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.
  • rafaelturk 6y ago
    Can't wait for your PR!
    • ori_b 6y ago
      https://www.libressl.org/ https://www.libressl.org/
      • nightpool 6y ago
        As mentioned down-thread, LibreSSL patched a use-after-free just last week.
      • airhead969 6y ago
        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.
        • ori_b 6y ago
          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.
• 29athrowaway 6y ago
  How else do you expect that national security agencies do their job? :^)
• maerF0x0 6y ago
  Go seems to have it's own SSL lib https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ
  • covid_gopher 6y ago
    that's nice to hear, it is only lacking a proper programming language then
  • maerF0x0 6y ago
    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...
• elwell 6y ago
  What 'til you see a Solidity [0] smart contract... [0] - JS ¯\_(ツ)_/¯
  • vntok 6y ago
    Nonsense. Solidity is a statically-typed programming language.
• jamescun 6y ago
  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.
• dvdkhlng 6y ago
  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... :)
• usefulcat 6y ago
  > 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.
  • kaliszad 6y ago
    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.)
• alerighi 6y ago
  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.
  • anonymousiam 6y ago
    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.
  • pas 6y ago
    > 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. :|
    • vntok 6y ago
      Is Citrix ADC a security library?
      • formerly_proven 6y ago
        It’s a network security appliance - undoubtedly contains multiple security libraries.
• kroeckx 6y ago
  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.
• throwaway823882 6y ago
  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 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.
• Klwohu 6y ago
  Please, don't do this any more. You're not winning any friends and Rust and Go both have serious issues, mainly the sheer bulk, which will ensure they never, EVER make it into certain market segments. Moreover, you come across as an obnoxious, and likely paid astroturfer. Stop telling people to use your silly "safe" software. Who wants to be a part of a community with people like YOU in it?
  • dang 6y ago
    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 https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here, we'd be grateful.