11 ms·

Patch: https://github.com/openssl/openssl/commit/70428eada9bc4cf31424d723d1f992baffeb0dfb https://github.com/openssl/openssl/commit/70428eada9bc4cf314... Advis

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.
        nickpsecurity 10y ago
        We know they exist. Bernstein and Cutler are two probables based on reviews of their code. Thing is, these people are mentally not even human: it's like Human++ in terms of technical proficiency. So, maybe skilled C programmers only exist among the super-humans. ;)
        mokus 10y ago
        That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns. The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc. The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb. Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code. Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.
    - 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.

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.
        nickpsecurity 10y ago
        We know they exist. Bernstein and Cutler are two probables based on reviews of their code. Thing is, these people are mentally not even human: it's like Human++ in terms of technical proficiency. So, maybe skilled C programmers only exist among the super-humans. ;)
        mokus 10y ago
        That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns. The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc. The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb. Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code. Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.
  - 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.