
Go 1.5.3 released to address security vulnerability - patrickmn
https://groups.google.com/forum/#!topic/golang-dev/MEATuOi_ei4
======
JoachimSchipper
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
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.

~~~
hannob
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).

~~~
ancarda
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?

~~~
hannob
The bug was introduced with an assembly optimization that got added to OpenSSL
after LibreSSL forked the codebase.

------
Jabbles
They gave 5 days' notice.

[https://groups.google.com/forum/#!topic/golang-
announce/MLaP...](https://groups.google.com/forum/#!topic/golang-
announce/MLaPAPFlCNY)

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

~~~
JoachimSchipper
Linking everything statically is not always an advantage...

~~~
coldtea
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
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.)

~~~
coldtea
> _How does that square? I mean, I have one copy of a shared library on any of
> my machines._

That's all well and good, but that's just you. Real systems often get messed
with multiple copies/versions of shared libraries. Also known as dll-hell in
Windows. In Java land you could easily end up with 20 versions of some jars
just as easily, all installed locally by maven and needed by this or that
lib/framework/etc.

> _Or rather, I do, but that 's because it's my job, and I'm actually good at
> my job._

Citation needed.

~~~
eropple
I haven't seen that on a decently-maintained Linux system--certainly not any
I'd call a "real system"\--in a really long time, unless they're side-by-side
packages from the OS.

~~~
coldtea
What "Linux system"? We're not talking about your distro userland packages
here.

We're talking about businesses deploying multiple server apps and such.
Neither Java nor .NET shops for example rely on "OS packages" for their server
dependencies when it comes to Jars, dlls, etc.

~~~
eropple
Yes, actually, I _was_ talking about distro userland packages, but whatever.
If you're deploying a Java application, everything _should_ be coming out of
Maven (and thus avoid any sort of shared library hell) in the first place, no?

~~~
coldtea
> _Yes, actually, I was talking about distro userland packages, but whatever._

Then you were off topic, since we were discussing Golang packages for
deployment, which aren't userland packages either. But whatever.

> _If you 're deploying a Java application, everything should be coming out of
> Maven (and thus avoid any sort of shared library hell) in the first place,
> no?_

You still get multiple copies of jars. And you still need to replace them. And
you still might have older projects that need particular versions of a jar
that you need to update somehow in case such a long-reaching issue is
discovered (and upstream might not do that at all).

------
tptacek
Carry propagation strikes again!

~~~
bma10
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
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. :)

------
SyneRyder
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.

------
revelation
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.

~~~
tptacek
Go has one of the best TLS implementations available in any language. Adam
Langley at Google oversees it. I think it's more trustworthy than OpenSSL's.

The specific type of cryptographic flaw that occurred here is common to
virtually all crypto libraries. As I said upthread: even Nacl got bit by carry
propagation. Using OpenSSL wouldn't have protected Go from these kinds of
flaws; OpenSSL has had _several_ carry bugs.

~~~
echlebek
I've had a lot of pushback from our operations team about the Go TLS stack,
which they consider to be less secure and less vetted than OpenSSL. They
(rightly) point to this message from Andrew Gerrand in 2013:
[https://groups.google.com/d/msg/golang-
nuts/LjhVww0TQi4/oBLi...](https://groups.google.com/d/msg/golang-
nuts/LjhVww0TQi4/oBLikl38BYUJ)

Do you know if this is still true? Or does it even matter, if OpenSSL is the
only other contender for TLS? As someone who has no expertise in crypto, it's
hard to make sound judgments.

~~~
rsc
Andrew wrote:

> It's really up to the provider of the service in question to make the call.
> All we can say about crypto/tls is that it hasn't been thoroughly reviewed
> from a cryptographic standpoint. Whether that suits your use case or not is
> very much up to you.

That is still true. Of course, the implementation has been reviewed and beat
on in production use more now than it had been in 2013, but the fact remains
that there has been no systematic, independent outside audit focused
specifically on cryptography. On the other hand, the cascade of "interesting"
bugs since 2013 like Goto Fail and Heartbleed suggests that maybe the other
implementations are not quite as audited as one might have expected.

As tptacek mentioned in another comment, Adam Langley is the primary author
and maintainer for Go's crypto packages. He's also one of the key people
involved in Chrome's TLS implementation and Google's use of TLS more broadly,
and he's a significant committer to OpenSSL and the creator and maintainer of
BoringSSL. You can learn more about his work at his blog, imperialviolet.org.
Having Adam involved with Go's crypto/tls raises my comfort level
considerably. It's not Joe Random (or Jane Random) working on the crypto code,
as others suggested below. Even so, even experts make mistakes and it would be
nice to get a second expert to go through it looking for problems.

For the most part Google does not use Go's crypto/tls for user-facing traffic.
That is primarily a detail of Google's pre-existing serving architecture (we
use separate servers to do that, much like putting nginx in front of your main
server, and many engineering years of work went into those servers before Go
even started). Because of that, Google has not really evaluated Go's
crypto/tls one way or the other for that use. I believe we do run Go's
crypto/tls to serve HTTPS on godoc.org, although I'd have to double-check. I
certainly run it on swtch.com, rsc.io, and so on, not that there are real
secrets in any of those servers.

I suspect the largest production user of Go's crypto/tls is CloudFlare. Maybe
someone from there can say something about their comfort level or exposure.

Like Andrew said, it's really up to the provider of the service to make the
call. You can have the same bugs as everyone else, or you can have a different
set of bugs.

~~~
tptacek
For whatever it's worth: lots of experts have looked at the crypto/tls code in
Go.

There's never been a focussed, all-encompassing audit of it. But that's mostly
true of all the other TLS stacks as well. OpenSSL got a complete audit last
year; the same people that worked on that project have spent significant time
working with Go's TLS as well.

I'd caution readers of threads like these not to put too much stock in formal
audits for things like complete TLS implementations. It's incredibly difficult
to get the kind of coverage you'd expect from an audit in something like a
full-featured TLS.

For instance, Microsoft's SCHANNEL has had several contracted audits,
presumably by very smart teams, but I would still trust Go's TLS much more:
every time a new wide-reaching TLS bug class is discovered, someone is going
to check crypto/tls for it. That's not true of a lot of other stacks.

