Hacker News Reader

A note about Go. Go has its own DNS resolver, but unfortunately, if you compile natively, it's not enabled by default. It's only enabled if you cross-compile, or if you disable cgo, or if you rebuild the standard library with -tags netgo.

/edit: a second note about Go; even without the native resolver, Go uses getaddrinfo, not gethostbyname*, and it's not vulnerable.

So.... an application acts differently if it is cross-compiled? And if there's a vuln in the go resolver, binaries are "maybe" vulnerable, depending on whether they were cross-compiled or not?

I'm not sure why you were downvoted. In an ideal world, the behavior of the native Go resolver and the host resolver should be the same, but in the real world they might behave differently and might have different bugs. The nice thing about the native Go resolver is that it's written in a memory safe language which prohibits bugs like these.

The upstream patch is dated "Mon, 21 Jan 2013". Does this affect Redhat and Debian because they use older glibc versions and didn't backport this fix?

yes

What versions are affected? E.g. Ubuntu 14.04 appears to be on 2.19-0ubuntu6.5 (just updated). Does that include the fix?

You can check the libc version with:

dpkg -s libc6

For my Debian 7 servers it reports "Version: 2.13-38+deb7u7" after upgrading. Everything below that (eg. "*u6") is vulnerable. I don't know about the specific version numbers in Ubuntu though.

Edit: the fixed Ubuntu version is "2.15-0ubuntu10.10"

Per the Ubuntu security advisory for this, 14.04 is not impacted.

Full blog post coming, but 14.04 was never vulnerable. glibc 2.17 was the last vulnerable version.

The scope of this vulnerability is huge! A lot of server applications attempt to resolve or reverse-resolve network clients's hostnames or IP addresses when a connection is established, so they would all be potentially vulnerable: the malicious client controlling his DNS records simply needs to return specially crafted hostname or address data that is too big to fit in the buffer.

This overstates things a bit - hostnames that can be returned by the reverse DNS resolver can't trigger the vulnerability (maximum label length of 63). It needs to be a hostname supplied by a non-DNS method (eg. the POC uses the HELO SMTP command).

> And this affects everything, no matter what language the server application is written in: C, Python, Golang, PHP, Java...

Assuming the runtime links to glibc, which unfortunately most do.