Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

openwall.com

Post reply on HN
Print view View original

91–100 of 254 posts

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#91

Post by 4ad »

0x0 wrote: post #87
4ad wrote: post #30

Earlier quoted context omitted.

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.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#92

Post by gtrubetskoy »

JshWright wrote: post #22
michaelx386 wrote: post #19

Earlier quoted context omitted.

Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment and ran the command to check. If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.

You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.

There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#93

Post by lunixbochs »

tonyg wrote: post #89

All those home routers. All those home routers running Linux. All those home routers that are difficult to upgrade. All those home routers that will soon be part of some botnet or other?

Those (Linux-based) home routers usually use uclibc, which is not glibc.

Similarly, they usually use busybox ash as a shell and thus weren't vulnerable to shellshock.

Some do use openssl, so might still be affected by heartbleed.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#94

Post by zrm »

martius wrote: post #63
jap wrote: post #60

Looks like that function is marked as obsolete, anyone know how long that's been the case? https://www.mankier.com/3/gethostbyname "The gethostbyname (), gethostbyaddr (), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead."

For a long time: getaddrinfo() and others are specified in susv3[1] (since 2003 I think). However, gethostbyname() and gethostbyaddr() are still very commonly used, and won't be gone soon. 1/ http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB...

The main reason gethostbyname is deprecated is that it doesn't support IPv6. The implementation of getaddrinfo uses gethostbyname, so you're using it either way.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#95

Post by mlrtime »

cylo wrote: post #53
tonyhb wrote: post #48

Earlier quoted context omitted.

The Qualys security advisory says that it was fixed independently in 2013, so RHEL6 and 7 might already have the fix. http://www.openwall.com/lists/oss-security/2015/01/27/9

Yes, it was fixed upstream in glibc, but that doesn't mean the distros actually get the patch into their distribution. In fact, the report states: "Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example."

Correct, if you download the src rpm for the latest version of glibc for RHEL 6.5 and compare it with the fix, you will see it is not patched.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#96

Post by tonyg »

lunixbochs wrote: post #93
tonyg wrote: post #89

All those home routers. All those home routers running Linux. All those home routers that are difficult to upgrade. All those home routers that will soon be part of some botnet or other?

Those (Linux-based) home routers usually use uclibc, which is not glibc. Similarly, they usually use busybox ash as a shell and thus weren't vulnerable to shellshock. Some do use openssl, so might still be affected by heartbleed.

Good point! Hooray for avoidance of software monocultures.

On the other hand, I shall now work hard to stop worrying about undiscovered vulnerabilities in uclibc.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#97

Post by JshWright »

gtrubetskoy wrote: post #92
JshWright wrote: post #22

Earlier quoted context omitted.

You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.

There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.

Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#98

Post by IshKebab »

pjmlp wrote: post #56
userbinator wrote: post #45

Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?

> Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly? Yet there seems to exist this belief in the C world, that they can.

Yeah, "I would have written it right."

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#99

Post by phoboslab »

eslaught wrote: post #82
0x0 wrote: post #46

Earlier quoted context omitted.

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"

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#100

Post by Karunamon »

csmeu wrote: post #88
Signez wrote: post #12

Earlier quoted context omitted.

I think the parent comment was sarcastic.

I wasn't being sarcastic. Adding a tagline, media friendly name or keywords is unprofessional. Simply, severity is then ranked by how popular the press or security bloggers can market the word, not by the respective severity of the CVE. Its a popularity contest, nothing more. As someone who deals with every damn sensationalist story at a financial company, having every fucking client phone up about every damn marketo…

"Professionalism" is overrated. And this appears to be a "drop everything and fix it" bug, so the "damn sensationalism" is warranted. If clients calling you about a vulnerability bothers you, get out of this line of work, please.

People actually giving a shit about security holes is something we've been wanting for a long time. It beats the hell out of the alternative, something we've been dealing with since the 90s or so!

Post reply on HN