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

111–120 of 254 posts

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

#111

Post by [deleted] »

pjmlp wrote: post #58
mrb wrote: post #7

This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: 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 Debian bug: https://bugs.debian.org/776391 Great write-up from the discoverer (Qualys): http://www.openwall.com…

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

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

#112

Post by tptacek »

zrm wrote: post #83
tptacek wrote: post #24

Earlier quoted context omitted.

I'm not fully though my morning bootup process and so not really ready to grok this but, can anyone give a quick summary of why gethostbyname() needs to hit the heap at all, let alone with a realloc call? There's a maximum hostname length, and it's not huge. Also: isn't this function just saying "yes" or "no" to a candidate hostname? Can't it just say "no" if the hostname is super long?

gethostbyname() and friends fill in struct hostent: struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ } The pointers in the structure point into the buffer. There could be any number of host aliases or IP addresses.

That's true and a good point, but not (it seems) applicable to this particular function, which validates whether or not the name is one of two fixed-sized formats, right?

(edit) You may be totally right here, by the way.

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

#113

Post by mserdarsanli »

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?

Counting is the hardest thing in programming.

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

#117

Post by derf_ »

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

Well, Ulrich Drepper has been trying to get people to stop using it since 2007: https://udrepper.livejournal.com/16116.html

And not just because of IPv6.

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

#119

Post by skuhn »

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?

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

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

#120

Post by asveikau »

0x0 wrote: post #36

Here is the full Qualys report with an in-depth analysis: http://www.openwall.com/lists/oss-security/2015/01/27/9 Also contains a writeup about a remote Exim exploit (which is the default mail server on at least Debian).

    101       *buffer_size = size_needed;
    102       new_buf = (char *) realloc (*buffer, *buffer_size);
    103
    104       if (new_buf == NULL)
    105         {
    ...
    114           goto done;
    115         }
It's a shame they put that "..." there, because this looked like another potential vulnerability to me, or at least something I would take very critically reading this code. (realloc fails, the caller's variable at buffer_size still gets assigned a larger value, next call thinks it has a larger buffer than it does). Line 110 assigns *buffer_size back to 0 so there is no such problem.
Post reply on HN