
CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow - martius
http://www.openwall.com/lists/oss-security/2015/01/27/9
======
DangerousPie
Here is the test program, from [http://www.openwall.com/lists/oss-
security/2015/01/27/9](http://www.openwall.com/lists/oss-
security/2015/01/27/9)

[https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63](https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63)

To test your system, simply run this (but obviously only after making sure
gistfile1.c is clean ;))

    
    
        wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
        gcc gistfile1.c -o CVE-2015-0235
        ./CVE-2015-0235

~~~
windsurfer
I always laugh when people give you a URL to C code to test for remote code
execution...

~~~
fragmede
Why?

Reproducers are standard fare and it's not like the code in this case is
obfuscated. Are magic code goblins going to come and invoke Ken Thompson's
untrustable computing and make your computer install windows and join a botnet
or something?

~~~
Natsu
You're piping random executables from the internet without even looking at
them to see what they do if you run that command.

~~~
Xylakant
There's no pipe involved in the GPs posting. It downloads a source file and
the post even points out to check the file before compiling. I actually copied
and pasted the test code from the original advisory. Should I have typed it in
with my own bare fingers to be more secure? I agree with your sentiment in
general, you just picked the wrong example to bash here.

~~~
acveilleux
The average Linux IT guy will not read the C code. Many of them wouldn't be
able to really understand what it does either. And this is best case code is
simple and easy to grok.

~~~
Xylakant
If you're not reading the code you can just as well curl-and-pipe it. However,
we run so much code on our computers that is trusted-by-association (oh,
that's from apache.org, that's probably safe!) that it probably does not
matter anyways.

------
amlweems
Qualys Security Advisory: [http://www.openwall.com/lists/oss-
security/2015/01/27/9](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](https://gist.github.com/amlweems/6e78d03810548b4867d6)

~~~
kyboren

        - At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit
          machines, and 8 bytes on 64-bit machines). Bytes can be overwritten
          only with digits ('0'...'9'), dots ('.'), and a terminating null
          character ('\0').
    
        - Despite these limitations, arbitrary code execution can be achieved.
          As a proof of concept, we developed a full-fledged remote exploit
          against the Exim mail server, bypassing all existing protections
          (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will
          publish our exploit as a Metasploit module in the near future.
    

Wow, that's actually amazing! I never would have thought it possible. As
tonyhb says, it will be really interesting 'in the near future' to see how
they managed to do it.

~~~
simplexion
Does this mean it currently is only a problem for mail servers?

------
WestCoastJustin
When the patches are available, you need to update, and likely reboot. Mattias
Geniar talks about using the following command to find processes depending on
libc, any of which could be running the vulnerable code, these are core
processes that you probably cannot just cycle without a reboot [1]. For me the
listing looks something like this: agetty, auditd, dbus-daem, dhclient, init,
master, mysqld, rsyslogd, sshd, udevd, xinetd. Many of these deal with
hostnames, so I would want to be sure everything is clean, and the best option
is likely a reboot.

    
    
      lsof | grep libc | awk '{print $1}' | sort | uniq
    

[1] [http://ma.ttias.be/critical-glibc-update-
cve-2015-0235-getho...](http://ma.ttias.be/critical-glibc-update-
cve-2015-0235-gethostbyname-calls/)

~~~
peterwwillis
They're only attacking host-lookup, so you just have to worry about people who
can connect to your service and are able to control name server response. This
means your network services that are internet-accessible. Everything else can
wait for a maintenance window for the reboot.

    
    
      ~# netstat -lnp | grep -e "\(tcp.*LISTEN\|udp\)" | cut -d / -f 2- | sort -u
      cupsd          
      dnsmasq        
      httpd          
      nmbd           
      ntpd           
      qemu-kvm       
      rpc.portmap    
      rpc.statd      
      sendmail: acce 
      smbd           
      ssh           
      sshd

~~~
jerematasno
It doesn't have to be internet accessible, AFAIK. If an attacker can get
something to do arbitrary DNS lookups, I think it can be attacked. For
instance, monitoring/log correlation software might be vulnerable.

~~~
NickNameNick
If you have backend systems parsing XML, then an XXE[1] attack could trigger a
DNS lookup, for example.

[1][https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...](https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing)

~~~
sarciszewski
Ooh, that could lead to some very interesting attack vectors. :D

------
mrb
This is the original report:
[https://sourceware.org/bugzilla/show_bug.cgi?id=15014](https://sourceware.org/bugzilla/show_bug.cgi?id=15014)

Upstream patch:
[https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d...](https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd)
Full diff:
[https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6...](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hp=fef94eab0bd308d5059a2588c753bf9a4926845d)

Red Hat bug:
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235)

Debian bug: [https://bugs.debian.org/776391](https://bugs.debian.org/776391)

Great write-up from the discoverer (Qualys):
[http://www.openwall.com/lists/oss-
security/2015/01/27/9](http://www.openwall.com/lists/oss-
security/2015/01/27/9) \- thanks amlweems!
([https://news.ycombinator.com/item?id=8954069](https://news.ycombinator.com/item?id=8954069))

It looks like when an application calls a function of the
gethostbyname()/gethostbyname_r() family but passes a buffer and a buffer
length that is too short to store the result, then the function sometimes
fails to detect there is not enough space due to a miscalculation of how much
space it needs, leading to a heap overflow. This means potentially arbitrary
code execution! Edit: Both the reentrant version (gethostbyname_r) and non-
reentrant one (gethostbyname) are affected (the non-reentrant one uses a fixed
buffer length). The scope of this vulnerability is huge! A lot of server
applications attempt to resolve or reverse-resolve network clients's hostnames
or IP addresses when a connection is established, so they would all be
potentially vulnerable: the malicious client controlling his DNS records
simply needs to return specially crafted hostname or address data that is too
big to fit in the buffer. And this affects everything, no matter what language
the server application is written in: C, Python, PHP, Java...

Edit #2: it looks like the bug was patched 2 years ago, but the fact it was
exploitable was not understood until today, hence why a CVE was only assigned
now.

Edit #3: Apps written in Golang are not vulnerable:
[https://news.ycombinator.com/item?id=8954011](https://news.ycombinator.com/item?id=8954011)
\- thanks 4ad!

~~~
4ad
A note about Go. Go has its own DNS resolver, but unfortunately, if you
compile natively, it's not enabled by default. It's only enabled if you cross-
compile, or if you disable cgo, or if you rebuild the standard library with
-tags netgo.

/edit: a second note about Go; even without the native resolver, Go uses
getaddrinfo, not gethostbyname*, and it's not vulnerable.

~~~
0x0
So.... an application acts differently if it is cross-compiled? And if there's
a vuln in the go resolver, binaries are "maybe" vulnerable, depending on
whether they were cross-compiled or not?

~~~
4ad
I'm not sure why you were downvoted. In an ideal world, the behavior of the
native Go resolver and the host resolver should be the same, but in the real
world they might behave differently and might have different bugs. The nice
thing about the native Go resolver is that it's written in a memory safe
language which prohibits bugs like these.

------
martius
From
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235)

"A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which
is used by the gethostbyname() and gethostbyname2() glibc function call. A
remote attacker could use this flaw to execute arbitary code with the
permissions of the user running the application."

~~~
unwind
Obligatory git link for the curious:
[https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_...](https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_dots.c;hb=HEAD).

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.

~~~
tptacek
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?

~~~
tedunangst
From the GNU coding standards:

> Avoid arbitrary limits on the length or number of any data structure,
> including file names, lines, files, and symbols, by allocating all data
> structures dynamically.

~~~
userbinator
[http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_...](http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names)

 _the entire hostname (including the delimiting dots but not a trailing dot)
has a maximum of 253 ASCII characters_

In general that is a good guideline, but when the standard (RFC1035) says
there is an absolute limit, there is little value in going above that as it is
likely that other systems won't be able to handle it. The added complexity of
dynamic allocation is also an opportunity for bugs, like this one.

~~~
tptacek
I think he's making fun of that glibc principle.

Again, this is especially silly if (as it appears to first glance) the bug is
in a _hostname validation function_ , and so flexible allocation could only
ever be useful in the case of a hostname that must fail validation anyways.

------
tonyg
All those home routers. All those home routers running Linux. All those home
routers that are difficult to upgrade. All those home routers that will soon
be part of some botnet or other?

~~~
lunixbochs
Those (Linux-based) home routers usually use uclibc, which is not glibc.

Similarly, they usually use busybox ash as a shell and thus weren't vulnerable
to shellshock.

Some do use openssl, so might still be affected by heartbleed.

~~~
tonyg
Good point! Hooray for avoidance of software monocultures.

On the other hand, I shall now work hard to stop worrying about undiscovered
vulnerabilities in uclibc.

------
rkwasny
This looks like an "accident" by PR Agency:

[http://www.frsag.org/pipermail/frsag/2015-January/005722.htm...](http://www.frsag.org/pipermail/frsag/2015-January/005722.html)
From: Mar 27 Jan 15:28:45 CET 2015

Half an hour after Redhat lifted embargo from the ticket:
[https://bugzilla.redhat.com/show_activity.cgi?id=1183461](https://bugzilla.redhat.com/show_activity.cgi?id=1183461)
2015-01-27 10:03:14 EST Removed: EMBARGOED CVE-2015-0235

If this is true this lady gets an award for best security disclosure this year
;-)

~~~
4mnt
Yep, she published too soon.
[http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...](http://www.frsag.org/pipermail/frsag/2015-January/005727.html)

------
jap
Looks like that function is marked as obsolete, anyone know how long that's
been the case?

[https://www.mankier.com/3/gethostbyname](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."

~~~
martius
For a long time: getaddrinfo() and others are specified in susv3[1] (since
2003 I think). However, gethostbyname() and gethostbyaddr() are still very
commonly used, and won't be gone soon.

1/ [http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-
generic/LSB...](http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-
Core-generic/normativerefs.html#STD.SUSV3)

~~~
zrm
The main reason gethostbyname is deprecated is that it doesn't support IPv6.
The implementation of getaddrinfo uses gethostbyname, so you're using it
either way.

------
rdhyee
As a non-professional in the area of Linux security, let me share what I
figured out while patching Ubuntu 12.04 servers for GHOST. In my situation at
least, I got confused by looking for glibc and eglibc, which are listed as
packages to be patched in [http://people.canonical.com/~ubuntu-
security/cve/2015/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2015/CVE-2015-0235.html).

I wanted to know what version of glibc and eglibc my servers were running so
that I could check that they were getting updated. Running

    
    
       dpkg -s glibc 
    

and

    
    
       dpkg -s eglibc 
    

turned up nothing. How could that be since there had to be a C library?!

Answer: there are indeed compiled C libraries on my servers. I found that the
key packages to update were related to libc6
([http://packages.ubuntu.com/precise/libc6](http://packages.ubuntu.com/precise/libc6)),
which were compiled from eglibc.

At any rate, I patched my servers with a typical procedure:

    
    
        sudo apt-get update 
        sudo unattended-upgrades
    

BTW, it helped me to understand that Ubuntu 12.04 uses eglibc and not glibc:
[http://askubuntu.com/questions/372864/why-ubuntu-uses-
eglibc...](http://askubuntu.com/questions/372864/why-ubuntu-uses-eglibc-
instead-of-glibc/372880#372880) to make sense of the charts at
[http://people.canonical.com/~ubuntu-
security/cve/2015/CVE-20...](http://people.canonical.com/~ubuntu-
security/cve/2015/CVE-2015-0235.html), especially the reason for the "DNE"
(does not exist?) for Ubuntu 12.04 and glibc.

Hope this is clarifying to someone out there. Would love to hear confirmation
or refutation of my reasoning here.

~~~
yrro
FYI, if you want to identify which package shipped a particular file:

    
    
        $ dpkg -S /lib/x86_64-linux-gnu/libc.so.6 
        libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
    

Hence 'libc6' is the package as you figured out.

If you want to see the status of a particular vulnerability in Debian, you can
use the Security Tracker: [https://security-
tracker.debian.org/tracker/CVE-2015-0235](https://security-
tracker.debian.org/tracker/CVE-2015-0235) which links to the security advisory
and tells you that the bug was fixed in version 2.13-38+deb7u7 of the package.

Note that any programs running before you upgraded the library will need to be
restarted in order to use the fixed version. There's a program called
checkrestart that will tell you which programs need to be restarted, or you
can play it safe and reboot your system after applying library updates.

~~~
rdhyee
thanks especially for the tip about restarting the system, just in case.

------
0x0
Here is the full Qualys report with an in-depth analysis:

[http://www.openwall.com/lists/oss-
security/2015/01/27/9](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).

~~~
jameskilton
From this, the vulnerability was fixed in May 2013 so any systems from there
or later (e.g. Ubuntu 14.04) are fine. Older systems obviously now need to
wait for the patches to come through.

~~~
danielweber
If you are looking for date-based checking[1], August 2013 is when glibc 2.18
was released.[2]

[1] I wouldn't.

[2] [http://ftp.gnu.org/gnu/glibc/](http://ftp.gnu.org/gnu/glibc/)

------
ryan-c
Reading the thread, it does appear that someone broke embargo on this.

[http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...](http://www.frsag.org/pipermail/frsag/2015-January/005727.html)

[http://www.frsag.org/pipermail/frsag/2015-January/005726.htm...](http://www.frsag.org/pipermail/frsag/2015-January/005726.html)

~~~
martius
Yes, the mail you link says:

"I will keep you posted in next hours. I send the notice to early. Big fail of
my own. Stay tuned."

------
beagle3
As far as I can tell, sshd has always used getaddrinfo() which is not
vulnerable (rather than gethostbyname() which is). Can anyone confirm?

According to this comment:
[https://news.ycombinator.com/item?id=8954458](https://news.ycombinator.com/item?id=8954458)
, getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes'
ssh setup vulnerable or not?

~~~
cft
Even if it used gethostbyname() , I fail to understand how one would supply an
invalid IP address to an sshd program? It calls an IP resolver after the TCP
connection has been established, reading off the IP from there. From what I
understood from their exim HELO example, one has to feed in a crazy IP
"address" to gethostbyname() to trigger the bug.

~~~
beagle3
Well, it obviously does getaddrinfo() on the incoming TCP connection to get
the hostname (which is reported in the log, unless you have a 'UseDNS no'
directive) -- and at least in my setup (which is mostly vanilla Debian), it
seems to resolve that name again to an IP address, compare that to the IP
address of the connection, and warn if it does not match.

Thus, an attacker controlling the PTR record for a given IP might provide a
GHOST-compliant name in that PTR record; Then, connect to the ssh daemon, wait
for it to read the PTR record - and if it gethostbyname() on it, it's game
over.

Quite a few log processors would do that. The reason I'm worried specifically
about sshd is that it is usually the only port ever listening to the world-
and-not-firewalled on my servers (and a non-standard, at that - and only
allowing public key authentication) - but despite this generally-regarded-as-
secure setting, GHOST may prove it vulnerable.

~~~
cft
But why would this malicious PTR record be fed into gethostbyname() again? At
that point of getting a reverse lookup result, sshd is done checking.

~~~
beagle3
To see that it resolves back to the IP address from which the connection is
made. It's a standard check that many servers do, and ssh does too (and gives
off a warning if they don't match). I'm not sure if it does it in a way that's
vulnerable or not, though - but it surely does so by default.

From man sshd_config:

    
    
         UseDNS  Specifies whether sshd(8) should look up the
         remote host name and check that the resolved host name
         for the remote IP address maps back to the very same 
         IP address.  The default is “yes”.

------
DangerousPie
Looks like this was still supposed to be embargoed. I feel sorry for the
maintainers who now have to deal with this getting leaked...

------
gtrubetskoy
RedHat has a fix for 6 and 7 now:
[https://rhn.redhat.com/errata/RHSA-2015-0092.html](https://rhn.redhat.com/errata/RHSA-2015-0092.html)

~~~
McGlockenshire
Does anyone have any insight into when we'll see CentOS packages start hitting
the mirrors?

~~~
nilic
They are now available, on CentOS 6.4 yum update glibc installs
glibc-2.12-1.149.el6_6.5

changelog: * Mon Jan 19 2015 Siddhesh Poyarekar <siddhesh@redhat.com> \-
2.12-1.149.5 \- Fix parsing of numeric hosts in gethostbyname_r
(CVE-2015-0235, #1183533).

Qualys GHOST program returns "not vulnerable" after the upgrade.

~~~
cpncrunch
I just updated this on a CentOS 6 box, and it broke the server. After I
rebooted, it never came online. Luckily it was a backup server, so it's not
critical. Right now I'm just waiting for the customer to contact iweb to
figure out what went wrong. This is a vanilla server with just some of my
software installed (which couldn't possibly have prevented the server from
rebooting).

Obviously there is some dependency that they forgot to add, so I would hold
off on updating anything unless you don't really care if the server is offline
for a while.

~~~
cpncrunch
The problem was the iweb smart layer - they just needed to recreate the smart
layer.

------
mirimir

        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.
    

See "Re: Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname
buffer overflow" <[http://seclists.org/oss-
sec/2015/q1/283>](http://seclists.org/oss-sec/2015/q1/283>).

~~~
SaveTheRbtz
nginx on most supporting platforms (`NGX_HAVE_GETADDRINFO && NGX_HAVE_INET6`)
uses `getaddrinfo(3)`.

------
Karunamon
Details on this one appear to be quite sparse - under what use cases would a
remote user be able to craft invalid IP addresses?

~~~
yxhuvud
It seems it was made public by accident, so it is not totally surprising that
information is sparse :(

~~~
vezzy-fnord
Given that I recently received a Debian Security Advisory which specifically
addressed this CVE, I don't think it was accidental at all.

~~~
tedunangst
I think the timing was accidental due to leaking. The coordinated release
became uncoordinated.

------
jerematasno
We wrote a quick blog post on this. The main meaningful feature is a table of
distros, versions, and whether they're not vulnerable, vulnerable but with a
patch, or vulnerable with no patch yet. I am accepting requests for other
distros, and of course if you have any corrections I'd love to hear them!

[http://chargen.matasano.com/chargen/2015/1/27/vulnerability-...](http://chargen.matasano.com/chargen/2015/1/27/vulnerability-
overview-ghost-cve-2015-0235.html#versions)

------
yk
So what I figured out so far: This is a quite nasty bug that may or may not
affect everything that links against glibc (or eglibc). However the bug was
fixed in glibc 2.18 and the advisory [1] includes a test program at the start
of section 4. From this Ubuntu 10.04 LTS and 12.04 LTS are affected, but not
14.04 LTS. ( Can someone confirm this?)

[1] [http://www.openwall.com/lists/oss-
security/2015/01/27/9](http://www.openwall.com/lists/oss-
security/2015/01/27/9)

~~~
ubiquitousthey
14.04 and 13.10 are not vulnerable

------
smcquaid
Here is a diff removing the vulnerability:
[https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/dig...](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/digits_dots.c;h=e007ef47a41b69437655c26565689be393705a82;hp=2b862956e9a8c39bbccbea982add1d7ab2d16ab2;hb=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hpb=fef94eab0bd308d5059a2588c753bf9a4926845d)

------
yeukhon
Is Ubuntu 12.04 vulnerable to this?

>> this vulnerability affects many systems from Linux glibc-2.2 version
published on 10 November 2000.

>> a fixed was pushed to glibc-2.17 et glibc-2.18

Ran dpkg -l libc6 on 12.04.5 shows it's 2.15. So anything before 2.17?

/lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.7)
stable release version 2.15, by Roland McGrath et al.

~~~
href
According to Canonical it is:
[http://www.ubuntu.com/usn/usn-2485-1/](http://www.ubuntu.com/usn/usn-2485-1/)

------
csmeu
I'm glad the moderator removed GHOST from the subject line. CVEs don't need a
media friendly handle.

Edit: Its back again. Booooo.

~~~
Karunamon
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.

~~~
Signez
I think the parent comment was sarcastic.

~~~
csmeu
I wasn't being sarcastic.

Adding a tagline, media friendly name or keywords is unprofessional. Simply,
severity is then ranked by how popular the press or security bloggers can
market the word, not by the respective severity of the CVE. Its a popularity
contest, nothing more.

As someone who deals with every damn sensationalist story at a financial
company, having every fucking client phone up about every damn marketoid
creation even if it doesn't affect our platform detracts from doing real work.

Let's play their trick:

Its the X Factor of security.

~~~
Karunamon
"Professionalism" is overrated. And this appears to be a "drop everything and
fix it" bug, so the "damn sensationalism" is warranted. If clients calling you
about a vulnerability bothers you, get out of this line of work, please.

People actually giving a shit about security holes is something we've been
wanting for a long time. It beats the hell out of the alternative, something
we've been dealing with since the 90s or so!

~~~
csmeu
Professionalism is thinking and understanding before you start firing a gun at
your infrastructure, testing stuff and not shooting client SLAs.

We do that bit between the CVE being announced and patching ahit, not when the
press goes ape shit.

So, that's overrated is it?

~~~
__david__
Yes. When there's an exploit available _now_ , you really don't have that
luxury.

------
ars
Debian was updated, but their website does not show it.

It's version 2.13-38+deb7u7

A standard update command should get it, but if not you can find it here:

[http://security.debian.org/pool/updates/main/e/eglibc/](http://security.debian.org/pool/updates/main/e/eglibc/)

------
atom_enger
Here's a quick writeup I made with all of the information I found in this
thread.

Feedback welcome:

[http://product.reverb.com/2015/01/28/patching-
cve-2015-0235-...](http://product.reverb.com/2015/01/28/patching-
cve-2015-0235-aka-ghost-2/)

~~~
sandstrom
Good writeup, I liked the gists you picked out.

I've got some feedback though:

The bug has been fixed (May 21, 2013, between the releases of glibc-2.17 and
glibc-2.18).

So your statement "This bug effects all versions of libc6 greater than 2.2+
(which was released Nov, 10, 2000) so you’ll be really lucky if you’re not
vulnerable." is wrong.

For example, Ubuntu 14.04 uses glibc-2.19-1 which isn't affected.

~~~
atom_enger
Thanks for the feedback. I've updated the post to omit that statement since
it's not entirely helpful.

------
brunes
Does anyone have any pointers as to an example hostname that would trigger
this? I am trying to determine if one can write a signature for it.

\--Conclusion: inet_aton() is the only option, and the hostname must have one
of the following forms: "a.b.c.d", "a.b.c", "a.b", or "a", where a, b, c, d
must be unsigned integers, at most 0xfffffffful, converted successfully (ie,
no integer overflow) by strtoul() in decimal or octal (but not hexadecimal,
because 'x' and 'X' are forbidden). \--

So essentially, any DNS lookups of the form a.b.c.d, a.b.c, a.b, or a where
a,b,c,d are all numbers, should be considered suspicious?

------
mef
Relevant AWS thread
[https://forums.aws.amazon.com/thread.jspa?threadID=170359&ts...](https://forums.aws.amazon.com/thread.jspa?threadID=170359&tstart=0)

~~~
spjwebster
ALAS covering this vulnerability:

[https://alas.aws.amazon.com/ALAS-2015-473.html](https://alas.aws.amazon.com/ALAS-2015-473.html)

As usual, the Elastic Beanstalk team (with their forked yum repositories) are
lagging behind on a fix.

------
frabcus
This might be a good time to sign the promise not to use C/C++ on new
projects...
[http://www.flourish.org/promise/](http://www.flourish.org/promise/)

~~~
cozzyd
yeah by using python, you will never run into problems like this
[https://github.com/python/cpython/search?utf8=✓&q=gethostbyn...](https://github.com/python/cpython/search?utf8=✓&q=gethostbyname)

------
Erwin
According to this update: [http://www.openwall.com/lists/oss-
security/2015/01/27/18](http://www.openwall.com/lists/oss-
security/2015/01/27/18)

The Qualys guys were unable to find any issues with sshd and tcp_wrappers. I
imagine I'm not the only one that has /etc/hosts.deny setup to reject all but
some IPs, but according to Qualys tests this issue cannot be triggered via
someone with exploitable RDNS. As far as they know -- of course you should
upgrade when you can.

------
awkgeek
Here is how you can handle with it without rebooting the whole server:

for s in $(lsof | grep libc | awk '{print $1}' | sort | uniq); do if [[ -f
"/etc/init.d/$s" && "$(ps aufx | grep -v grep | grep $s)" ]]; then echo $s;
service $s restart; fi; done

From: [http://blog.wallarm.com/post/109402223343/ghost-a-brief-
reca...](http://blog.wallarm.com/post/109402223343/ghost-a-brief-recap-of-
what-you-need-to-know)

------
mlrtime
RedHat has patches out for RHEL5 only so far

[https://rhn.redhat.com/errata/RHSA-2015-0090.html](https://rhn.redhat.com/errata/RHSA-2015-0090.html)

~~~
tonyhb
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](http://www.openwall.com/lists/oss-
security/2015/01/27/9)

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

~~~
mlrtime
Correct, if you download the src rpm for the latest version of glibc for RHEL
6.5 and compare it with the fix, you will see it is not patched.

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

~~~
MichaelGG
I find it pretty funny how no matter how many times we're shown that unsafe
languages blow up on all sorts of code by all sorts of programmers, anyone
would still try to defend the language.

FFS in this case they even found the bug and fixed it, but didn't notice how
it could be a vulnerability. So even with eyes directly on issues, we (human
programmers excluding djb) can't seem to get it right.

~~~
AnthonyMouse
> I find it pretty funny how no matter how many times we're shown that unsafe
> languages blow up on all sorts of code by all sorts of programmers, anyone
> would still try to defend the language.

Heartbleed, Shellshock, Ghost. OpenSSL implemented their own memory allocator,
so you would get the same result in another language. Shellshock was a parsing
failure, memory safety had nothing to do with it, still arbitrary code
execution. Ghost is very hard to exploit, which is why people didn't notice
how it could be. It's like trying to exploit an off by one error.

Bugs in production code are not "safe" regardless of what language you use.
What we need are better ways to find bugs before the code is put into
production.

~~~
MichaelGG
Shellshock is somewhat atypical for systems vulns no? Looking at all the CVEs
for Microsoft for a couple of years, essentially all critical security
exploits are due to their use of C/C++.

Heartbleed would _not_ happen just because of a custom allocator. Eg Rust
allows you to do so, but would have prevented that code from compiling.

Basically, using C/C++ means that in addition to all the normal security logic
errors like command injection, you've got to worry that an errant copy or
overflow hands total execution control to an attacker. It's bizarre to not
realise this is a huge language failing and that _most_ of the systems level
exploits are purely due to poor languages. Even despite all the crazy codegen
and memory janking b modern compilers and OSes do, even with some hardware
support, it's still happening.

~~~
AnthonyMouse
> Shellshock is somewhat atypical for systems vulns no? Looking at all the
> CVEs for Microsoft for a couple of years, essentially all critical security
> exploits are due to their use of C/C++.

You're kind of answering your own question. Most OS bugs are in C because most
OS code is in C.

> Heartbleed would _not_ happen just because of a custom allocator. Eg Rust
> allows you to do so, but would have prevented that code from compiling.

If you get a large buffer and then "allocate" it by returning pointers to
pieces of it (or offsets if you don't have pointers), now the compiler/runtime
only knows where the end of the buffer is, not where the end of the allocation
is supposed to be. You can write dumb code in any language.

> Basically, using C/C++ means that in addition to all the normal security
> logic errors like command injection, you've got to worry that an errant copy
> or overflow hands total execution control to an attacker. It's bizarre to
> not realise this is a huge language failing and that _most_ of the systems
> level exploits are purely due to poor languages.

The problem with this reasoning is that it's solving the problem in the wrong
place. Yes, if you screw up very badly then it's better for the language to
blow up the program than let the attacker control it. But you still have to
solve the _other_ problem, which is that the attacker can blow up the program
or possibly do other things even with "safe" languages because the program is
parsing unvalidated input etc. And solving _that_ problem, which needs to
happen regardless, causes the first problem to go away.

~~~
MichaelGG
You're not reading it correctly. Microsoft's critical vulns are nearly all of
the class of errors that, say, Rust, solves. Memory safety issues. If Windows
was written in, e.g. Rust, all those security issues simply would not have
happened. I'm not sure how I can make this more clear.

While you _can_ write dumb code in any language, programmers somehow end up
not writing remote code execution from simple copies in other languages. Yet
in C, this keeps happening.

~~~
AnthonyMouse
> You're not reading it correctly. Microsoft's critical vulns are nearly all
> of the class of errors that, say, Rust, solves. Memory safety issues. If
> Windows was written in, e.g. Rust, all those security issues simply would
> not have happened. I'm not sure how I can make this more clear.

And what I'm saying is that you're solving the problem in the wrong place.
I'll take a static analysis tool that will find a buffer overrun at compile
time over a runtime that blows up the program in production, every time.

> While you _can_ write dumb code in any language, programmers somehow end up
> not writing remote code execution from simple copies in other languages. Yet
> in C, this keeps happening.

Shellshock, eval, SQL injection, people will write dumb code that results in
remote code execution using whatever you like.

~~~
kibwen

      > I'll take a static analysis tool that will find a buffer 
      > overrun at compile time over a runtime that blows up the 
      > program in production, every time.
    

Then you'll love Rust, where the compiler is essentially one ultra-
comprehensive static analyzer. :)

------
discordianfish
In case anyone has tons of Docker images and looks for a easy way to list
those which include a vulnerable glibc version, here is a handy one-liner:
[https://5pi.de/2015/01/27/find-ghosts-in-your-docker-
images/](https://5pi.de/2015/01/27/find-ghosts-in-your-docker-images/)

~~~
mootothemax
FYI I get a certificate error - ERR_CERT_AUTHORITY_INVALID - when trying to
access your site over the provided https link. OS X 10.10, Chrome and Safari.

~~~
vacri
I see a chain error - looks like the intermediate certificate is missing.

------
kungfooman
The 64-bit version update failed to update the libc6.so.6 link, so my system
was still vulnerable after update.

Link fix here: [http://killtube.org/showthread.php?2118-GHOST-
gethostbyname%...](http://killtube.org/showthread.php?2118-GHOST-
gethostbyname%28%29-Remote-Exploit&p=11295#post11295)

------
jonesnc
I'm having trouble updating my Ubuntu Server 12.04.5 LTS server to patch this
vulnerability.

[http://askubuntu.com/questions/578565/ubuntu-12-04-5-lts-
won...](http://askubuntu.com/questions/578565/ubuntu-12-04-5-lts-wont-update-
libc6-to-2-15-0ubuntu10-10)

------
jedisct1
Debian security advisory:
[http://www.securityfocus.com/archive/1/534554/30/0/threaded](http://www.securityfocus.com/archive/1/534554/30/0/threaded)

------
Animats
This is embarrassing. We now know that the line "with many eyes, all bugs are
shallow" is just wrong. What we do know now is that the open source process
does not converge to a no-bugs state.

It's time to start phasing out C/C++. Languages which don't know how big their
arrays are have to go. If it can run efficiently in a garbage-collected
environment, it should be in Go or some scripting language. If it can't use
GC, Rust is almost there. (As I say occasionally, I really hope the Rust guys
don't screw up.) C and C++ should not be used for new work.

 _It has been 1 days since the last buffer overflow vulnerability report._

~~~
tragomaskhalos
I wish people would stop tarring C++ with the same brush - this vulnerability
is caused by exactly the sort of manual dicking around with memory and buffer
sizes that are trivial to avoid and completely unidiomatic in C++ but de
rigeur in C. Is it possible to create these sorts of bugs in C++? Of course it
is, but that's a far cry from an environment that actively leads you down a
dangerous path because it lacks the necessary higher level abstractions.

~~~
pcwalton
C++ lacks the necessary higher-level abstractions to write memory-safe code.
It is vulnerable to iterator invalidation, use-after-free, dangling
references, and so forth. RAII does not provide the necessary guarantees.

~~~
tomjen3
Please justify your last statement - RAII is often used with Smart Pointers
(now in the standard library).

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

~~~
danielweber
The Qualys link (elsewhere on this page) contains sample code to test if you
are vulnerable.

Also, you can check your glibc version with this tiny code:

    
    
        #include <stdio.h>
        #include <gnu/libc-version.h>
        int main (void) { puts (gnu_get_libc_version ()); return 0; }
    

(taken from a forum that I've since closed the page on, sorry for lack of
attribution)

<= 2.17 is unsafe, >= 2.18 is safe.

ldd --version might also do the trick.

~~~
arielby
You can check your libc version by running libc - e.g. `/lib/x86_64-linux-
gnu/libc.so.6`

------
rdtsc
Does it need a marketing moniker?

~~~
cozzyd
gethosedbyname

------
skeer5
Do you know the sensitivity pattern of the vulnerability? (IDS/IPS)

------
voidz
Is Gentoo affected?

~~~
dewey
No, the announcement [1] says the affected versions are:

> In particular, we discovered that it was fixed on May 21, 2013 (between the
> releases of glibc-2.17 and glibc-2.18)

Gentoo is listing glibc version 2.19-r1 as the latest stable version [2] and
is using that per default.

[1] [http://www.openwall.com/lists/oss-
security/2015/01/27/9](http://www.openwall.com/lists/oss-
security/2015/01/27/9)

[2] [http://packages.gentoo.org/package/sys-
libs/glibc](http://packages.gentoo.org/package/sys-libs/glibc)

------
driverdan
If this was patched in 2013 why is it an issue now?

~~~
tedunangst
Because it was "silently" fixed so nobody applied the patch to existing,
shipping systems.

~~~
tikums
Sweeping-under-rug is a common approach. It seems that in this instance, they
have followed Linus Torvalds mantra, who once said: "I don't have any reason
what-so-ever to think it's a good idea to track security bugs and announce
them as something special. I don't think some spectacular security hole should
be glorified or cared about as being any more _special_ than a random
spectacular crash due to bad locking."

------
sh943
excuse the ignorance but could this effect OSX Macs that have GCC installed or
is this strictly limited to what it can effect?

------
antocv
Is this serious? Does this mean if I have an app, Java, PHP or whatever, which
eventually calls glibc's gethostbyname gethostbyaddr, my machine is owned?
That somebody could just craft a special hostname or ip address to lookup? So
all those websites where you enter hostname o IP address to lookup something
like whois info or ping other machines, could be owned?

~~~
ryan-c
If it affects gethostbyaddr that'd be really bad - there are a lot of
applications that automatically look up reverse DNS on a connection.

Mail servers in particular generally make it pretty easy to trigger both
forward and reverse lookups.

The test case seems to have it looking up an ip address as if it were a name,
but it's using the reentrant version of the function - maybe only those are
affected?

~~~
zwp
> If it affects gethostbyaddr

The release at
[http://www.frsag.org/pipermail/frsag/2015-January/005722.htm...](http://www.frsag.org/pipermail/frsag/2015-January/005722.html)
says that it affects both gethostbyname() and gethostbyaddr().

------
tlb
URL changed from
[https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=h...](https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.frsag.org%2Fpipermail%2Ffrsag%2F2015-January%2F005722.html)

------
nodata
Ouch. Ouch. Ouch.

