5 ms·

This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https:

by mrb 12y ago

This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hp=fef94eab0bd308d5059a2588c753bf9a4926845d https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6... Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 Debian bug: https://bugs.debian.org/776391 https://bugs.debian.org/776391 Great write-up from the discoverer (Qualys): http://www.openwall.com/lists/oss-security/2015/01/27/9 http://www.openwall.com/lists/oss-security/2015/01/27/9 - thanks amlweems! (https://news.ycombinator.com/item?id=8954069 https://news.ycombinator.com/item?id=8954069) It looks like when an application calls a function of the gethostbyname()/gethostbyname_r() family but passes a buffer and a buffer length that is too short to store the result, then the function sometimes fails to detect there is not enough space due to a miscalculation of how much space it needs, leading to a heap overflow. This means potentially arbitrary code execution! Edit: Both the reentrant version (gethostbyname_r) and non-reentrant one (gethostbyname) are affected (the non-reentrant one uses a fixed buffer length). 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. And this affects everything, no matter what language the server application is written in: C, Python, PHP, Java... Edit #2: it looks like the bug was patched 2 years ago, but the fact it was exploitable was not understood until today, hence why a CVE was only assigned now. Edit #3: Apps written in Golang are not vulnerable: https://news.ycombinator.com/item?id=8954011 https://news.ycombinator.com/item?id=8954011 - thanks 4ad!

4ad 12y ago
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.
- 0x0 12y ago
  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?
  - 4ad 12y ago
    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.
tveita 12y ago
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?
- 0x0 12y ago
  yes
  - eslaught 12y ago
    What versions are affected? E.g. Ubuntu 14.04 appears to be on 2.19-0ubuntu6.5 (just updated). Does that include the fix?
    - phoboslab 12y ago
      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"
    - skuhn 12y ago
      Per the Ubuntu security advisory for this, 14.04 is not impacted.
    - jerematasno 12y ago
      Full blog post coming, but 14.04 was never vulnerable. glibc 2.17 was the last vulnerable version.
pjmlp 12y ago
> 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.
- deleted 12y ago
  [deleted]
caf 12y ago
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).

by mrb 12y ago

4ad 12y ago

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.

0x0 12y ago
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?
- 4ad 12y ago
  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.

tveita 12y ago

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?

0x0 12y ago
yes
- eslaught 12y ago
  What versions are affected? E.g. Ubuntu 14.04 appears to be on 2.19-0ubuntu6.5 (just updated). Does that include the fix?
  - phoboslab 12y ago
    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"
  - skuhn 12y ago
    Per the Ubuntu security advisory for this, 14.04 is not impacted.
  - jerematasno 12y ago
    Full blog post coming, but 14.04 was never vulnerable. glibc 2.17 was the last vulnerable version.

pjmlp 12y ago

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

deleted 12y ago
[deleted]

caf 12y ago

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