13 ms·

OpenSSL Security Advisory

259 points by FiloSottile 10y ago

FiloSottile 10y ago
Patch: https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb https://github.com/openssl/openssl/commit/70428eada9bc4cf314... Advisory mirror: https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa2009a891490 https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa200... Preliminary analysis: https://news.ycombinator.com/item?id=11621038 https://news.ycombinator.com/item?id=11621038
- CiPHPerCoder 10y ago
  But it no longer checked that there was enough data to have both the MAC and padding bytes. ... I am beyond words.
  - pjmlp 10y ago
    Just the C usual stuff, but good bone coders use all the warnings and analyzers from gcc and clang and never commit such errors.
    - adrianN 10y ago
      I'm not sure whether you are sarcastic or not, but to me the seemingly endless amount of this kind of bug in high profile projects like OpenSSL is pretty good proof that nobody can write secure C.
      - Sir_Cmpwn 10y ago
        Just because a projcet is high profile doesn't mean it's well managed or well written.
        mokus 10y ago
        All the more reason not to rely on security properties of code written in C - I don't have time to read and understand the source of every piece of software I use, and popularity is completely useless as a proxy for code quality. Being written in a memory-safe language isn't a silver bullet for all problems, but it actually _is_ a silver bullet for memory corruption problems. Memory corruption problems are a bit like infant mortality in the history of the medical profession - people that live past infancy still died, but infant deaths overwhelmingly impact the historical life expectancy statistics. Let's get our industry past the dark ages so we can start to live longer and begin to tackle more interesting causes of death. EDIT: fixed very silly typo (which I'm really surprised i wasn't instantly called on - it basically made me say I wasn't willing to understand my own code. thanks for the generous reading!)
        Sir_Cmpwn 10y ago
        There are plenty of codebases (including large ones) written in C that have a low number of vulnerabilities, even compared to projects written in higher level languages (setting aside Rust et al because they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. OpenSSL has louder vulnerabilities than most software because it's (1) very old, (2) very bad code, and (3) relied upon by heaps of software. There are lots of things wrong with OpenSSL, and those are the reasons that it's vulnerable. We should address the real issues instead of using C as a scapegoat.
        pjmlp 10y ago
        > It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. I have been reading about this mythical "skilled C programmer" since I got to learn C in 1993 and eventually joined C++ ranks instead, leaving my favorite Turbo Pascal behind. Never met one to this day, but fixed lots of memory corruption issues left behind by not so skilled ones, during the days I used to work daily with C and C++ codebases.
        10y ago
      - CiPHPerCoder 10y ago
        What about https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium then? Very high profile, no CVEs found to date. EDIT: Can't respond to lambda below. I was responding to THIS assertion, not proposing libsodium as a general purpose openssl replacement: "nobody can write secure C." To which I said, here's a project that's written in C that's apparently secure.
        lambda 10y ago
        It also doesn't interoperate with any widely deployed crypto standards. Yes, NaCL is a better design for cryptographic primitives, being much more limited in scope and reducing the number of primitives supported. It's great, if you can control both sides of the protocol so you can use something like this, and if you can also write your own safe, secure protocol code on top of it that doesn't introduce any errors of its own. The problem being solved by OpenSSL is much harder; for interoperability, you need to support a much wider range of standards, and they are always changing. It also supplies the full protocol stack to implement TLS, including multiple versions of TLS, rather than just the crypto primitives. It's when you have code that is trying to do all of this, and evolve over time, with contributions from multiple people, that it's easy for such mistakes to creep in. Writing a single piece of code in C with no vulnerabilities is hard, but not impossible; maintaining such a piece of code, implementing complex and changing standards, over time, over a variety of platforms, and so on, without introducing vulnerabilities, does seem to be impossible in C.
        tptacek 10y ago
        Not interoperating with TLS's CBC construction is a feature, not a liability.
        nickpsecurity 10y ago
        Almost always by super-human's, though. These people that can do in programming what most people can't do across the board. Including write C code with almost no defects. Now, what about mere humans with average or above average intelligence? What about us!? We can't be basing our expectations of what most can do with garbage like C on what the mental elite can pull off.
      - pjmlp 10y ago
        Of course I am being sarcastic, you just need to check my other posts. :) The point being, that in spite of what everyone says, not even with the help of the best tools to detect memory corruption issues in C, developers write memory corruption free code in it.
        jjnoakes 10y ago
        Are the openssl developers using the "best tools to detect memory corruption issues in C"? In my experience, most open source projects don't devote the money or time to use, understand, deploy, and ensure such tools are used and the issues they find are resolved.
        nickpsecurity 10y ago
        Actually, I think they're using the best tools to create memory corruption issues in C. There could in fact be a slow-moving fuzzer in their build system that transforms safe C constructs into unsafe ones before release. It's random and hits one thing at a time. Probably borrowed from mutation component of a genetic algorithm toolkit. I won't speculate if lack of focus or quality could indicate rest of OpenSSL code was produced by genetic algorithms.
        pjmlp 10y ago
        I know C since 1993 and C++ since 1994. Used C++ extensively during those years up to 2006. C only when required to do so for university assignments or customers. On one of my employers, I was one of the few developers that bordered using VC++ debugging libraries for memory allocation and Insure++. It is not a matter of tooling being available, many don't use them even when they can.
      - pfg 10y ago
        Not sure if I'm missing something, but does the padding oracle really have anything to do with the code being written in C?
        muricula 10y ago
        I could be mistaken but I think that the padding Oracle is possible because of a buffer overflow.
      - 27182818284 10y ago
        > is pretty good proof that nobody can write secure C. I came to that same conclusion. I used to almost romanticize C programmers years ago, but years and years of reading things like this have changed my mind.
      - ArkyBeagle 10y ago
        Where I work, you won't last long with too many memory overwrite bugs. There is no such... evolutionary feedback in open source.
      - SomeCallMeTim 10y ago
        >proof that nobody can write secure C. No, it just takes a good developer to write secure C. See: Qmail [1], which in 20 years only four bugs have been found, and only one of those was a potential security bug. Or djbdns [2]; similar lack of security holes despite being faster and safer than Bind. It's far easier to write code in C than it is to write good code in C. It's a downside of the security of open source projects that the contributors are those who care enough to volunteer who can contribute code, rather than restricting the team, or at least those who can approve code going into the core, to vetted experts. I'm a good developer, but far from the best, and glancing through the OpenSSL code that I've seen, I would never have approved most of it in code review. There needs to be someone at least as good as I am reviewing every last line of code submitted to OpenSSL. Even better if it were someone much better than I. [1] https://en.wikipedia.org/wiki/Qmail https://en.wikipedia.org/wiki/Qmail [2] http://cr.yp.to/djbdns/guarantee.html http://cr.yp.to/djbdns/guarantee.html
    - tveita 10y ago
      That doesn't look like a C specific error to me. In the release notes CVE-2016-2107 is listed as a padding oracle attack. Padding oracles are a logic/design error that is not easily caught by any language feature. CVE-2016-2108 on the other hand looks like a typical C style memory corruption bug.
petecooper 10y ago
Not working here -- likely hugged to death -- so Google cache: https://webcache.googleusercontent.com/search?q=cache:I3M170FkOTUJ:https://www.openssl.org/news/secadv/20160503.txt+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:I3M170... Edit: spelling.
- greglindahl 10y ago
  Or the Internet Archive: https://web.archive.org/web/20160503160435/https://www.openssl.org/news/secadv/20160503.txt https://web.archive.org/web/20160503160435/https://www.opens...
roddux 10y ago
Memory Issues: Episode III - Revenge Of The Buffer Overflow (2016) In all seriousness, repeated occurrences such as these should make people consider other languages for new projects. Despite being quite a C fanboy, I have to admit that even I think manual memory management should be a thing of the past now.
- pjmlp 10y ago
  The sad part is that already in the mid-60's and 70's, in computers much less powerful than the PDP-11, bounds checking wasn't a problem as such. In the few cases where it was a real problem for the application being written, it could be selectively disabled. Which according to C.A.Hoare in his 1981 speech, most people didn't want to do anyway. It only became a problem in the industry thanks to C.
  - krylon 10y ago
    Having written C for a living for about two years, I have to admit that a large part of me really likes C. But also, I would have commited unspeakable acts just to have a compiler switch to enable bounds checking, no matter how badly that would have affected performance. Even when one knows what one is doing - or thinks so, anyway - these errors are so easy to sneak in and such a pain to track down. (Especially since we were using OpenWatcom whose debugger did not show useful data when the program crashed, which is usually the time one needs it the most...)
    - ghrifter 10y ago
      Just curious - what do you do for a living that means you have to write C? I'm interested in really learning C or C++ more indepthly. I feel like I am very proficient in high level programming knowledge (other than design patterns). Basically, when or if the web dev industry falls out, I want to have a good back up of knowing low-level languages.
      - stephen_g 10y ago
        Anything in embedded systems. I write code for high performance satellite terminal (ground side) and also point-to-point radio systems (ultra-low latency, millimetre wave stuff). 90% of the code I write is in C, about 60% of the time on microcontrollers with <256KB of RAM, and the rest in a cut-down Linux running on an ARM Cortex A8. I'd actually prefer to use C++ for the Linux stuff (std::string, smart pointers and STL containers would save me so much time), but we don't have the C++ standard library in our custom distro.
Filligree 10y ago
These are all errors that would be impossible in a language with, oh, bounds checking. There may be ranges of security-critical code that make sense to write in C, for example ensuring that algorithms run in constant time, although with modern compilers I have difficulty trusting that the compiler won't accidentally optimize away the constant-time-ness. Surely ASN.1 encoding isn't part of that range, however?
- pjmlp 10y ago
  Hoare quote during Turing award in 1981: "The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R. Hoare, Communications of the ACM, 1981
  - codezero 10y ago
    Making it illegal to write code without bounds checking is an interesting and fun concept to imagine.
    - masklinn 10y ago
      Why? That's how the vast majority of modern languages work. You can't opt out of bounds checking in Java or Python.
solarengineer 10y ago
Does anyone know if there is an SSL specification somewhere? One could then start to write tests at various levels to ensure compliance with the specification. This test suite could then be considered a compatibility test suite as well.
- CiPHPerCoder 10y ago
  There are numerous RFCs, yes.
- theandrewbailey 10y ago
  The SSL spec (if you can call it that) and everything it depends on is spread over about a dozen or so RFCs. Good luck.
- IgorPartola 10y ago
  This has been discussed to death, and the conclusion is generally that testing for unknown security bugs is not possible (or at least not practical).
- lmm 10y ago
  The spec generally only specifies the correct behaviour, not what the program should be doing with e.g. malformed ASN.1.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
jbaviat 10y ago
One of the two issues was interestingly found using Clang fuzzing capabilities. This is in-process fuzzing, that Clang libFuzzer makes quite easy: http://blog.llvm.org/2015/04/fuzz-all-clangs.html http://blog.llvm.org/2015/04/fuzz-all-clangs.html http://llvm.org/docs/LibFuzzer.html http://llvm.org/docs/LibFuzzer.html
- ashitlerferad 10y ago
  Another fuzzer, quite amazing one actually (it managed to create PNG/JPEG images from fuzzing). http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
  - jbaviat 10y ago
    The (truly amazing) lcamtuf blog post you are referring to is this one: http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin-air.html http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin...
mcs 10y ago
ASN.1 parsing in implementations of several different standards have had this class of issue for well over a decade. ip phone and software stack vulnerabilities in, for example in asterisk, specifically for ASN.1 handling have probably been used by our intelligence community for a long time. The safe implementations are probably ran in virtual machine languages.
- cyphar 10y ago
  I think we should all agree to move from ASN.1 as quickly as possible. Many implementations don't include some of the wacky features (like recursive serialisation of structures), because nobody needs them and they cause bugs. But there is so much more weirdness in ASN.1 that it would honestly be much nicer if we used JSON (as an example of the other extreme). Maybe there's a nice binary, typed format which doesn't resemble the 80s we should be using.
  - lmm 10y ago
    Thrift/Protobuf/etc. are reasonably nice IME.
    - cyphar 10y ago
      The cool thing about protobuf is that it allows automated parser generation (that isn't some horrific hack built on bison). The downside is that if there's a bug in someone else's code, it becomes a bug in your code. :D
  - zeveb 10y ago
    This is why the SPKI guys, seventeen years ago, made one of their design goals not using ASN.1: https://tools.ietf.org/html/rfc2692 https://tools.ietf.org/html/rfc2692 states 'No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.' They came up with a simple, beautiful representation for certificates. They also came up with a simple, logic, understandable way to think about what certificates can and cannot do. The world ignored them. RFCs 2692 & 2693 stand as a remarkable example of what could have been.
FiloSottile 10y ago
My understanding of the padding oracle vulnerability so far, mainly from the patch [0]: it's possible to make a "valid" message that has the pad length byte higher than maxpad (total_length - digest_length - 1) [1]. If you make it high enough, I think you'll push the offset used in the constant time comparison masks enough below 0 to entirely skip the MAC check [2]. But then your entire plaintext will have to match the pad byte to pass the check, and I think you can use that as a padding oracle. In other words, constant time programming, which by definition means that you have to behave normally even if your offsets go negative, is HARD. (And when you don't put comments ANYWHERE, it's even harder.) [0]: https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb https://github.com/openssl/openssl/commit/70428eada9bc4cf314... [1]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L583 https://github.com/openssl/openssl/blob/70428eada9bc4cf31424... [2]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L742-L766 https://github.com/openssl/openssl/blob/70428eada9bc4cf31424... For the record, there is nothing Go or Rust could have done here. The bug is caused by having to write code that runs in constant time, by employing masks and behaving in exactly the same way irrespective of the pad value. If you want to blame the design of something, blame Mac-then-Encrypt in TLS 1.0. See also The Cryptographic Doom Principle [3]. [3]: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/ EDIT: Interestingly, this was found with TLS-attacker [4], a new framework to analyze, test and attack TLS libraries. Finding it was probably "just" a matter of sending a plaintext made entirely of the same right byte value, and noticing that the MAC check passes when it should not. However, so far we didn't have any tool or testsuite (which I'm aware of) to perform this kind of checks. [4]: https://github.com/RUB-NDS/TLS-Attacker https://github.com/RUB-NDS/TLS-Attacker IMPACT [EDIT]: to sum up, if a client uses AES-CBC to connect to a server with AES-NI support, a MitM can recover at least 16 bytes of anything it can get the client to send repeatedly, together with attacker-controlled data (think Cookies or such, using Javascript cross-origin requests).
- tptacek 10y ago
  That's a second-order padding attack, in the same sense that an integer overflow most often creates a second-order buffer overflow: a first bug transitions your program to a state where a second bug --- very exploitable, and one the program tried to guard against --- is revealed. What's interesting about crypto to me is the prospect that every common crypto flaw has second- and third- order variants that we will not find out about for many years, the same way we've barely now got a grip on the interaction between C integers and buffer counting.
zymhan 10y ago
It's not a great bug, but I think it would require a very particular set of circumstances to arise: > ... only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL's default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities. However it does seem like a great exploit method for malware, using legit signed certificates that allow overwriting memory just by parsing the cert.
jjawssd 10y ago
What's the status of this bug for LibreSSL? (LibreSSL is used in OS X 10.11+)
- jlgaddis 10y ago
  Saw a tweet from one of the OpenBSD folks saying LibreSSL was also affected by these issues and fixes would be available today. Sorry, not on my laptop at the moment so I can't post a link. ETA: Source code [0] and binary [1] patches (via M-Tier) are available for OpenBSD. [0]: https://marc.info/?l=openbsd-tech&m=146228598730414&w=2 https://marc.info/?l=openbsd-tech&m=146228598730414&w=2 [1]: https://stable.mtier.org/ https://stable.mtier.org/
- slasaus 10y ago
  OpenSSL announced several issues today that also affect LibreSSL. - Memory corruption in the ASN.1 encoder (CVE-2016-2108) - Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) - EVP_EncodeUpdate overflow (CVE-2016-2105) - EVP_EncryptUpdate overflow (CVE-2016-2106) - ASN.1 BIO excessive memory allocation (CVE-2016-2109) Thanks to OpenSSL for providing information and patches. http://marc.info/?l=openbsd-announce&m=146228598930416&w=2 http://marc.info/?l=openbsd-announce&m=146228598930416&w=2 https://twitter.com/bob_beck/status/727478594591543296 https://twitter.com/bob_beck/status/727478594591543296
- deleted 10y ago
  [deleted]
kafka99 10y ago
Looks like the "negative zeroes" patch (commit in https://mta.openssl.org/pipermail/openssl-commits/2015-April/000906.html https://mta.openssl.org/pipermail/openssl-commits/2015-April...) was never introduced in debian and ubuntu?
- kafka99 10y ago
  I was indeed right :( The danger of only backporting security fixes. But it's in the patch now: http://www.ubuntu.com/usn/usn-2959-1/ http://www.ubuntu.com/usn/usn-2959-1/
nickpsecurity 10y ago
ASN.1 is so well-understood at this point that Galois even has a high-assurance toolkit for it: http://cps-vo.org/node/1577 http://cps-vo.org/node/1577 Maybe someone should forward that to OpenSSL team and suggest they pay Galois to crank out a bunch of encoders/decoders for them for anything requiring that in OpenSSL. Or LANGSEC people behind HAMMER toolkit. Or even the Cap n Proto guy. Seriously, the number of preventable failures in this software, esp memory, is a strong indicator of why you should never use it.
- peterwwillis 10y ago
  > Maybe someone should forward that to OpenSSL team and suggest they pay Galois Here's where you can donate your money to pay Galois: https://www.openssl.org/support/donations.html https://www.openssl.org/support/donations.html Once they've received the funds i'm sure they'll get right on it.
  - nickpsecurity 10y ago
    Lol. I thought they've had money all this time and not spent it on stuff that works. Meanwhile, LibreSSL did more in a few weeks for their code quality than its owners did in a year. Why would I give them money expecting something different? The right course, if we're talking Galois, is for them to try to ask Galois to donate some time or tooling to improve critical aspects of a widespread-deployed library. They already make money with grants and stuff for code they often open-source. They might even find thr deliverables useful for them. So OpenSSL team can feel free to give them a call.
Mojah 10y ago
Mirrored here, in case official site collapses: https://marc.ttias.be/openssl-announce/2016-05/msg00002.php https://marc.ttias.be/openssl-announce/2016-05/msg00002.php
tajen 10y ago
Sorry for the noob question, but how do you ensure a Debian installation is always updated with the latest security patches? Do you just run `apt-get upgrade` everyday? Isn't there a risk of breaking things?
- steveklabnik 10y ago
  I use Debian. If you're running stable, you should be able to upgrade every day, and nothing will break. that's the purpose of stable; it really only adds security fixes.
- teddyh 10y ago
  Install the “unattended-upgrades” package.
josteink 10y ago
Again? Am I the only one calling this the rule, not the exception at this point? This is where I want the Rust-guys (or D or whatever) to be. "Hey guys. A drop in Libre/Open-SSL replacement, written in rust. Guaranteed to be free of all those security advisories you keep getting on a monthly basis these days". That's when people will start taking C-replacements like Rust seriously. Step up your game, guys :)
cm3 10y ago
Off-topic but given how many programs link against OpenSSL and that in some scenarios statically linked binaries are preferable, I've been wondering if there's a Linux distro that works like OCaml's opam, namely rebuilding everything that depends on something that just got updated. Is there such a distro?

259 points by FiloSottile 10y ago

Patch: https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb https://github.com/openssl/openssl/commit/70428eada9bc4cf314... Advisory mirror: https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa2009a891490 https://gist.github.com/FiloSottile/99ad6b52688f5a1f0a5fa200... Preliminary analysis: https://news.ycombinator.com/item?id=11621038 https://news.ycombinator.com/item?id=11621038

CiPHPerCoder 10y ago
But it no longer checked that there was enough data to have both the MAC and padding bytes. ... I am beyond words.
- pjmlp 10y ago
  Just the C usual stuff, but good bone coders use all the warnings and analyzers from gcc and clang and never commit such errors.
  - adrianN 10y ago
    I'm not sure whether you are sarcastic or not, but to me the seemingly endless amount of this kind of bug in high profile projects like OpenSSL is pretty good proof that nobody can write secure C.
    - Sir_Cmpwn 10y ago
      Just because a projcet is high profile doesn't mean it's well managed or well written.
      - mokus 10y ago
        All the more reason not to rely on security properties of code written in C - I don't have time to read and understand the source of every piece of software I use, and popularity is completely useless as a proxy for code quality. Being written in a memory-safe language isn't a silver bullet for all problems, but it actually _is_ a silver bullet for memory corruption problems. Memory corruption problems are a bit like infant mortality in the history of the medical profession - people that live past infancy still died, but infant deaths overwhelmingly impact the historical life expectancy statistics. Let's get our industry past the dark ages so we can start to live longer and begin to tackle more interesting causes of death. EDIT: fixed very silly typo (which I'm really surprised i wasn't instantly called on - it basically made me say I wasn't willing to understand my own code. thanks for the generous reading!)
        Sir_Cmpwn 10y ago
        There are plenty of codebases (including large ones) written in C that have a low number of vulnerabilities, even compared to projects written in higher level languages (setting aside Rust et al because they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. OpenSSL has louder vulnerabilities than most software because it's (1) very old, (2) very bad code, and (3) relied upon by heaps of software. There are lots of things wrong with OpenSSL, and those are the reasons that it's vulnerable. We should address the real issues instead of using C as a scapegoat.
        pjmlp 10y ago
        > It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. I have been reading about this mythical "skilled C programmer" since I got to learn C in 1993 and eventually joined C++ ranks instead, leaving my favorite Turbo Pascal behind. Never met one to this day, but fixed lots of memory corruption issues left behind by not so skilled ones, during the days I used to work daily with C and C++ codebases.
        10y ago
    - CiPHPerCoder 10y ago
      What about https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium then? Very high profile, no CVEs found to date. EDIT: Can't respond to lambda below. I was responding to THIS assertion, not proposing libsodium as a general purpose openssl replacement: "nobody can write secure C." To which I said, here's a project that's written in C that's apparently secure.
      - lambda 10y ago
        It also doesn't interoperate with any widely deployed crypto standards. Yes, NaCL is a better design for cryptographic primitives, being much more limited in scope and reducing the number of primitives supported. It's great, if you can control both sides of the protocol so you can use something like this, and if you can also write your own safe, secure protocol code on top of it that doesn't introduce any errors of its own. The problem being solved by OpenSSL is much harder; for interoperability, you need to support a much wider range of standards, and they are always changing. It also supplies the full protocol stack to implement TLS, including multiple versions of TLS, rather than just the crypto primitives. It's when you have code that is trying to do all of this, and evolve over time, with contributions from multiple people, that it's easy for such mistakes to creep in. Writing a single piece of code in C with no vulnerabilities is hard, but not impossible; maintaining such a piece of code, implementing complex and changing standards, over time, over a variety of platforms, and so on, without introducing vulnerabilities, does seem to be impossible in C.
        tptacek 10y ago
        Not interoperating with TLS's CBC construction is a feature, not a liability.
      - nickpsecurity 10y ago
        Almost always by super-human's, though. These people that can do in programming what most people can't do across the board. Including write C code with almost no defects. Now, what about mere humans with average or above average intelligence? What about us!? We can't be basing our expectations of what most can do with garbage like C on what the mental elite can pull off.
    - pjmlp 10y ago
      Of course I am being sarcastic, you just need to check my other posts. :) The point being, that in spite of what everyone says, not even with the help of the best tools to detect memory corruption issues in C, developers write memory corruption free code in it.
      - jjnoakes 10y ago
        Are the openssl developers using the "best tools to detect memory corruption issues in C"? In my experience, most open source projects don't devote the money or time to use, understand, deploy, and ensure such tools are used and the issues they find are resolved.
        nickpsecurity 10y ago
        Actually, I think they're using the best tools to create memory corruption issues in C. There could in fact be a slow-moving fuzzer in their build system that transforms safe C constructs into unsafe ones before release. It's random and hits one thing at a time. Probably borrowed from mutation component of a genetic algorithm toolkit. I won't speculate if lack of focus or quality could indicate rest of OpenSSL code was produced by genetic algorithms.
        pjmlp 10y ago
        I know C since 1993 and C++ since 1994. Used C++ extensively during those years up to 2006. C only when required to do so for university assignments or customers. On one of my employers, I was one of the few developers that bordered using VC++ debugging libraries for memory allocation and Insure++. It is not a matter of tooling being available, many don't use them even when they can.
    - pfg 10y ago
      Not sure if I'm missing something, but does the padding oracle really have anything to do with the code being written in C?
      - muricula 10y ago
        I could be mistaken but I think that the padding Oracle is possible because of a buffer overflow.
    - 27182818284 10y ago
      > is pretty good proof that nobody can write secure C. I came to that same conclusion. I used to almost romanticize C programmers years ago, but years and years of reading things like this have changed my mind.
    - ArkyBeagle 10y ago
      Where I work, you won't last long with too many memory overwrite bugs. There is no such... evolutionary feedback in open source.
    - SomeCallMeTim 10y ago
      >proof that nobody can write secure C. No, it just takes a good developer to write secure C. See: Qmail [1], which in 20 years only four bugs have been found, and only one of those was a potential security bug. Or djbdns [2]; similar lack of security holes despite being faster and safer than Bind. It's far easier to write code in C than it is to write good code in C. It's a downside of the security of open source projects that the contributors are those who care enough to volunteer who can contribute code, rather than restricting the team, or at least those who can approve code going into the core, to vetted experts. I'm a good developer, but far from the best, and glancing through the OpenSSL code that I've seen, I would never have approved most of it in code review. There needs to be someone at least as good as I am reviewing every last line of code submitted to OpenSSL. Even better if it were someone much better than I. [1] https://en.wikipedia.org/wiki/Qmail https://en.wikipedia.org/wiki/Qmail [2] http://cr.yp.to/djbdns/guarantee.html http://cr.yp.to/djbdns/guarantee.html
  - tveita 10y ago
    That doesn't look like a C specific error to me. In the release notes CVE-2016-2107 is listed as a padding oracle attack. Padding oracles are a logic/design error that is not easily caught by any language feature. CVE-2016-2108 on the other hand looks like a typical C style memory corruption bug.

petecooper 10y ago

Not working here -- likely hugged to death -- so Google cache: https://webcache.googleusercontent.com/search?q=cache:I3M170FkOTUJ:https://www.openssl.org/news/secadv/20160503.txt+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:I3M170... Edit: spelling.

greglindahl 10y ago
Or the Internet Archive: https://web.archive.org/web/20160503160435/https://www.openssl.org/news/secadv/20160503.txt https://web.archive.org/web/20160503160435/https://www.opens...

roddux 10y ago

Memory Issues: Episode III - Revenge Of The Buffer Overflow (2016) In all seriousness, repeated occurrences such as these should make people consider other languages for new projects. Despite being quite a C fanboy, I have to admit that even I think manual memory management should be a thing of the past now.

pjmlp 10y ago
The sad part is that already in the mid-60's and 70's, in computers much less powerful than the PDP-11, bounds checking wasn't a problem as such. In the few cases where it was a real problem for the application being written, it could be selectively disabled. Which according to C.A.Hoare in his 1981 speech, most people didn't want to do anyway. It only became a problem in the industry thanks to C.
- krylon 10y ago
  Having written C for a living for about two years, I have to admit that a large part of me really likes C. But also, I would have commited unspeakable acts just to have a compiler switch to enable bounds checking, no matter how badly that would have affected performance. Even when one knows what one is doing - or thinks so, anyway - these errors are so easy to sneak in and such a pain to track down. (Especially since we were using OpenWatcom whose debugger did not show useful data when the program crashed, which is usually the time one needs it the most...)
  - ghrifter 10y ago
    Just curious - what do you do for a living that means you have to write C? I'm interested in really learning C or C++ more indepthly. I feel like I am very proficient in high level programming knowledge (other than design patterns). Basically, when or if the web dev industry falls out, I want to have a good back up of knowing low-level languages.
    - stephen_g 10y ago
      Anything in embedded systems. I write code for high performance satellite terminal (ground side) and also point-to-point radio systems (ultra-low latency, millimetre wave stuff). 90% of the code I write is in C, about 60% of the time on microcontrollers with <256KB of RAM, and the rest in a cut-down Linux running on an ARM Cortex A8. I'd actually prefer to use C++ for the Linux stuff (std::string, smart pointers and STL containers would save me so much time), but we don't have the C++ standard library in our custom distro.

Filligree 10y ago

These are all errors that would be impossible in a language with, oh, bounds checking. There may be ranges of security-critical code that make sense to write in C, for example ensuring that algorithms run in constant time, although with modern compilers I have difficulty trusting that the compiler won't accidentally optimize away the constant-time-ness. Surely ASN.1 encoding isn't part of that range, however?

pjmlp 10y ago
Hoare quote during Turing award in 1981: "The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R. Hoare, Communications of the ACM, 1981
- codezero 10y ago
  Making it illegal to write code without bounds checking is an interesting and fun concept to imagine.
  - masklinn 10y ago
    Why? That's how the vast majority of modern languages work. You can't opt out of bounds checking in Java or Python.

solarengineer 10y ago

Does anyone know if there is an SSL specification somewhere? One could then start to write tests at various levels to ensure compliance with the specification. This test suite could then be considered a compatibility test suite as well.

CiPHPerCoder 10y ago
There are numerous RFCs, yes.
theandrewbailey 10y ago
The SSL spec (if you can call it that) and everything it depends on is spread over about a dozen or so RFCs. Good luck.
IgorPartola 10y ago
This has been discussed to death, and the conclusion is generally that testing for unknown security bugs is not possible (or at least not practical).
lmm 10y ago
The spec generally only specifies the correct behaviour, not what the program should be doing with e.g. malformed ASN.1.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

jbaviat 10y ago

One of the two issues was interestingly found using Clang fuzzing capabilities. This is in-process fuzzing, that Clang libFuzzer makes quite easy: http://blog.llvm.org/2015/04/fuzz-all-clangs.html http://blog.llvm.org/2015/04/fuzz-all-clangs.html http://llvm.org/docs/LibFuzzer.html http://llvm.org/docs/LibFuzzer.html

ashitlerferad 10y ago
Another fuzzer, quite amazing one actually (it managed to create PNG/JPEG images from fuzzing). http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
- jbaviat 10y ago
  The (truly amazing) lcamtuf blog post you are referring to is this one: http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin-air.html http://lcamtuf.blogspot.fr/2014/11/pulling-jpegs-out-of-thin...

mcs 10y ago

ASN.1 parsing in implementations of several different standards have had this class of issue for well over a decade. ip phone and software stack vulnerabilities in, for example in asterisk, specifically for ASN.1 handling have probably been used by our intelligence community for a long time. The safe implementations are probably ran in virtual machine languages.

cyphar 10y ago
I think we should all agree to move from ASN.1 as quickly as possible. Many implementations don't include some of the wacky features (like recursive serialisation of structures), because nobody needs them and they cause bugs. But there is so much more weirdness in ASN.1 that it would honestly be much nicer if we used JSON (as an example of the other extreme). Maybe there's a nice binary, typed format which doesn't resemble the 80s we should be using.
- lmm 10y ago
  Thrift/Protobuf/etc. are reasonably nice IME.
  - cyphar 10y ago
    The cool thing about protobuf is that it allows automated parser generation (that isn't some horrific hack built on bison). The downside is that if there's a bug in someone else's code, it becomes a bug in your code. :D
- zeveb 10y ago
  This is why the SPKI guys, seventeen years ago, made one of their design goals not using ASN.1: https://tools.ietf.org/html/rfc2692 https://tools.ietf.org/html/rfc2692 states 'No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.' They came up with a simple, beautiful representation for certificates. They also came up with a simple, logic, understandable way to think about what certificates can and cannot do. The world ignored them. RFCs 2692 & 2693 stand as a remarkable example of what could have been.

FiloSottile 10y ago

My understanding of the padding oracle vulnerability so far, mainly from the patch [0]: it's possible to make a "valid" message that has the pad length byte higher than maxpad (total_length - digest_length - 1) [1]. If you make it high enough, I think you'll push the offset used in the constant time comparison masks enough below 0 to entirely skip the MAC check [2]. But then your entire plaintext will have to match the pad byte to pass the check, and I think you can use that as a padding oracle. In other words, constant time programming, which by definition means that you have to behave normally even if your offsets go negative, is HARD. (And when you don't put comments ANYWHERE, it's even harder.) [0]: https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb https://github.com/openssl/openssl/commit/70428eada9bc4cf314... [1]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L583 https://github.com/openssl/openssl/blob/70428eada9bc4cf31424... [2]: https://github.com/openssl/openssl/blob/70428eada9bc4cf31424d723d1f992baffeb0dfb/crypto/evp/e_aes_cbc_hmac_sha1.c#L742-L766 https://github.com/openssl/openssl/blob/70428eada9bc4cf31424... For the record, there is nothing Go or Rust could have done here. The bug is caused by having to write code that runs in constant time, by employing masks and behaving in exactly the same way irrespective of the pad value. If you want to blame the design of something, blame Mac-then-Encrypt in TLS 1.0. See also The Cryptographic Doom Principle [3]. [3]: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/ EDIT: Interestingly, this was found with TLS-attacker [4], a new framework to analyze, test and attack TLS libraries. Finding it was probably "just" a matter of sending a plaintext made entirely of the same right byte value, and noticing that the MAC check passes when it should not. However, so far we didn't have any tool or testsuite (which I'm aware of) to perform this kind of checks. [4]: https://github.com/RUB-NDS/TLS-Attacker https://github.com/RUB-NDS/TLS-Attacker IMPACT [EDIT]: to sum up, if a client uses AES-CBC to connect to a server with AES-NI support, a MitM can recover at least 16 bytes of anything it can get the client to send repeatedly, together with attacker-controlled data (think Cookies or such, using Javascript cross-origin requests).

tptacek 10y ago
That's a second-order padding attack, in the same sense that an integer overflow most often creates a second-order buffer overflow: a first bug transitions your program to a state where a second bug --- very exploitable, and one the program tried to guard against --- is revealed. What's interesting about crypto to me is the prospect that every common crypto flaw has second- and third- order variants that we will not find out about for many years, the same way we've barely now got a grip on the interaction between C integers and buffer counting.

zymhan 10y ago

It's not a great bug, but I think it would require a very particular set of circumstances to arise: > ... only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL's default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities. However it does seem like a great exploit method for malware, using legit signed certificates that allow overwriting memory just by parsing the cert.

jjawssd 10y ago

What's the status of this bug for LibreSSL? (LibreSSL is used in OS X 10.11+)

jlgaddis 10y ago
Saw a tweet from one of the OpenBSD folks saying LibreSSL was also affected by these issues and fixes would be available today. Sorry, not on my laptop at the moment so I can't post a link. ETA: Source code [0] and binary [1] patches (via M-Tier) are available for OpenBSD. [0]: https://marc.info/?l=openbsd-tech&m=146228598730414&w=2 https://marc.info/?l=openbsd-tech&m=146228598730414&w=2 [1]: https://stable.mtier.org/ https://stable.mtier.org/
slasaus 10y ago
OpenSSL announced several issues today that also affect LibreSSL. - Memory corruption in the ASN.1 encoder (CVE-2016-2108) - Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) - EVP_EncodeUpdate overflow (CVE-2016-2105) - EVP_EncryptUpdate overflow (CVE-2016-2106) - ASN.1 BIO excessive memory allocation (CVE-2016-2109) Thanks to OpenSSL for providing information and patches. http://marc.info/?l=openbsd-announce&m=146228598930416&w=2 http://marc.info/?l=openbsd-announce&m=146228598930416&w=2 https://twitter.com/bob_beck/status/727478594591543296 https://twitter.com/bob_beck/status/727478594591543296
deleted 10y ago
[deleted]

kafka99 10y ago

Looks like the "negative zeroes" patch (commit in https://mta.openssl.org/pipermail/openssl-commits/2015-April/000906.html https://mta.openssl.org/pipermail/openssl-commits/2015-April...) was never introduced in debian and ubuntu?

kafka99 10y ago
I was indeed right :( The danger of only backporting security fixes. But it's in the patch now: http://www.ubuntu.com/usn/usn-2959-1/ http://www.ubuntu.com/usn/usn-2959-1/

nickpsecurity 10y ago

ASN.1 is so well-understood at this point that Galois even has a high-assurance toolkit for it: http://cps-vo.org/node/1577 http://cps-vo.org/node/1577 Maybe someone should forward that to OpenSSL team and suggest they pay Galois to crank out a bunch of encoders/decoders for them for anything requiring that in OpenSSL. Or LANGSEC people behind HAMMER toolkit. Or even the Cap n Proto guy. Seriously, the number of preventable failures in this software, esp memory, is a strong indicator of why you should never use it.

peterwwillis 10y ago
> Maybe someone should forward that to OpenSSL team and suggest they pay Galois Here's where you can donate your money to pay Galois: https://www.openssl.org/support/donations.html https://www.openssl.org/support/donations.html Once they've received the funds i'm sure they'll get right on it.
- nickpsecurity 10y ago
  Lol. I thought they've had money all this time and not spent it on stuff that works. Meanwhile, LibreSSL did more in a few weeks for their code quality than its owners did in a year. Why would I give them money expecting something different? The right course, if we're talking Galois, is for them to try to ask Galois to donate some time or tooling to improve critical aspects of a widespread-deployed library. They already make money with grants and stuff for code they often open-source. They might even find thr deliverables useful for them. So OpenSSL team can feel free to give them a call.

Mojah 10y ago

Mirrored here, in case official site collapses: https://marc.ttias.be/openssl-announce/2016-05/msg00002.php https://marc.ttias.be/openssl-announce/2016-05/msg00002.php

tajen 10y ago

Sorry for the noob question, but how do you ensure a Debian installation is always updated with the latest security patches? Do you just run `apt-get upgrade` everyday? Isn't there a risk of breaking things?

steveklabnik 10y ago
I use Debian. If you're running stable, you should be able to upgrade every day, and nothing will break. that's the purpose of stable; it really only adds security fixes.
teddyh 10y ago
Install the “unattended-upgrades” package.

josteink 10y ago

Again? Am I the only one calling this the rule, not the exception at this point? This is where I want the Rust-guys (or D or whatever) to be. "Hey guys. A drop in Libre/Open-SSL replacement, written in rust. Guaranteed to be free of all those security advisories you keep getting on a monthly basis these days". That's when people will start taking C-replacements like Rust seriously. Step up your game, guys :)

cm3 10y ago

Off-topic but given how many programs link against OpenSSL and that in some scenarios statically linked binaries are preferable, I've been wondering if there's a Linux distro that works like OCaml's opam, namely rebuilding everything that depends on something that just got updated. Is there such a distro?