GHOST: glibc vulnerability

hua · 01-28-2015, 03:33 AM

Hi all,

How serious this is?

Background Information

GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.
Impact

The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.

https://access.redhat.com/articles/1332213

Keruskerfuerst · 01-28-2015, 05:15 AM

You should update as soon as possible.
High vulnerability.

kooru · 01-28-2015, 05:27 AM

Depending about the distro. For long support distro as red hat you have to fixed the bug.
For normal distro as Fedora, the bug should be already fixed.
Anyway, here more information.

hua · 01-28-2015, 06:30 AM

Quote:

Originally Posted by Keruskerfuerst

You should update as soon as possible.
High vulnerability.

Maybe. But maybe not.

Quote:

Here is a list of potential targets that we investigated (they all call
gethostbyname, one way or another), but to the best of our knowledge,
the buffer overflow cannot be triggered in any of them:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,
pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,
vsftpd, xinetd.

That being said, we believe it would be interesting if other people
could have a look, just in case we missed something.

It looks like that this buffer-overflow in the glibc can be triggered by other external applications (which passes variables to it). But the tests were not focused to find real vulnerable applications (which can trigger it) but rather for vulnerability in general in glibc.

It doesn't mean it cannot be exploited but it's not so inevitable as it was published.

Miati · 01-28-2015, 12:17 PM

This is a big issue... but only in specific circumstances.

Directly from their report

Quote:

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.

Head_on_a_Stick · 01-28-2015, 02:49 PM

Arch patched this a year and a half ago...

rokytnji · 01-28-2015, 03:19 PM

Code:

@scuzbucket:~
$ ldd --version
ldd (Debian GLIBC 2.19-13) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Be not afeard.

matsvw · 01-28-2015, 05:39 PM

My Fedora 14 server is vulnerable according to the scripts. glibc on this server is version 2.13 and I cannot update it via yum. Any thoughts?

kooru · 01-29-2015, 03:46 AM

Quote:

Originally Posted by matsvw

My Fedora 14 server is vulnerable according to the scripts. glibc on this server is version 2.13 and I cannot update it via yum. Any thoughts?

The end support of Fedora 14 was 2011-12-08!!!
And if you still use it as server, it's a big mistake.
The last version of Fedora is 21.

matsvw · 01-29-2015, 11:39 AM

Quote:

Originally Posted by kooru

The end support of Fedora 14 was 2011-12-08!!!
And if you still use it as server, it's a big mistake.
The last version of Fedora is 21.

Sadly, I don't have control over it.

unSpawn · 01-29-2015, 05:24 PM

Quote:

Originally Posted by matsvw

Sadly, I don't have control over it.

While mitigating circumstances are there, as exploiting this vulnerability isn't that easy as many commonly exposed services have been tested to be not vulnerable (http://www.openwall.com/lists/oss-se.../2015/01/27/18), this does not mean that you should aim to stay with an unsupported Linux distribution release.

Since you have posted no details that could help us help you all I can say is that yours is a problem you have to solve with whomever provides it. Have them change it or ponder the alternatives. If unsure post details but do not expect anyone here to support a Linux distribution release the vendor doesn't support.
Linux may be free to use but using it should not be free of responsibilities.

yukinK · 02-05-2015, 02:13 AM

According to RPM query, I've glibc 2.3.4-2.25,glibc-common 2.3.4-2.25 installed in my server. But when i tried run the vulnerability check script, it returned as "gcc: command not found".

i checked the "bin" directories i couldn't find the gcc script file and any other sysmlinks. i'm curious to know whether my server is vulnerable or not. Google is not helping much!! I'm returning to linux environment after a long stint with windows.

any help and guidance would be appreciated.

Tamil

unSpawn · 02-05-2015, 04:16 PM

Quote:

Originally Posted by yukinK

According to RPM query, I've glibc 2.3.4-2.25,glibc-common 2.3.4-2.25 installed in my server.

AFAIK that's a RHL 8.0-like or RHEL 4-like glibc version. If that's the case your distro release is way old.

Quote:

Originally Posted by yukinK

when i tried run the vulnerability check script, it returned as "gcc: command not found".

Consider not having a C compiler / development packages installed a minor nuisance compared to running an ancient, unsupported distro release.

yukinK · 02-05-2015, 11:28 PM

Yeah, The Distro Version is RHEL4, I have no control over the updating the distro.

Anyways, Could you tell how to check, that my server is vulnerable or not? I would appreciate any help!

matsvw · 02-06-2015, 10:27 AM

Quote:

Originally Posted by unSpawn

While mitigating circumstances are there, as exploiting this vulnerability isn't that easy as many commonly exposed services have been tested to be not vulnerable (http://www.openwall.com/lists/oss-se.../2015/01/27/18), this does not mean that you should aim to stay with an unsupported Linux distribution release.

Since you have posted no details that could help us help you all I can say is that yours is a problem you have to solve with whomever provides it. Have them change it or ponder the alternatives. If unsure post details but do not expect anyone here to support a Linux distribution release the vendor doesn't support.
Linux may be free to use but using it should not be free of responsibilities.

As a silver lining, this issue has given me the leverage needed to decommission and/or upgrade the effected servers. On a happier note, all of my newer Ubuntu servers were either up to date or upgraded without drama.