Dumb question perhaps, but is there a command line command I can run to test before and after that this patch has been applied successfully?
CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
51–60 of 254 posts
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#52Earlier quoted context omitted.
Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_... . Note that this is a HEAD link, so if there are changes after I post this they should appear. I don't claim to have spotted the suspicious code (it's not ... super-accessible), just wanted to provide a link to the file in question.
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?
[deleted]
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#53RedHat has patches out for RHEL5 only so far https://rhn.redhat.com/errata/RHSA-2015-0090.html
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."
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#54Glancing 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?
Not really. h_addr_ptrs and h_alias_ptr look very similar, and that style with the random linebreaks is practically begging for this kind of error. I'm far more disappointed that so many programmers haven't adopted better systems, systems that avoid the possibility of this kind of error entirely.
Unless I've misread the patch, the problem isn't that they counted the sizeof the wrong thing, it's that they forgot one of the things entirely. sizeof() the same thing twice would have been explained by similar names.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#55Glancing 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?
It is nice if they can count. However instead of sending them back to kindergarten, it might make sense to find a compiler/language/framework that would make inability to count not result in easy remote exploits.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#56Glancing 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.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#57If this was patched in 2013 why is it an issue now?
Because it was "silently" fixed so nobody applied the patch to existing, shipping systems.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#58This 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.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#59Earlier 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?
[deleted]
Right, but they only need to do that computation because they're dynamically allocating storage. But the maximum size of a hostname is so small that hitting the allocator is costing them more than static allocation would.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#60Looks 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."