7 ms·

Go 1.5.3 released to address security vulnerability

202 points by patrickmn 11y ago

0x0 11y ago
Having to recompile all applications and libraries to remove the potential crypto bug is a pretty scary bug :-/
- Armand_Grillet 11y ago
  Fortunately, the bug's frequency is really low: "On 64-bit systems, the frequency of the bug is [...] less than one in 2^50".
- JoachimSchipper 11y ago
  Linking everything statically is not always an advantage...
  - coldtea 11y ago
    In this case it actually is. Imagine the nightmare of having to hunt tens of shared libraries versions, and even have to re-build them and patch them with the correct version of the language/apis so that they continue to work.
    - eropple 11y ago
      How does that square? I mean, I have one copy of a shared library on any of my machines. I don't even necessarily know off the top of my head what of the Go tools my developers found bloggable enough to want in the stack that might be impacted by this bug. (Or rather, I do, but that's because it's my job, and I'm actually good at my job. I don't have the same high hopes with regards to most other infrastructure folks I've worked with.)
      - JamesMcMinn 11y ago
        You don't need to know what Go tools your "developers found bloggable enough to want in the stack". You simply need to rebuild whatever binaries you run, this will re-compile everything (libraries and all) and prevent the exploit. What libraries you or your developers use is irrelevant. As an aside, do you have any idea how pretentious you come across?
        nindalf 11y ago
        I can't understand why someone making a statement like that ("bloggable..") which is untrue can be upvoted while you're downvoted. Worse, he even bragged about being an excellent engineer who knows everything there is to know when he clearly doesn't in this case.
        elithrar 11y ago
        `go build -a` rebuilds all packages (i.e. those already cached under $GOPATH/pkg/ or /vendor). Alternatively you can just rm -rf your `$GOPATH/pkg` directory.
        eropple 11y ago
        > You simply need to rebuild whatever binaries you run "Stack", not "app". That includes, say, Docker. Or nsq. Which are packaged by the operating system (because, as noted in a reply to `tptacek, paying me to build out what they get from the operating system is generally not something a client is going to want to do). And which will not be updated as conscientiously as I can expect a core library on my system to be updated. > As an aside, do you have any idea how pretentious you come across? Pretension, frustration, whichever. My low opinion of Go aside, it's my job to deal with the details of my clients' stacks, make a coherent experience for their developers, and deal with the system-level security concerns they don't think about. If getting annoyed that Go and its community make my life suck a little bit more in ways it need not suck is pretension, I'm really gonna be okay with that. I mean, jeez, it's 2016. "Rebuild the entire world when a mouse farts" is fragile, dangerous garbage that puts the lie to the idea of "engineering" in this profession. We should be better than this. (And Go's first iteration, lovingly called Java 1.4, was. We're going backwards.)
  - ori_b 11y ago
    You're right. Let's put it in a docker image instead, and ship shared libraries that way.
- tacticus 11y ago
  Thankfully it's rather trivial to do.
  - 0x0 11y ago
    It's trivial to do when you know which binary to replace (and you have the source code available). But it's probably not so trivial to hunt down every single old binary on every system. There's also a continuous risk that you may receive old binaries from third parties in the future. For example, gitlab has started to ship a component written in Go in recent versions. Things like these are easy to forget about.
    - karaziox 11y ago
      If you can't track the binaries you are running you have a bigger problem than recompiling some of them. Security issues aren't the one in a decade thing, if you can't easily locate which code has to be updated, you are in trouble already...
    - donatj 11y ago
      I'd say as a general overzealous rule that if at least two people in the company don't know the code, it shouldn't be publicly accessible if it being compromised could cause you financial harm.
- ominous_prime 11y ago
  Not really. Go doesn't use shared libraries (yet), so you're only really recompiling the end binaries. If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.
  - eropple 11y ago
    > If you're using Go, you should already have the infrastructure to do this. Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome. We got away from statically linked monoliths for a reason.
    - bliti 11y ago
      Feeling your pain right now. I have a service running in go that runs in multiple machines and this will keep me busy for the night. Worst is that I can't have a sysadmin do the whole process. Now QA has to sign off on it... It's no wonder things stay broken for a long time. It is a lotnif work. Sorry for the rant. :)
      - helper 11y ago
        Isn't that what automation tools are for?
        bliti 11y ago
        You can't blindly trust automated tools. They also don't replace protocol.
        ownagefool 11y ago
        That's why you write tests. Not that always works either, but it's not like a qa team of point and clixkers running over a manual set of those same tests will always get it right.
tptacek 11y ago
Carry propagation strikes again!
- pbsd 11y ago
  I think it's time we forgive the entertainment industry for that "you forgot to carry the one" trope. Turns out they were right!
- bma10 11y ago
  Can you point to a resource that explains what a carry propagation bug means? I am having a hard time searching for an explanation, especially in the context of how it can cause security issues.
  - nickpsecurity 11y ago
    When I see a question like this, I always type in obvious words like "carry propagation bug" into Google just to see if it's a lazy question or there's a failure by INFOSEC authors on a topic. I was shocked that all I got was garbage about all kinds of CVE's and such with no clear explanation of the problem. Not clear in terms of someone searching for an article rather than bug report. Only one I saw in a few pages of Google was: http://blog.skylable.com/2014/05/tweetnacl-carrybit-bug/ http://blog.skylable.com/2014/05/tweetnacl-carrybit-bug/ StackOverflow had nothing useful with that phrase. Weird. I tried Modular and Montgomery Multiplication as they're important key words that should give you an idea about potential carry issues. I found these decent descriptions in my short Googling: https://en.wikipedia.org/wiki/Kochanski_multiplication https://en.wikipedia.org/wiki/Kochanski_multiplication http://www.hackersdelight.org/MontgomeryMultiplication.pdf http://www.hackersdelight.org/MontgomeryMultiplication.pdf Best I can do with little time and the flood of irrelevant results I saw. Maybe need a thorough write-up on these sorts of things that shows up in Google. At least I serendipitously found a great paper on statically detecting flaws in error propagation: http://pages.cs.wisc.edu/~liblit/dissertations/crubio.pdf http://pages.cs.wisc.edu/~liblit/dissertations/crubio.pdf So, thanks for asking even if not an intended benefit. :)
  - fryguy 11y ago
    You can't store a 4096-bit number in 32-bit register, so if you are multiplying numbers together you need to do it a piece (limb) at a time. Given that the arithmetic is modular, you can get away with "leaving some room" and not using all 32-bits, but instead using more 32-bit registers and treating them as if they are say 26-bit registers that can overflow 6-bits. For instance, Curve25519 (255-bit modulus) can be stored with 8 32-bit limbs, or 10 26-bit limbs (among other combinations). So if you do repeated calculations, you don't need to carry all of the bits all of the time. I don't know if it's the case for this bug, but I know it's been a bug in the past that they waited too long to propagate the carry (the extra 6-bits) into the next limb and it's overflowed the 32-bit register. This results in an incorrect calculation.
Jabbles 11y ago
They gave 5 days' notice. https://groups.google.com/forum/#!topic/golang-announce/MLaPAPFlCNY https://groups.google.com/forum/#!topic/golang-announce/MLaP...
JoachimSchipper 11y ago
Note that you probably need to revoke your key if you used it on a 32-bit system and published anywhere close to 64M results. Busy SSL terminators or e.g. OAUTH signers might want to take note. I'm surprised to learn that Go did not already check the result of calculations; that's a pretty standard countermeasure, also to e.g. protect your private key on somewhat-unreliable hardware.
- tptacek 11y ago
  Not really surprising. This is a common bug, and people are looking for it much more aggressively over the last year. Even Nacl had one of these bugs! There was a carry propagation bug in OpenSSL/BoringSSL/LibreSSL just a few weeks ago.
  - parfe 11y ago
    Are you rerferring to CVE-2015-3193? I believe it did not affect libressl
  - hannob 11y ago
    The surprising thing is not the bug, it's that go didn't verify the result of the CRT calculation. That's a standard countermeasure (although not present everywhere, Florian Weimer recently did some work on patching implementations that were lacking this check). And nit: The OpenSSL bug didn't affect libressl (I discovered it, I checked for that).
    - tptacek 11y ago
      I stand corrected! Sorry about that.
    - ancarda 11y ago
      How do bugs that affect OpenSSL not affect LibreSSL? Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup?
revelation 11y ago
Go implements their own RSA crypto and related algorithms? I would have expected them to learn from Javas mistakes and use something that has a hope of being maintained indefinitely and isn't coupled to something like language version. JSSE (TLS implementation in Java) is so broken and behind Tomcat ships with some marshal interface to OpenSSL, but that takes considerable effort and software converges to language defaults.
- Dobbs 11y ago
  Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.
  - revelation 11y ago
    That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.
    - f2f 11y ago
      you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
      - deleted 11y ago
        [deleted]
      - revelation 11y ago
        The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.
SyneRyder 11y ago
In case anyone wondered if the discontinued 32-bit Mac OS X versions were also affected (for 10.6 & 10.7 compatibility), apparently "The issue was introduced in Go 1.5", and the last 32-bit binaries for Mac were Go 1.4.2.

202 points by patrickmn 11y ago

0x0 11y ago

Having to recompile all applications and libraries to remove the potential crypto bug is a pretty scary bug :-/

Armand_Grillet 11y ago
Fortunately, the bug's frequency is really low: "On 64-bit systems, the frequency of the bug is [...] less than one in 2^50".
JoachimSchipper 11y ago
Linking everything statically is not always an advantage...
- coldtea 11y ago
  In this case it actually is. Imagine the nightmare of having to hunt tens of shared libraries versions, and even have to re-build them and patch them with the correct version of the language/apis so that they continue to work.
  - eropple 11y ago
    How does that square? I mean, I have one copy of a shared library on any of my machines. I don't even necessarily know off the top of my head what of the Go tools my developers found bloggable enough to want in the stack that might be impacted by this bug. (Or rather, I do, but that's because it's my job, and I'm actually good at my job. I don't have the same high hopes with regards to most other infrastructure folks I've worked with.)
    - JamesMcMinn 11y ago
      You don't need to know what Go tools your "developers found bloggable enough to want in the stack". You simply need to rebuild whatever binaries you run, this will re-compile everything (libraries and all) and prevent the exploit. What libraries you or your developers use is irrelevant. As an aside, do you have any idea how pretentious you come across?
      - nindalf 11y ago
        I can't understand why someone making a statement like that ("bloggable..") which is untrue can be upvoted while you're downvoted. Worse, he even bragged about being an excellent engineer who knows everything there is to know when he clearly doesn't in this case.
      - elithrar 11y ago
        `go build -a` rebuilds all packages (i.e. those already cached under $GOPATH/pkg/ or /vendor). Alternatively you can just rm -rf your `$GOPATH/pkg` directory.
      - eropple 11y ago
        > You simply need to rebuild whatever binaries you run "Stack", not "app". That includes, say, Docker. Or nsq. Which are packaged by the operating system (because, as noted in a reply to `tptacek, paying me to build out what they get from the operating system is generally not something a client is going to want to do). And which will not be updated as conscientiously as I can expect a core library on my system to be updated. > As an aside, do you have any idea how pretentious you come across? Pretension, frustration, whichever. My low opinion of Go aside, it's my job to deal with the details of my clients' stacks, make a coherent experience for their developers, and deal with the system-level security concerns they don't think about. If getting annoyed that Go and its community make my life suck a little bit more in ways it need not suck is pretension, I'm really gonna be okay with that. I mean, jeez, it's 2016. "Rebuild the entire world when a mouse farts" is fragile, dangerous garbage that puts the lie to the idea of "engineering" in this profession. We should be better than this. (And Go's first iteration, lovingly called Java 1.4, was. We're going backwards.)
- ori_b 11y ago
  You're right. Let's put it in a docker image instead, and ship shared libraries that way.
tacticus 11y ago
Thankfully it's rather trivial to do.
- 0x0 11y ago
  It's trivial to do when you know which binary to replace (and you have the source code available). But it's probably not so trivial to hunt down every single old binary on every system. There's also a continuous risk that you may receive old binaries from third parties in the future. For example, gitlab has started to ship a component written in Go in recent versions. Things like these are easy to forget about.
  - karaziox 11y ago
    If you can't track the binaries you are running you have a bigger problem than recompiling some of them. Security issues aren't the one in a decade thing, if you can't easily locate which code has to be updated, you are in trouble already...
  - donatj 11y ago
    I'd say as a general overzealous rule that if at least two people in the company don't know the code, it shouldn't be publicly accessible if it being compromised could cause you financial harm.
ominous_prime 11y ago
Not really. Go doesn't use shared libraries (yet), so you're only really recompiling the end binaries. If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.
- eropple 11y ago
  > If you're using Go, you should already have the infrastructure to do this. Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome. We got away from statically linked monoliths for a reason.
  - bliti 11y ago
    Feeling your pain right now. I have a service running in go that runs in multiple machines and this will keep me busy for the night. Worst is that I can't have a sysadmin do the whole process. Now QA has to sign off on it... It's no wonder things stay broken for a long time. It is a lotnif work. Sorry for the rant. :)
    - helper 11y ago
      Isn't that what automation tools are for?
      - bliti 11y ago
        You can't blindly trust automated tools. They also don't replace protocol.
        ownagefool 11y ago
        That's why you write tests. Not that always works either, but it's not like a qa team of point and clixkers running over a manual set of those same tests will always get it right.

tptacek 11y ago

Carry propagation strikes again!

pbsd 11y ago
I think it's time we forgive the entertainment industry for that "you forgot to carry the one" trope. Turns out they were right!
bma10 11y ago
Can you point to a resource that explains what a carry propagation bug means? I am having a hard time searching for an explanation, especially in the context of how it can cause security issues.
- nickpsecurity 11y ago
  When I see a question like this, I always type in obvious words like "carry propagation bug" into Google just to see if it's a lazy question or there's a failure by INFOSEC authors on a topic. I was shocked that all I got was garbage about all kinds of CVE's and such with no clear explanation of the problem. Not clear in terms of someone searching for an article rather than bug report. Only one I saw in a few pages of Google was: http://blog.skylable.com/2014/05/tweetnacl-carrybit-bug/ http://blog.skylable.com/2014/05/tweetnacl-carrybit-bug/ StackOverflow had nothing useful with that phrase. Weird. I tried Modular and Montgomery Multiplication as they're important key words that should give you an idea about potential carry issues. I found these decent descriptions in my short Googling: https://en.wikipedia.org/wiki/Kochanski_multiplication https://en.wikipedia.org/wiki/Kochanski_multiplication http://www.hackersdelight.org/MontgomeryMultiplication.pdf http://www.hackersdelight.org/MontgomeryMultiplication.pdf Best I can do with little time and the flood of irrelevant results I saw. Maybe need a thorough write-up on these sorts of things that shows up in Google. At least I serendipitously found a great paper on statically detecting flaws in error propagation: http://pages.cs.wisc.edu/~liblit/dissertations/crubio.pdf http://pages.cs.wisc.edu/~liblit/dissertations/crubio.pdf So, thanks for asking even if not an intended benefit. :)
- fryguy 11y ago
  You can't store a 4096-bit number in 32-bit register, so if you are multiplying numbers together you need to do it a piece (limb) at a time. Given that the arithmetic is modular, you can get away with "leaving some room" and not using all 32-bits, but instead using more 32-bit registers and treating them as if they are say 26-bit registers that can overflow 6-bits. For instance, Curve25519 (255-bit modulus) can be stored with 8 32-bit limbs, or 10 26-bit limbs (among other combinations). So if you do repeated calculations, you don't need to carry all of the bits all of the time. I don't know if it's the case for this bug, but I know it's been a bug in the past that they waited too long to propagate the carry (the extra 6-bits) into the next limb and it's overflowed the 32-bit register. This results in an incorrect calculation.

Jabbles 11y ago

They gave 5 days' notice. https://groups.google.com/forum/#!topic/golang-announce/MLaPAPFlCNY https://groups.google.com/forum/#!topic/golang-announce/MLaP...

JoachimSchipper 11y ago

Note that you probably need to revoke your key if you used it on a 32-bit system and published anywhere close to 64M results. Busy SSL terminators or e.g. OAUTH signers might want to take note. I'm surprised to learn that Go did not already check the result of calculations; that's a pretty standard countermeasure, also to e.g. protect your private key on somewhat-unreliable hardware.

tptacek 11y ago
Not really surprising. This is a common bug, and people are looking for it much more aggressively over the last year. Even Nacl had one of these bugs! There was a carry propagation bug in OpenSSL/BoringSSL/LibreSSL just a few weeks ago.
- parfe 11y ago
  Are you rerferring to CVE-2015-3193? I believe it did not affect libressl
- hannob 11y ago
  The surprising thing is not the bug, it's that go didn't verify the result of the CRT calculation. That's a standard countermeasure (although not present everywhere, Florian Weimer recently did some work on patching implementations that were lacking this check). And nit: The OpenSSL bug didn't affect libressl (I discovered it, I checked for that).
  - tptacek 11y ago
    I stand corrected! Sorry about that.
  - ancarda 11y ago
    How do bugs that affect OpenSSL not affect LibreSSL? Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup?

revelation 11y ago

Go implements their own RSA crypto and related algorithms? I would have expected them to learn from Javas mistakes and use something that has a hope of being maintained indefinitely and isn't coupled to something like language version. JSSE (TLS implementation in Java) is so broken and behind Tomcat ships with some marshal interface to OpenSSL, but that takes considerable effort and software converges to language defaults.

Dobbs 11y ago
Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.
- revelation 11y ago
  That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.
  - f2f 11y ago
    you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
    - deleted 11y ago
      [deleted]
    - revelation 11y ago
      The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.

SyneRyder 11y ago

In case anyone wondered if the discontinued 32-bit Mac OS X versions were also affected (for 10.6 & 10.7 compatibility), apparently "The issue was introduced in Go 1.5", and the last 32-bit binaries for Mac were Go 1.4.2.