10 ms·

OpenSSL CVE-2016-0799: heap corruption via BIO_printf

137 points by 0x0 11y ago

wiredfool 11y ago
This appears to be jumping the gun just a bit. They normally aim for during the work week in the US?
chinathrow 11y ago
Responsible disclosure, anyone?
- deleted 11y ago
  [deleted]
- detaro 11y ago
  The openSSL project committed the fix and description to their public repo 3 days ago (no clue if intentionally or not, but they didn't remove them). Not much to hide anymore.
latenightcoding 11y ago
I arrived to the comments section before the C vs Rust flame war
- pjmlp 11y ago
  Don't bother, they haven't learned about writing secure code since Extended Algol (1961), Mesa (early 70's), Modula-2 (1978), Cedar (early 80's), Ada (1983), Oberon (1991),... anyway.
  - tosseraccount 11y ago
    17 years ago it was "Let's rewrite Unix in Perl" ... http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl I do wish them the best luck, though.
    - jest3r1 11y ago
      Strange to go back in time.
  - cwzwarich 11y ago
    Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding a garbage collector, so you could generalize and say that nobody has learned about writing secure code since Lisp in 1958. Also, I'm pretty sure that Oberon was quite a bit earlier than that.
    - pcwalton 11y ago
      To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).
      - viraptor 11y ago
        Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
        steveklabnik 11y ago
        Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
        viraptor 11y ago
        That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.
    - 11y ago
- striking 11y ago
  They might downvote you, but I think your preemption of the flame war is a noble thing.
  - tosseraccount 11y ago
    Looks like they showed up.
    - striking 11y ago
      But they're isolated here at the bottom.
- topspin 11y ago
  Another day, another memory violation... the endless supply of ammo dispenses another box of shells for Rust. I don't know if Rust is the future, but I am certain the dangling pointers, use after frees, buffer overflows, double frees, smashed stacks, ignored failures, uninitialized data and all the other horrors of contemporary C/C++ will one day be understood as intolerable.
  - JoeAltmaier 11y ago
    These things can be reduced to nuisance level by discipline. The cost to obviating them by language design is not zero (code size; execution speed; random latencies) so its arguable, different languages, different purposes.
    - aschampion 11y ago
      > These things can be reduced to nuisance level by discipline. Obviously not. We've been doing this for decades and are still making the same mistakes with costly effects. Humans are as much a part of technological systems as the language or platform; continuing to ignore that even educated, disciplined, skilled developers are prone to certain classes of errors -- errors that could be obviated by other components of the system -- is hubris. It is much more feasible to create tools that exclude certain classes of error than to create less fallible developers. > (code size; execution speed; random latencies) Rust is not GC'ed, has no inherent reason to be slower than C (as the toolchain matures), and I doubt is more verbose than C code that provides the same safety.
      - JoeAltmaier 11y ago
        Speak for yourself. A power saw is dangerous; but I'm not going back thanks. And nothing to say about the performance cost of these infallible tools? They are not free.
        kbenson 11y ago
        > A power saw is dangerous; but I'm not going back thanks. And now we have power saws that immediately stop when they encounter flesh. Obviously, disciplined users never had to worry about that system, otherwise we would have had a bunch of people missing fingers... like my wood shop teacher in high school. :/ > And nothing to say about the performance cost of these infallible tools? They are not free. People have brought this up a few times, but I've never gotten an explanation that makes sense. My understanding is that Rust does most of its protections in the compile stage, so while not free, they are a small up-front cost at the compile stage, plus an indeterminate cost at the development stage in possible more complex reasoning about the code, which then pays off over the lifetime of the application. While not free, that's definitely a trade-off that seems to make sense to me. Or are you talking about some other cost? Can you explain where I'm not understanding your point?
ComputerGuru 11y ago
There was "fair notice" given last week (and front page'd here on HN) about an upcoming release patching "several" vulnerabilities: https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html https://mta.openssl.org/pipermail/openssl-announce/2016-Febr... However, they're scheduled for release on Monday the 1st of March - so we might be seeing a few more bugs in the next couple of days. EDIT: I've spent all morning teasing a friend whose birthday is today about "what if it were tomorrow" (I'm sure they get it every year from every single person they meet), only to then come here and forget all about it in my tally. Go figure. Yes, the 1st of March is Tuesday. Sorry!
- protomyth 11y ago
  1st March 2016 is a Tuesday
- Someone 11y ago
  Don't look for it on Monday; The 1st of March is Tuesday; 2016 is a leap year.
0x0 11y ago
Three CVE's listed as currently vulnerable here: https://security-tracker.debian.org/tracker/source-package/openssl https://security-tracker.debian.org/tracker/source-package/o... With links to git commits: CVE-2016-0705: https://git.openssl.org/?p=openssl.git;a=commit;h=ab4a81f69ec88d06c9d8de15326b9296d7f498ed https://git.openssl.org/?p=openssl.git;a=commit;h=ab4a81f69e... CVE-2016-0798: https://git.openssl.org/?p=openssl.git;a=commit;h=59a908f1e8380412a81392c468b83bf6071beb2a https://git.openssl.org/?p=openssl.git;a=commit;h=59a908f1e8... CVE-2016-0799: https://git.openssl.org/?p=openssl.git;a=commit;h=a801bf263849a2ef773e5bc0c86438cbba720835 https://git.openssl.org/?p=openssl.git;a=commit;h=a801bf2638...
vmorgulis 11y ago
It's a bit crazy to see again issues related to string manipulation. Why this kind of stuff is not centralized yet?
- stonogo 11y ago
  In the name of portability, they've opted to have low-quality NIHed code instead.
whoopdedo 11y ago
That it has its own printf implementation, along with many other not-exactly-crypto-related utilities, is a feature creep that I always found distasteful about OpenSSL.
narrator 11y ago
This is one of those "let's ignore malloc failing" bugs. This is pretty common in C code and is, IMHO, a common "worse is better"[1] anti-pattern, which is predicated on the "worse is better" principle that correctness can be sacrified if it makes things too complicated. Many programmers, unfortunately, don't give a crap about things that far off the happy path, and when the language implements checked exceptions or Option types they get upset that it forces them to think about those distracting corner cases. Such is the state of software engineering. 1. https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better
- mattst88 11y ago
  The project I work on, Mesa3D, routinely ignores malloc failures for a couple of reasons: no one knows how to reasonably test the additional code, and often no one has any idea what sort of graceful failure is even possible when malloc fails. We've had some cargo culted patches to call _mesa_error_no_memory() when malloc fails, but it was recently noted that this can't possibly work because it internally calls fprintf, and there's no guarantee that fprintf doesn't call malloc! In fact, glibc's implementation does. Suggestions for best practices welcome.
  - Sanddancer 11y ago
    If you can't fail gracefully, then crash as soon as possible. Trying to sputter along is just asking for worse problems.
    - webkike 11y ago
      Well, considering malloc gives a NULL pointer on failure, a crash at some point is pretty clearly inevitable.
      - Sanddancer 11y ago
        Yes, but it becomes harder to tell where in the code that happened. If you run abort() or the like, you've got more information as to the circumstances of the crash.
viraptor 11y ago
Nice code formatter. If in doubt, escape it thrice: _dopr(&amp;amp;hugebufp, ....
- iokanuon 11y ago
  That's actually four times - browser unescapes the first one. _dopr(&amp;amp;amp;hugebufp, ...
viraptor 11y ago
In case someone's interested in history, related change (return on malloc fail) was done in March 2015 in a general alloc-fail cleanup across the codebase. https://github.com/openssl/openssl/commit/918bb8652969fd53f0c390c1cd909265ed502c7e https://github.com/openssl/openssl/commit/918bb8652969fd53f0...
userbinator 11y ago
From reading the description, I get the feeling that this is nowhere near as severe as e.g. Heartbleed, right? IMHO dynamic allocation is something that is often overused, and the fact that it could fail leads to another error path that might be exploitable, like this one. I don't think it's necessary for a printf-like function to ever use dynamic allocation. (If there are cases where it's necessary, I would love to know more... and perhaps suggest how it could be avoided.)
vszakats 11y ago
"These are not the patches you are looking for": https://groups.google.com/forum/m/#!topic/mailing.openssl.dev/4m8--XksQD4 https://groups.google.com/forum/m/#!topic/mailing.openssl.de... Clarification from OpenSSL maintainer.
alexandercrohde 11y ago
Am I the only one who doesn't understand why it's still considered "okay" to write C for security-dependent code these days? Processors have gotten order of magnitudes faster, speed is no longer the constraining resource, and certainly not one I would trade my security for...
- alextgordon 11y ago
  Don't even need anything that drastic. Just switch the compiler to C++ mode and start using std::unique_ptr instead of malloc/free. Remember to turn off exceptions and RTTI to keep the spirit of C alive in your C++ code!
- serge2k 11y ago
  Oh my god what a revelation. I've never seen anyone bring this up before. Outside of every single thread about C. Everyone at this point knows the shitty side of C.

137 points by 0x0 11y ago

wiredfool 11y ago

This appears to be jumping the gun just a bit. They normally aim for during the work week in the US?

chinathrow 11y ago

Responsible disclosure, anyone?

deleted 11y ago
[deleted]
detaro 11y ago
The openSSL project committed the fix and description to their public repo 3 days ago (no clue if intentionally or not, but they didn't remove them). Not much to hide anymore.

latenightcoding 11y ago

I arrived to the comments section before the C vs Rust flame war

pjmlp 11y ago
Don't bother, they haven't learned about writing secure code since Extended Algol (1961), Mesa (early 70's), Modula-2 (1978), Cedar (early 80's), Ada (1983), Oberon (1991),... anyway.
- tosseraccount 11y ago
  17 years ago it was "Let's rewrite Unix in Perl" ... http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl I do wish them the best luck, though.
  - jest3r1 11y ago
    Strange to go back in time.
- cwzwarich 11y ago
  Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding a garbage collector, so you could generalize and say that nobody has learned about writing secure code since Lisp in 1958. Also, I'm pretty sure that Oberon was quite a bit earlier than that.
  - pcwalton 11y ago
    To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).
    - viraptor 11y ago
      Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
      - steveklabnik 11y ago
        Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
        viraptor 11y ago
        That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.
  - 11y ago
striking 11y ago
They might downvote you, but I think your preemption of the flame war is a noble thing.
- tosseraccount 11y ago
  Looks like they showed up.
  - striking 11y ago
    But they're isolated here at the bottom.
topspin 11y ago
Another day, another memory violation... the endless supply of ammo dispenses another box of shells for Rust. I don't know if Rust is the future, but I am certain the dangling pointers, use after frees, buffer overflows, double frees, smashed stacks, ignored failures, uninitialized data and all the other horrors of contemporary C/C++ will one day be understood as intolerable.
- JoeAltmaier 11y ago
  These things can be reduced to nuisance level by discipline. The cost to obviating them by language design is not zero (code size; execution speed; random latencies) so its arguable, different languages, different purposes.
  - aschampion 11y ago
    > These things can be reduced to nuisance level by discipline. Obviously not. We've been doing this for decades and are still making the same mistakes with costly effects. Humans are as much a part of technological systems as the language or platform; continuing to ignore that even educated, disciplined, skilled developers are prone to certain classes of errors -- errors that could be obviated by other components of the system -- is hubris. It is much more feasible to create tools that exclude certain classes of error than to create less fallible developers. > (code size; execution speed; random latencies) Rust is not GC'ed, has no inherent reason to be slower than C (as the toolchain matures), and I doubt is more verbose than C code that provides the same safety.
    - JoeAltmaier 11y ago
      Speak for yourself. A power saw is dangerous; but I'm not going back thanks. And nothing to say about the performance cost of these infallible tools? They are not free.
      - kbenson 11y ago
        > A power saw is dangerous; but I'm not going back thanks. And now we have power saws that immediately stop when they encounter flesh. Obviously, disciplined users never had to worry about that system, otherwise we would have had a bunch of people missing fingers... like my wood shop teacher in high school. :/ > And nothing to say about the performance cost of these infallible tools? They are not free. People have brought this up a few times, but I've never gotten an explanation that makes sense. My understanding is that Rust does most of its protections in the compile stage, so while not free, they are a small up-front cost at the compile stage, plus an indeterminate cost at the development stage in possible more complex reasoning about the code, which then pays off over the lifetime of the application. While not free, that's definitely a trade-off that seems to make sense to me. Or are you talking about some other cost? Can you explain where I'm not understanding your point?

ComputerGuru 11y ago

There was "fair notice" given last week (and front page'd here on HN) about an upcoming release patching "several" vulnerabilities: https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html https://mta.openssl.org/pipermail/openssl-announce/2016-Febr... However, they're scheduled for release on Monday the 1st of March - so we might be seeing a few more bugs in the next couple of days. EDIT: I've spent all morning teasing a friend whose birthday is today about "what if it were tomorrow" (I'm sure they get it every year from every single person they meet), only to then come here and forget all about it in my tally. Go figure. Yes, the 1st of March is Tuesday. Sorry!

protomyth 11y ago
1st March 2016 is a Tuesday
Someone 11y ago
Don't look for it on Monday; The 1st of March is Tuesday; 2016 is a leap year.

0x0 11y ago

Three CVE's listed as currently vulnerable here: https://security-tracker.debian.org/tracker/source-package/openssl https://security-tracker.debian.org/tracker/source-package/o... With links to git commits: CVE-2016-0705: https://git.openssl.org/?p=openssl.git;a=commit;h=ab4a81f69ec88d06c9d8de15326b9296d7f498ed https://git.openssl.org/?p=openssl.git;a=commit;h=ab4a81f69e... CVE-2016-0798: https://git.openssl.org/?p=openssl.git;a=commit;h=59a908f1e8380412a81392c468b83bf6071beb2a https://git.openssl.org/?p=openssl.git;a=commit;h=59a908f1e8... CVE-2016-0799: https://git.openssl.org/?p=openssl.git;a=commit;h=a801bf263849a2ef773e5bc0c86438cbba720835 https://git.openssl.org/?p=openssl.git;a=commit;h=a801bf2638...

vmorgulis 11y ago

It's a bit crazy to see again issues related to string manipulation. Why this kind of stuff is not centralized yet?

stonogo 11y ago
In the name of portability, they've opted to have low-quality NIHed code instead.

whoopdedo 11y ago

That it has its own printf implementation, along with many other not-exactly-crypto-related utilities, is a feature creep that I always found distasteful about OpenSSL.

narrator 11y ago

This is one of those "let's ignore malloc failing" bugs. This is pretty common in C code and is, IMHO, a common "worse is better"[1] anti-pattern, which is predicated on the "worse is better" principle that correctness can be sacrified if it makes things too complicated. Many programmers, unfortunately, don't give a crap about things that far off the happy path, and when the language implements checked exceptions or Option types they get upset that it forces them to think about those distracting corner cases. Such is the state of software engineering. 1. https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better

mattst88 11y ago
The project I work on, Mesa3D, routinely ignores malloc failures for a couple of reasons: no one knows how to reasonably test the additional code, and often no one has any idea what sort of graceful failure is even possible when malloc fails. We've had some cargo culted patches to call _mesa_error_no_memory() when malloc fails, but it was recently noted that this can't possibly work because it internally calls fprintf, and there's no guarantee that fprintf doesn't call malloc! In fact, glibc's implementation does. Suggestions for best practices welcome.
- Sanddancer 11y ago
  If you can't fail gracefully, then crash as soon as possible. Trying to sputter along is just asking for worse problems.
  - webkike 11y ago
    Well, considering malloc gives a NULL pointer on failure, a crash at some point is pretty clearly inevitable.
    - Sanddancer 11y ago
      Yes, but it becomes harder to tell where in the code that happened. If you run abort() or the like, you've got more information as to the circumstances of the crash.

viraptor 11y ago

Nice code formatter. If in doubt, escape it thrice: _dopr(&amp;amp;hugebufp, ....

iokanuon 11y ago
That's actually four times - browser unescapes the first one. _dopr(&amp;amp;amp;hugebufp, ...

viraptor 11y ago

In case someone's interested in history, related change (return on malloc fail) was done in March 2015 in a general alloc-fail cleanup across the codebase. https://github.com/openssl/openssl/commit/918bb8652969fd53f0c390c1cd909265ed502c7e https://github.com/openssl/openssl/commit/918bb8652969fd53f0...

userbinator 11y ago

From reading the description, I get the feeling that this is nowhere near as severe as e.g. Heartbleed, right? IMHO dynamic allocation is something that is often overused, and the fact that it could fail leads to another error path that might be exploitable, like this one. I don't think it's necessary for a printf-like function to ever use dynamic allocation. (If there are cases where it's necessary, I would love to know more... and perhaps suggest how it could be avoided.)

vszakats 11y ago

"These are not the patches you are looking for": https://groups.google.com/forum/m/#!topic/mailing.openssl.dev/4m8--XksQD4 https://groups.google.com/forum/m/#!topic/mailing.openssl.de... Clarification from OpenSSL maintainer.

alexandercrohde 11y ago

Am I the only one who doesn't understand why it's still considered "okay" to write C for security-dependent code these days? Processors have gotten order of magnitudes faster, speed is no longer the constraining resource, and certainly not one I would trade my security for...

alextgordon 11y ago
Don't even need anything that drastic. Just switch the compiler to C++ mode and start using std::unique_ptr instead of malloc/free. Remember to turn off exceptions and RTTI to keep the spirit of C alive in your C++ code!
serge2k 11y ago
Oh my god what a revelation. I've never seen anyone bring this up before. Outside of every single thread about C. Everyone at this point knows the shitty side of C.