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

Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by peterwwillis on Tuesday January 27, 2015 @11:50AM (#8954104)

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.

[ Parent | on HN ]

Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by pilif on Tuesday January 27, 2015 @12:56PM (#8954551)

>You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit

would you? If you want to exploit something that does unauthenticated gethostbyaddr(), then yes, for that you need to control a DNS server (which, btw, isn't harder than controlling a web server to serve malware with).

On the other hand, if you can make your target call gethostbyname() on an arbitrary string, you don't need to control a DNS server.

There are many sites out there that go and fetch user supplied URLs - for example to fetch picture previews.

First you exploit one of these, install a DNS server on them and then you can also exploit the ones which only do gethostbyaddr() :-)

[ Parent | on HN ]

Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by peterwwillis on Tuesday January 27, 2015 @05:11PM (#8956393)

Web servers serving malware are exploited in drive-by scanning; find a vuln in a webapp, drop your malware. It doesn't even take exploiting the system itself, and generally does not affect the web server at all. Taking over a DNS server would take much more work to pwn first, and then require reconfiguring the DNS server. Much more difficult.

Fetching a user-supplied URL is not enough to exploit remotely. You have to exploit the target's DNS resolver, because you have to feed it invalid or impossible records. All existing DNS resolvers will reject these because they break RFC.

It would be much easier to exploit a web app and drop your payload and exploit it locally, which is what everyone currently does to pwn servers with rootkits.

[ Parent | on HN ]