5 ms·

I'm not a low level expert, but I keep seeing mention of bugs related to memory access which have potentially severe security implications and I wonder what ben

I'm not a low level expert, but I keep seeing mention of bugs related to memory access which have potentially severe security implications and I wonder what benefits of whatever C Language dialect is worth this type of risk. If Rust or Haskell really make these issues far less prevalent, why not use them? Genuine question, I know nothing is so simple.

staticassertion 4y ago
Rust is newish, so it just wasn't an option. Haskell carries a heavy runtime around so it's not suitable for a lot of environments, nor is it easy (possible?) to package as a dynamic library. But yeah, for new projects, choose memory safe languages.
chasil 4y ago
One big reason that I know are patents. Elliptic curve was a minefield of patents when Sun Microsystems carefully crafted the OpenSSL implementation to avoid any patent infringement. The resulting source code was vetted by their attorneys. If any of those patents are still in force, then a naive implementation could infringe. "Sun Microsystems has donated ECC code to OpenSSL and the Network Security Services (NSS) library..." https://lwn.net/Articles/174784/ https://lwn.net/Articles/174784/ https://en.m.wikipedia.org/wiki/ECC_patents https://en.m.wikipedia.org/wiki/ECC_patents A lot more attention was likely paid to this code than to heartbleed.
- mattwilsonn888 4y ago
  Wow wasn't aware of that. Its funny to hear and agree with people proclaiming "privacy a right" and have the basic, fundamental technology behind make hairy the implementation of it.
  - chasil 4y ago
    I found out about that a few years ago. If you run "openssl ecparam -list_curves" on a RHEL clone, you will only see p-256, p-384, and e-521 (and e-521 was only added in v7). If you build libressl and run the same command, there are dozens (and Canada doesn't allow software patents, so it's legal there). On OpenBSD 7.1, I see this result: $ openssl ecparam -list_curves | wc -l 102 Note the 2 Oakley curves take up 8 lines. There are also 17 matches in this output for NIST curves.
    - tzs 4y ago
      Canada seems to allow software patents [1]. Amazon got a Canadian patent for their one-click stuff, as mentioned in that Wikipedia article. Here's a Canadian patent on accelerated finite field operations on an elliptic curve [2]. Here's one on public key cryptography using elliptic curves [3]. [1] https://en.wikipedia.org/wiki/Software_patents_under_Canadian_patent_law https://en.wikipedia.org/wiki/Software_patents_under_Canadia... [2] https://brevets-patents.ic.gc.ca/opic-cipo/cpd/eng/patent/2324621/summary.html https://brevets-patents.ic.gc.ca/opic-cipo/cpd/eng/patent/23... [3] https://patents.google.com/patent/CA2129203A1/en https://patents.google.com/patent/CA2129203A1/en
    - zimmerfrei 4y ago
      Probably more related to RHEL compiling openssl in FIPS mode.
      - chasil 4y ago
        No, Red Hat has confirmed that they are leery of patents. https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 Tomas Mraz 2007-10-05 10:23:00 UTC: "They are intentionally removed due to possible patent issues." Bill McGonigle 2013-04-11 06:26:53 UTC: "I've read that Sun's ECC code (that went to OpenSSL) was developed to specifically avoid Certicom patents, but I've only seen that asserted, not proven." Jan-Frode Myklebust 2013-10-07 09:18:49 UTC: "Is this now solved in the RHEL6.5 beta... only the nistp256 and nistp384 curves are supported."
- tptacek 4y ago
  OpenSSL is the reference implementation of TLS, so when teams propose new TLS features (like the heartbeat extension), they tend to add them to OpenSSL. At the time of Heartbleed, OpenSSL got nothing resembling the attention it does today, so it wasn't insane to think that some random proof-of-concept code might find its way in.
  - chasil 4y ago
    If you examine this six year ECC support request, you will see that Sun's code saw legal attention. https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2
jart 4y ago
Really? Are we really going to turn this into a Rust vs. C flamewar when the code in question is most likely Assembly generated by Perl? https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949cdee490ecc1526b2c5509/crypto/aes/asm/aesni-x86.pl#L1 https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949c... In the recent release they changed a `jb` to `jbe` in that file which could be related. It's hard to tell what code is actually the culprit. They had a similar file in Perl which appeared to be for fused-multiply add avx512 that got removed at some point, possibly with a C rewrite, so you could be somewhat right. Either way there really should be more transparency about how what's written in release notes matches up with the code that actually changes between tags.
- dc-programmer 4y ago
  This is horrifying information. I was only aware of the C code that is 99% macros
  - staticassertion 4y ago
    It's not extremely uncommon to find "assembly pushed together by perl" tbh
    - dc-programmer 4y ago
      I believe it. But it makes source coding auditing and static analysis incredibly difficult.
- mattwilsonn888 4y ago
  Ironically this is the most inflammatory response I've seen thus far - not like being emotional makes something more likely to be incorrect anyways...
- yjftsjthsd-h 4y ago
  ... if that summary is materially accurate, then it would make the first occasion on which I would genuinely believe that rewriting a code base purely in C was a security improvement.
barsonme 4y ago
Rewriting something like OpenSSL isn't exactly trivial for many of the same reasons rewriting a large, widely used software library (especially one written in C) isn't trivial. Except in this case you need cryptography experts that are familiar in Rust (or whatever language) to review the code. As a developer you should use prefer libraries written in safer languages (Rust, Go, etc.). But that's not always possible given business/environment/etc constraints.
mlinksva 4y ago
It takes time and resources, but Rust is being used, e.g., https://www.memorysafety.org/initiative/rustls/ https://www.memorysafety.org/initiative/rustls/ which has been being worked on at least 6 years https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=rustls&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... ... I'd hope and guess that resources are increasing, especially as governments realize that software security is their problem too.
tialaramex 4y ago
Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel. https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important. One option if you're working with Rust anyway would be use something like Ring: https://github.com/briansmith/ring https://github.com/briansmith/ring Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance manuals carefully) to write constant time assembly in many cases. In the C / assembly language code of course you do not have any safety benefits. It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.
- jerry1979 4y ago
  What do you think of crates like subtle[1] which bills itself as "Pure-Rust traits and utilities for constant-time cryptographic implementations." [1] https://crates.io/crates/subtle/ https://crates.io/crates/subtle/
  - jcranmer 4y ago
    Speaking as a compiler developer: compilers for standard languages make no attempts to guarantee constant-time properties, nor to provide any primitives that can be used implement constant-time guarantees. Indeed, the developers are likely to be moderately hostile to proposals to add such primitives--it is a pretty different beast if you're worrying about constant-time. As such, if you're using a standard compiler for a language to implement a constant-time guarantee, you need to be doing verification of the resulting assembly to make sure that it actually is constant-time. If you're not doing that, or you're not verifying the generated assembly itself, your constant-time guarantee is not worth the paper it's printed on. Even if it's not even printed on any paper.
ggm 4y ago
You're not wrong, but OpenSSL represents "API/ABI" dependency. People coded to this. OpenSSL is also "s/w by accretion" as people added and removed things over time. The original core, SSLEAY, Was an exemplary instance of somebody outside the core cryptographic community (Eric was, IIRC working as a systems programmer in a psychology department at UQ) -And was hand coded to be both algorithmically faithful to export restrictions (ITAR) and machine code optimisations: it was FAST. The code had to implement both the export restricted brainded reduced keylength and the "illegal to export" algorithms. Peter Guttmans library was known in some ways to be "cleaner" -But didn't gain traction. A lot of OpenSSL is history. Recoding in a type safe language, and with a mind to risks is good. But remember, another attack pattern is differential analysis: Code in crypto has to do some things like present equal cost CPU burden across different paths, to defeat attacks including the side=channel of finding hotspots in the VLSI mask and working out what it does from the leakage of information there. Its complicated. Rust or Haskell Alone, won't make something like OpenSSL inherently risk-free, it may introduce new risks in closing off these ones. Still worth discussing. Just not necessarily a no-brainer.
- zgs 4y ago
  Most problems I've seen have been in the way OpenSSL is used not in OpenSSL itself. Sure OpenSSL has issues but naïve use of cryptography in the wrong way is *far* more prevalent.
dcow 4y ago
There are native TLS implementations in pure Rust and Haskell. They work great, use constant time “subtle” crypto, and are used regularly in the respective communities. OpenSSL is the C library and that’s not likely to change since people still write C.
- yjftsjthsd-h 4y ago
  I was given to understand that one of rust's selling points was the ability to "export" C compatible libraries. Can we "just" backport a crypto library that exposes a mostly openssl-like API+ABI?
  - rapsey 4y ago
    There is a library that provides the openssl C API on top of rustls. I can't find it at the moment however.
nly 4y ago
There are alternatives to OpenSSL written in Rust but, like it or not, OpenSSL already set the defacto standard API used by portable applications. Even alternatives in C or C++ don't get a look in. GnuTLS? Mozilla NSS? Libtls out of openbsd? Libretls port? Nobody cares. Even though the OpenSSL API is terrible, nobody wants to support multiple TLS backends in their application. Particularly if they cross platforms. This is one reason I personally believe standardizing good APIs is more important than implementation.
jmull 4y ago
What are you suggesting, though? Rewrite it in Rust? That might be worth it in the long run, but it would be a considerable effort that would likely take a long time to become a feasible replacement for openssl. E.g., it seems likely to me that it would suffer from more bugs until it reached a certain level of maturity. It would take a focused, long-term, sustained effort by experts to achieve and would still have many ways it could fail. I would guess we'll get a chance to find out if this could work, though. I think someone must be attempting this already. Of course, then the next level of "safe" language will come out, with more guarantees, and we think about rewriting to that. Personally, I think a more productive, much shorter path, would be to use a safe layer on top of the existing C language, and port the existing openssl to that.
adrian_b 4y ago
This memory corruption bug, which is specific to Cannon Lake or newer CPUs with AVX-512, does not appear to have any relationship with the high-level programming language used for OpenSSL. The bug is either in an assembly language sequence, or at most it can be due to incorrect use of compiler intrinsics. Changing the programming language cannot eliminate such bugs. Only either a much more clever compiler, able to use efficiently all the existing instructions implemented by the CPU, thus removing the need for using assembly language, or a much higher-level kind of assembly language, could help against such bugs. A more practical method would be to always use extensive fuzzing tests for all such functions written in assembly language.

staticassertion 4y ago

Rust is newish, so it just wasn't an option. Haskell carries a heavy runtime around so it's not suitable for a lot of environments, nor is it easy (possible?) to package as a dynamic library. But yeah, for new projects, choose memory safe languages.

chasil 4y ago

One big reason that I know are patents. Elliptic curve was a minefield of patents when Sun Microsystems carefully crafted the OpenSSL implementation to avoid any patent infringement. The resulting source code was vetted by their attorneys. If any of those patents are still in force, then a naive implementation could infringe. "Sun Microsystems has donated ECC code to OpenSSL and the Network Security Services (NSS) library..." https://lwn.net/Articles/174784/ https://lwn.net/Articles/174784/ https://en.m.wikipedia.org/wiki/ECC_patents https://en.m.wikipedia.org/wiki/ECC_patents A lot more attention was likely paid to this code than to heartbleed.

mattwilsonn888 4y ago
Wow wasn't aware of that. Its funny to hear and agree with people proclaiming "privacy a right" and have the basic, fundamental technology behind make hairy the implementation of it.
- chasil 4y ago
  I found out about that a few years ago. If you run "openssl ecparam -list_curves" on a RHEL clone, you will only see p-256, p-384, and e-521 (and e-521 was only added in v7). If you build libressl and run the same command, there are dozens (and Canada doesn't allow software patents, so it's legal there). On OpenBSD 7.1, I see this result: $ openssl ecparam -list_curves | wc -l 102 Note the 2 Oakley curves take up 8 lines. There are also 17 matches in this output for NIST curves.
  - tzs 4y ago
    Canada seems to allow software patents [1]. Amazon got a Canadian patent for their one-click stuff, as mentioned in that Wikipedia article. Here's a Canadian patent on accelerated finite field operations on an elliptic curve [2]. Here's one on public key cryptography using elliptic curves [3]. [1] https://en.wikipedia.org/wiki/Software_patents_under_Canadian_patent_law https://en.wikipedia.org/wiki/Software_patents_under_Canadia... [2] https://brevets-patents.ic.gc.ca/opic-cipo/cpd/eng/patent/2324621/summary.html https://brevets-patents.ic.gc.ca/opic-cipo/cpd/eng/patent/23... [3] https://patents.google.com/patent/CA2129203A1/en https://patents.google.com/patent/CA2129203A1/en
  - zimmerfrei 4y ago
    Probably more related to RHEL compiling openssl in FIPS mode.
    - chasil 4y ago
      No, Red Hat has confirmed that they are leery of patents. https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 Tomas Mraz 2007-10-05 10:23:00 UTC: "They are intentionally removed due to possible patent issues." Bill McGonigle 2013-04-11 06:26:53 UTC: "I've read that Sun's ECC code (that went to OpenSSL) was developed to specifically avoid Certicom patents, but I've only seen that asserted, not proven." Jan-Frode Myklebust 2013-10-07 09:18:49 UTC: "Is this now solved in the RHEL6.5 beta... only the nistp256 and nistp384 curves are supported."
tptacek 4y ago
OpenSSL is the reference implementation of TLS, so when teams propose new TLS features (like the heartbeat extension), they tend to add them to OpenSSL. At the time of Heartbleed, OpenSSL got nothing resembling the attention it does today, so it wasn't insane to think that some random proof-of-concept code might find its way in.
- chasil 4y ago
  If you examine this six year ECC support request, you will see that Sun's code saw legal attention. https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2 https://bugzilla.redhat.com/show_bug.cgi?id=319901#c2

jart 4y ago

Really? Are we really going to turn this into a Rust vs. C flamewar when the code in question is most likely Assembly generated by Perl? https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949cdee490ecc1526b2c5509/crypto/aes/asm/aesni-x86.pl#L1 https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949c... In the recent release they changed a `jb` to `jbe` in that file which could be related. It's hard to tell what code is actually the culprit. They had a similar file in Perl which appeared to be for fused-multiply add avx512 that got removed at some point, possibly with a C rewrite, so you could be somewhat right. Either way there really should be more transparency about how what's written in release notes matches up with the code that actually changes between tags.

dc-programmer 4y ago
This is horrifying information. I was only aware of the C code that is 99% macros
- staticassertion 4y ago
  It's not extremely uncommon to find "assembly pushed together by perl" tbh
  - dc-programmer 4y ago
    I believe it. But it makes source coding auditing and static analysis incredibly difficult.
mattwilsonn888 4y ago
Ironically this is the most inflammatory response I've seen thus far - not like being emotional makes something more likely to be incorrect anyways...
yjftsjthsd-h 4y ago
... if that summary is materially accurate, then it would make the first occasion on which I would genuinely believe that rewriting a code base purely in C was a security improvement.

barsonme 4y ago

Rewriting something like OpenSSL isn't exactly trivial for many of the same reasons rewriting a large, widely used software library (especially one written in C) isn't trivial. Except in this case you need cryptography experts that are familiar in Rust (or whatever language) to review the code. As a developer you should use prefer libraries written in safer languages (Rust, Go, etc.). But that's not always possible given business/environment/etc constraints.

mlinksva 4y ago

It takes time and resources, but Rust is being used, e.g., https://www.memorysafety.org/initiative/rustls/ https://www.memorysafety.org/initiative/rustls/ which has been being worked on at least 6 years https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=rustls&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... ... I'd hope and guess that resources are increasing, especially as governments realize that software security is their problem too.

tialaramex 4y ago

Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel. https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important. One option if you're working with Rust anyway would be use something like Ring: https://github.com/briansmith/ring https://github.com/briansmith/ring Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance manuals carefully) to write constant time assembly in many cases. In the C / assembly language code of course you do not have any safety benefits. It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.

jerry1979 4y ago
What do you think of crates like subtle[1] which bills itself as "Pure-Rust traits and utilities for constant-time cryptographic implementations." [1] https://crates.io/crates/subtle/ https://crates.io/crates/subtle/
- jcranmer 4y ago
  Speaking as a compiler developer: compilers for standard languages make no attempts to guarantee constant-time properties, nor to provide any primitives that can be used implement constant-time guarantees. Indeed, the developers are likely to be moderately hostile to proposals to add such primitives--it is a pretty different beast if you're worrying about constant-time. As such, if you're using a standard compiler for a language to implement a constant-time guarantee, you need to be doing verification of the resulting assembly to make sure that it actually is constant-time. If you're not doing that, or you're not verifying the generated assembly itself, your constant-time guarantee is not worth the paper it's printed on. Even if it's not even printed on any paper.

ggm 4y ago

You're not wrong, but OpenSSL represents "API/ABI" dependency. People coded to this. OpenSSL is also "s/w by accretion" as people added and removed things over time. The original core, SSLEAY, Was an exemplary instance of somebody outside the core cryptographic community (Eric was, IIRC working as a systems programmer in a psychology department at UQ) -And was hand coded to be both algorithmically faithful to export restrictions (ITAR) and machine code optimisations: it was FAST. The code had to implement both the export restricted brainded reduced keylength and the "illegal to export" algorithms. Peter Guttmans library was known in some ways to be "cleaner" -But didn't gain traction. A lot of OpenSSL is history. Recoding in a type safe language, and with a mind to risks is good. But remember, another attack pattern is differential analysis: Code in crypto has to do some things like present equal cost CPU burden across different paths, to defeat attacks including the side=channel of finding hotspots in the VLSI mask and working out what it does from the leakage of information there. Its complicated. Rust or Haskell Alone, won't make something like OpenSSL inherently risk-free, it may introduce new risks in closing off these ones. Still worth discussing. Just not necessarily a no-brainer.

zgs 4y ago
Most problems I've seen have been in the way OpenSSL is used not in OpenSSL itself. Sure OpenSSL has issues but naïve use of cryptography in the wrong way is *far* more prevalent.

dcow 4y ago

There are native TLS implementations in pure Rust and Haskell. They work great, use constant time “subtle” crypto, and are used regularly in the respective communities. OpenSSL is the C library and that’s not likely to change since people still write C.

yjftsjthsd-h 4y ago
I was given to understand that one of rust's selling points was the ability to "export" C compatible libraries. Can we "just" backport a crypto library that exposes a mostly openssl-like API+ABI?
- rapsey 4y ago
  There is a library that provides the openssl C API on top of rustls. I can't find it at the moment however.

nly 4y ago

There are alternatives to OpenSSL written in Rust but, like it or not, OpenSSL already set the defacto standard API used by portable applications. Even alternatives in C or C++ don't get a look in. GnuTLS? Mozilla NSS? Libtls out of openbsd? Libretls port? Nobody cares. Even though the OpenSSL API is terrible, nobody wants to support multiple TLS backends in their application. Particularly if they cross platforms. This is one reason I personally believe standardizing good APIs is more important than implementation.

jmull 4y ago

What are you suggesting, though? Rewrite it in Rust? That might be worth it in the long run, but it would be a considerable effort that would likely take a long time to become a feasible replacement for openssl. E.g., it seems likely to me that it would suffer from more bugs until it reached a certain level of maturity. It would take a focused, long-term, sustained effort by experts to achieve and would still have many ways it could fail. I would guess we'll get a chance to find out if this could work, though. I think someone must be attempting this already. Of course, then the next level of "safe" language will come out, with more guarantees, and we think about rewriting to that. Personally, I think a more productive, much shorter path, would be to use a safe layer on top of the existing C language, and port the existing openssl to that.

adrian_b 4y ago

This memory corruption bug, which is specific to Cannon Lake or newer CPUs with AVX-512, does not appear to have any relationship with the high-level programming language used for OpenSSL. The bug is either in an assembly language sequence, or at most it can be due to incorrect use of compiler intrinsics. Changing the programming language cannot eliminate such bugs. Only either a much more clever compiler, able to use efficiently all the existing instructions implemented by the CPU, thus removing the need for using assembly language, or a much higher-level kind of assembly language, could help against such bugs. A more practical method would be to always use extensive fuzzing tests for all such functions written in assembly language.