6 ms·

OpenSSL Security Advisory - 26 Sep 2016

126 points by ctz 10y ago

nikic 10y ago
Thankfully the RCE vulnerability is only in OpenSSL 1.1, which is probably not commonly used yet. Does the second issue imply that OpenSSL does not have any automated tests for the CRL functionality?
chillydawg 10y ago
"woops". Good they caught it fast. Interesting it was from fuzzing rather than direct inspection.
eis 10y ago
I think unfortunately by now it's high time that we get a complete replacement written in a safer language and one that doesn't carry so much old baggage. And no, LibreSSL is no such thing.
- randombit 10y ago
  miTLS is a stack written in annotated F# and definitely a promising step in that direction https://github.com/mitls https://github.com/mitls Unfortunately it doesn't offer a C-compatible ABI as far as I know, so not usable by native code applications.
  - pjmlp 10y ago
    Sure it is usable by native code. F* also has AOT compilers to native code.
    - nickpsecurity 10y ago
      F star compiles to Ocaml or F#. Here's the page on integrating Ocaml and C: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html I'm not sure at a glance how easy it will be to use F star programs in C applications via Ocaml. We'd be better off if there was a compiler from F star to annotated/safe C, Ada/SPARK, or Rust. All of these can integrate more easily into the legacy apps.
- hannesm 10y ago
  There's https://nqsb.io https://nqsb.io - now even with a libtls.so compat layer (you can LD_PRELOAD our libnqsb-tls https://github.com/mirleft/libnqsb-tls https://github.com/mirleft/libnqsb-tls) Being binary compatible with libssl.so is just insane (too many symbols), but obviously doable. Volunteers welcome
  - eis 10y ago
    Unfortunately that website doesn't load for me. Times out trying to connect to port 443. And the travis build bot says that the tls lib fails to build since about a month.
    - hannesm 10y ago
      Looks like we're on a different Interweb, works for me; and travis was a spurious reporting problem, compiles fine (and is now green just to make you happy) :)
  - schwarze_pest 10y ago
    Do you know if there will be a video about this talk at OCaml 2016? https://www.cl.cam.ac.uk/%7Ejdy22/papers/ocaml-inside-a-drop-in-replacement-for-libtls.pdf https://www.cl.cam.ac.uk/%7Ejdy22/papers/ocaml-inside-a-drop... I guess it would pop up there: https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/videos https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/vid...
- pjmlp 10y ago
  The more the merrier, thanks to it systems programing in memory safe languages is picking up support, from Ada getting more visibility in High Integrity Systems, Microsoft talking about their Midori research results[0] or Apple stating their goal with Swift is " Swift is intended as a replacement for C-based languages"[1]. Eventually we get the safety we had in the 90's back and improved. [0] - https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... [1] - https://swift.org/about/ https://swift.org/about/
  - duneroadrunner 10y ago
    Another choice is SaferCPlusPlus[0]. The transition could be done incrementally and the performance would be better than, say, C#. [0] - https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus (Note: shameless plug.)
- schwarze_pest 10y ago
  There is https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls which is used in MirageOS: https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitigation https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitig... https://mirage.io/blog/why-ocaml-tls https://mirage.io/blog/why-ocaml-tls
- OrpheanBeholder 10y ago
  Are you volunteering? Good luck and be sure not to repeat the various vulnerabilities that weren't related to memory safety.
  - eis 10y ago
    I am not volunteering because while being fluent in C, I am not very knowledgeable in the realm of crypto. I'd be stupid to do otherwise. I can still point out that there is a big need for such a project. This is a piece of software that is so core to our computer ecosystem that I am sure plenty of companies would contribute financially and with developer time. Heck, if this couldn't get enough funding for at least 5 fulltime devs plus external audits then we're in a sad state of an ecosystem. IMHO this actually should receive public funding. It would be more useful than many other things that get public funds.
    - OrpheanBeholder 10y ago
      Oh, so you were just blowing a bunch of hot air on the internet, while not offering to do any work and while shitting on the LibreSSL developers who are doing work to make things better.
      - eis 10y ago
        Sigh. Please improve your reading comprehension. I didn't "shit on the LibreSSL developers". Anyways, you sound not like someone one can have a sensible conversation with. So I wont be replying further.
        omginternets 10y ago
        Don't worry, the rest of us get it.
        OrpheanBeholder 10y ago
        Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL. To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.
- adekok 10y ago
  There is a lot of room for improvement in the current OpenSSL code base. Simple cleanups, for one. Code formatting. Removing duplicate code. Static analysis. Unit tests. The OpenSSL maintainers seem to be doing something other than all that. The historical defence for this was that they had minimal funding (which is no longer true), and that the funding they did have was for adding new features. That's just not an acceptable excuse. And it never was an acceptable excuse. Cleaning up code should be part of normal software development. Re-factoring code, adding unit tests, etc. Adding static analysis builds (clang is free, and Coverity is free for open source projects). It's 2016. Why are some people still using software practices from 1992?
  - e40 10y ago
    Has this been suggested to the OpenSSL devs? If so, what did they say? If not, adekok, perhaps you can do that. You are 100% correct here.
    - adekok 10y ago
      That's pretty much what the LibreSSL people have done. And no, they didn't get much response or buy-in.
  - jeltz 10y ago
    They are cleaning up the code, which I noticed when porting PostgreSQL to OpenSSL 1.1 and things were broken all over the place. I just think the code base is very bad to start with and the cleanup just start very recently.
- gbrown_ 10y ago
  The trouble with this isn't the lack of available options (indeed one may argue there are too many). But rather having everyone agree on something with a common API. Also has anything else seen heavy prolonged production usage?
  - aomix 10y ago
    I've read other people make this point. There are a lot of TLS implementations out there but OpenSSL was so synonymous with SSL/TLS for so long that it became a fundamental building block. If an API could be established that lets the-thing-that-does-TLS become a minor detail that's easily configured we'd all be better off. Removing the dependency on OpenSSL is going to be a challenging, messy job. OpenBSD has mostly transitioned over to their LibTLS API but even they had difficulty moving some projects over.
- micro_softy 10y ago
  Why not have a competition to see who can produce an alternative? Similar to the competitions between ciphers. Any language should be allowed. The problem is not necessarily the language. Sometimes it is the programmer, or more often the programmers. What happens when there are too many cooks in the kitchen.
- zzzcpan 10y ago
  What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.
  - pjmlp 10y ago
    - Bounds checking - Type safe enumerations - Strings with guaranteed size (not missing '\0') - No implicit conversions - No undefined behaviour - Validation of null pointers on access - ...
    - zzzcpan 10y ago
      These all can, they just choose not to bother.
    - duneroadrunner 10y ago
      And don't forget "use-after-free" avoidance. (Although technically "undefined behavior" covers a lot.) Also, couldn't distros just provide a version of the library built with the AddressSanitizer[0] enabled as well? It would be slower, but should be much safer. Let the user choose? Not the ultimate solution, but for the short term. [0] https://github.com/google/sanitizers/wiki/AddressSanitizer https://github.com/google/sanitizers/wiki/AddressSanitizer
      - zzzcpan 10y ago
        If they really wanted to make memory-safe C happen, there are already SoftBound+CETS [1] and SAFECode [2] and other approaches. Rewriting all of the C libraries is just not a viable solution. [1] http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ [2] http://sva.cs.illinois.edu/index.html http://sva.cs.illinois.edu/index.html
        duneroadrunner 10y ago
        Yeah, apparently the Tor project considered those first but they weren't able to compile Firefox [1]. And they seem to be abandonware at this point. I didn't immediately find any indication of their performance costs. [1] https://blog.torproject.org/blog/tor-browser-55a4-hardened-released https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...
- a-no-n 10y ago
  A simpler, focused protocol framework and reference implementation with only necessary, useful options... something like that needs actual security people, users in embedded, enterprise, client/server apps would need to agree on it without falling into the trap of being hijacked by special interests, vague edge-cases and feature-creep. The issue would be that it's yet another/different standard, and TLS has most of the de-facto "market-share." That aside, OpenSSL and TLS are terrible because they're so poorly-managed, poorly-tested, poorly-validated, arbitrarily-featured and unplanned. If SSL/TLS is a kitchen-sink, OpenSSL is Home Depot.
aorth 10y ago
TL;DR from the lead developer Rich Salz, on Twitter: openssl 1.1.0a had a use-after-free bug in its fix. :( 1.0.2 had a crash in its fix. :( please update. https://twitter.com/RichSalz/status/780383148236541953 https://twitter.com/RichSalz/status/780383148236541953
Panino 10y ago
I use LibreSSL and just want to thank OpenBSD/LibreSSL devs for their great work. It makes running TLS a lot less stressful for me, so thank you. Also: thanks to Google for finding the bug, via honggfuzz.
mulander 10y ago
http://marc.info/?l=libressl&m=147490843900748&w=2 http://marc.info/?l=libressl&m=147490843900748&w=2 Just a quick note that LibreSSL is not impacted by either of the issues mentioned in the latest OpenSSL security advisory - both of the issues exist in code that was added to OpenSSL in the last release, which is not present in LibreSSL.

126 points by ctz 10y ago

nikic 10y ago

Thankfully the RCE vulnerability is only in OpenSSL 1.1, which is probably not commonly used yet. Does the second issue imply that OpenSSL does not have any automated tests for the CRL functionality?

chillydawg 10y ago

"woops". Good they caught it fast. Interesting it was from fuzzing rather than direct inspection.

eis 10y ago

I think unfortunately by now it's high time that we get a complete replacement written in a safer language and one that doesn't carry so much old baggage. And no, LibreSSL is no such thing.

randombit 10y ago
miTLS is a stack written in annotated F# and definitely a promising step in that direction https://github.com/mitls https://github.com/mitls Unfortunately it doesn't offer a C-compatible ABI as far as I know, so not usable by native code applications.
- pjmlp 10y ago
  Sure it is usable by native code. F* also has AOT compilers to native code.
  - nickpsecurity 10y ago
    F star compiles to Ocaml or F#. Here's the page on integrating Ocaml and C: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html I'm not sure at a glance how easy it will be to use F star programs in C applications via Ocaml. We'd be better off if there was a compiler from F star to annotated/safe C, Ada/SPARK, or Rust. All of these can integrate more easily into the legacy apps.
hannesm 10y ago
There's https://nqsb.io https://nqsb.io - now even with a libtls.so compat layer (you can LD_PRELOAD our libnqsb-tls https://github.com/mirleft/libnqsb-tls https://github.com/mirleft/libnqsb-tls) Being binary compatible with libssl.so is just insane (too many symbols), but obviously doable. Volunteers welcome
- eis 10y ago
  Unfortunately that website doesn't load for me. Times out trying to connect to port 443. And the travis build bot says that the tls lib fails to build since about a month.
  - hannesm 10y ago
    Looks like we're on a different Interweb, works for me; and travis was a spurious reporting problem, compiles fine (and is now green just to make you happy) :)
- schwarze_pest 10y ago
  Do you know if there will be a video about this talk at OCaml 2016? https://www.cl.cam.ac.uk/%7Ejdy22/papers/ocaml-inside-a-drop-in-replacement-for-libtls.pdf https://www.cl.cam.ac.uk/%7Ejdy22/papers/ocaml-inside-a-drop... I guess it would pop up there: https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/videos https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/vid...
pjmlp 10y ago
The more the merrier, thanks to it systems programing in memory safe languages is picking up support, from Ada getting more visibility in High Integrity Systems, Microsoft talking about their Midori research results[0] or Apple stating their goal with Swift is " Swift is intended as a replacement for C-based languages"[1]. Eventually we get the safety we had in the 90's back and improved. [0] - https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... [1] - https://swift.org/about/ https://swift.org/about/
- duneroadrunner 10y ago
  Another choice is SaferCPlusPlus[0]. The transition could be done incrementally and the performance would be better than, say, C#. [0] - https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus (Note: shameless plug.)
schwarze_pest 10y ago
There is https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls which is used in MirageOS: https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitigation https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitig... https://mirage.io/blog/why-ocaml-tls https://mirage.io/blog/why-ocaml-tls
OrpheanBeholder 10y ago
Are you volunteering? Good luck and be sure not to repeat the various vulnerabilities that weren't related to memory safety.
- eis 10y ago
  I am not volunteering because while being fluent in C, I am not very knowledgeable in the realm of crypto. I'd be stupid to do otherwise. I can still point out that there is a big need for such a project. This is a piece of software that is so core to our computer ecosystem that I am sure plenty of companies would contribute financially and with developer time. Heck, if this couldn't get enough funding for at least 5 fulltime devs plus external audits then we're in a sad state of an ecosystem. IMHO this actually should receive public funding. It would be more useful than many other things that get public funds.
  - OrpheanBeholder 10y ago
    Oh, so you were just blowing a bunch of hot air on the internet, while not offering to do any work and while shitting on the LibreSSL developers who are doing work to make things better.
    - eis 10y ago
      Sigh. Please improve your reading comprehension. I didn't "shit on the LibreSSL developers". Anyways, you sound not like someone one can have a sensible conversation with. So I wont be replying further.
      - omginternets 10y ago
        Don't worry, the rest of us get it.
      - OrpheanBeholder 10y ago
        Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL. To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.
adekok 10y ago
There is a lot of room for improvement in the current OpenSSL code base. Simple cleanups, for one. Code formatting. Removing duplicate code. Static analysis. Unit tests. The OpenSSL maintainers seem to be doing something other than all that. The historical defence for this was that they had minimal funding (which is no longer true), and that the funding they did have was for adding new features. That's just not an acceptable excuse. And it never was an acceptable excuse. Cleaning up code should be part of normal software development. Re-factoring code, adding unit tests, etc. Adding static analysis builds (clang is free, and Coverity is free for open source projects). It's 2016. Why are some people still using software practices from 1992?
- e40 10y ago
  Has this been suggested to the OpenSSL devs? If so, what did they say? If not, adekok, perhaps you can do that. You are 100% correct here.
  - adekok 10y ago
    That's pretty much what the LibreSSL people have done. And no, they didn't get much response or buy-in.
- jeltz 10y ago
  They are cleaning up the code, which I noticed when porting PostgreSQL to OpenSSL 1.1 and things were broken all over the place. I just think the code base is very bad to start with and the cleanup just start very recently.
gbrown_ 10y ago
The trouble with this isn't the lack of available options (indeed one may argue there are too many). But rather having everyone agree on something with a common API. Also has anything else seen heavy prolonged production usage?
- aomix 10y ago
  I've read other people make this point. There are a lot of TLS implementations out there but OpenSSL was so synonymous with SSL/TLS for so long that it became a fundamental building block. If an API could be established that lets the-thing-that-does-TLS become a minor detail that's easily configured we'd all be better off. Removing the dependency on OpenSSL is going to be a challenging, messy job. OpenBSD has mostly transitioned over to their LibTLS API but even they had difficulty moving some projects over.
micro_softy 10y ago
Why not have a competition to see who can produce an alternative? Similar to the competitions between ciphers. Any language should be allowed. The problem is not necessarily the language. Sometimes it is the programmer, or more often the programmers. What happens when there are too many cooks in the kitchen.
zzzcpan 10y ago
What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.
- pjmlp 10y ago
  - Bounds checking - Type safe enumerations - Strings with guaranteed size (not missing '\0') - No implicit conversions - No undefined behaviour - Validation of null pointers on access - ...
  - zzzcpan 10y ago
    These all can, they just choose not to bother.
  - duneroadrunner 10y ago
    And don't forget "use-after-free" avoidance. (Although technically "undefined behavior" covers a lot.) Also, couldn't distros just provide a version of the library built with the AddressSanitizer[0] enabled as well? It would be slower, but should be much safer. Let the user choose? Not the ultimate solution, but for the short term. [0] https://github.com/google/sanitizers/wiki/AddressSanitizer https://github.com/google/sanitizers/wiki/AddressSanitizer
    - zzzcpan 10y ago
      If they really wanted to make memory-safe C happen, there are already SoftBound+CETS [1] and SAFECode [2] and other approaches. Rewriting all of the C libraries is just not a viable solution. [1] http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ [2] http://sva.cs.illinois.edu/index.html http://sva.cs.illinois.edu/index.html
      - duneroadrunner 10y ago
        Yeah, apparently the Tor project considered those first but they weren't able to compile Firefox [1]. And they seem to be abandonware at this point. I didn't immediately find any indication of their performance costs. [1] https://blog.torproject.org/blog/tor-browser-55a4-hardened-released https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...
a-no-n 10y ago
A simpler, focused protocol framework and reference implementation with only necessary, useful options... something like that needs actual security people, users in embedded, enterprise, client/server apps would need to agree on it without falling into the trap of being hijacked by special interests, vague edge-cases and feature-creep. The issue would be that it's yet another/different standard, and TLS has most of the de-facto "market-share." That aside, OpenSSL and TLS are terrible because they're so poorly-managed, poorly-tested, poorly-validated, arbitrarily-featured and unplanned. If SSL/TLS is a kitchen-sink, OpenSSL is Home Depot.

aorth 10y ago

TL;DR from the lead developer Rich Salz, on Twitter: openssl 1.1.0a had a use-after-free bug in its fix. :( 1.0.2 had a crash in its fix. :( please update. https://twitter.com/RichSalz/status/780383148236541953 https://twitter.com/RichSalz/status/780383148236541953

Panino 10y ago

I use LibreSSL and just want to thank OpenBSD/LibreSSL devs for their great work. It makes running TLS a lot less stressful for me, so thank you. Also: thanks to Google for finding the bug, via honggfuzz.

mulander 10y ago

http://marc.info/?l=libressl&m=147490843900748&w=2 http://marc.info/?l=libressl&m=147490843900748&w=2 Just a quick note that LibreSSL is not impacted by either of the issues mentioned in the latest OpenSSL security advisory - both of the issues exist in code that was added to OpenSSL in the last release, which is not present in LibreSSL.