Live data from Hacker News

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

openwall.com

41–50 of 254 posts

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

#41

Qualys Security Advisory: http://www.openwall.com/lists/oss-security/2015/01/27/9 Lots of info about their discovery. Apparently they developed a PoC exploit. They've also included a pretty short test program to determine if a system is vulnerable or not. Here's a gist of the test (copied from their advisory): https://gist.github.com/amlweems/6e78d03810548b4867d6

That's a great writeup. It will be really interesting to see how they achieve remote code execution under those limitations.

Also surprising to note that we've been vulnerable since November 2000.

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

#42
post #4

I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle. Edit: Its back again. Booooo.

We disagree on that, especially when they're widespread (and you don't get much more widespread than glibc) and "drop everything and patch"-level severity. Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.

Having a shorthand makes it a lot easier for people to freak out and panic unnecessarily, too. "Heartbleed" was big enough to warrant a world-wide freakout, but this is a remote buffer overflow with many requirements for success.

From http://www.openwall.com/lists/oss-security/2015/01/27/9 :

  --[ 3 - Mitigating factors ]--------------------------------------------------

  The impact of this bug is reduced significantly by the following reasons:

  - A patch already exists (since May 21, 2013), and has been applied and
  tested since glibc-2.18, released on August 12, 2013:

  - The gethostbyname*() functions are obsolete; with the advent of IPv6,
  recent applications use getaddrinfo() instead.

  - Many programs, especially SUID binaries reachable locally, use
  gethostbyname() if, and only if, a preliminary call to inet_aton()
  fails. However, a subsequent call must also succeed (the "inet-aton"
  requirement) in order to reach the overflow: this is impossible, and
  such programs are therefore safe.

  - Most of the other programs, especially servers reachable remotely, use
  gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also
  known as full-circle reverse DNS) checks. These programs are generally
  safe, because the hostname passed to gethostbyname() has normally been
  pre-validated by DNS software:

  . "a string of labels each containing up to 63 8-bit octets, separated
    by dots, and with a maximum total of 255 octets." This makes it
    impossible to satisfy the "1-KB" requirement.

  . Actually, glibc's DNS resolver can produce hostnames of up to
    (almost) 1025 characters (in case of bit-string labels, and special
    or non-printable characters). But this introduces backslashes ('\\')
    and makes it impossible to satisfy the "digits-and-dots"
    requirement.
You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.

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

#44
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…

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?

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

#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?

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

#46
post #44
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…

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

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

#47

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.

[deleted]

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

#48
post #26

RedHat 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

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

#49

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?

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.

Post reply on HN