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

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

by martius • 11 years ago

531 235 11 years ago

martius3• 11 years ago

From 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• 11 years ago

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.

tptacek3• 11 years ago

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?

nodata• 11 years ago

Ouch. Ouch. Ouch.

csmeu3• 11 years ago

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

Edit: Its back again. Booooo.

Karunamon4• 11 years ago

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• 11 years ago

I think the parent comment was sarcastic.

peterwwillis5• 11 years ago

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.

nraynaud• 11 years ago

plus the original email was sent from a PR agency.

rudolf0• 11 years ago

I think it's okay to assign a media name to vulnerabilities, but only if the vulnerability is truly severe enough (easy to exploit and serious magnitude) to warrant it. Otherwise it's just an attempt at marketing and PR.

In this case, it looks the name is probably not warranted.

Karunamon4• 11 years ago

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• 11 years ago

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

vezzy-fnord• 11 years ago

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

tonfa• 11 years ago

The example given in the article is an MTA, but I'm there there's others.

deanclatworthy• 11 years ago

I'm curious on this one too. How exactly can this be exploited remotely? SSH trickery? If a PHP script is doing geolookups or resolving of user's IP's to hosts?

How do I make my hosts secure?

api• 11 years ago

I'm guessing vulnerable cases will be where string-encoded IP addresses are accepted from the network and passed directly to these functions, such as by web apps or things that take string-serialized encodings. This would allow an attacker to pass any string in as an IP address.

mrb• 11 years ago

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/lists/oss-security/2015/01/27/9 - thanks amlweems! (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 - thanks 4ad!

4ad2• 11 years ago

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.

0x04• 11 years ago

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?

tveita• 11 years ago

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?

0x04• 11 years ago

yes

pjmlp4• 11 years ago

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.

caf2• 11 years ago

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.

This overstates things a bit - hostnames that can be returned by the reverse DNS resolver can't trigger the vulnerability (maximum label length of 63). It needs to be a hostname supplied by a non-DNS method (eg. the POC uses the HELO SMTP command).

antocv• 11 years ago

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-c3• 11 years ago

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• 11 years ago

If it affects gethostbyaddr

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

WestCoastJustin• 11 years ago

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

contingencies• 11 years ago

For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.

beagle35• 11 years ago

This is a good idea in general. However, every version of ssh that I could test (going back to Ubuntu 8.04) uses getaddrinfo() rather than gethostbyname() and is therefore safe.

michaelx386• 11 years ago

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.

JshWright2• 11 years ago

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.

0x04• 11 years ago

For debian, you can use "checkrestart -v" from the "debian-goodies" package.

peterwwillis5• 11 years ago

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

correxion2• 11 years ago

sudo netstat -lnp | awk -F/ '/LISTEN /{print $2}'

jerematasno5• 11 years ago

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.

stplsd• 11 years ago

Just remember that by default lsof prints only first 9 characters of process name, so processes with long names will be cut. You can change how much initial characters lsof prints with +c command, but often kernel does not supply full names for lsof, example limit in my box is 15 characters

lsof +c 64

lsof: +c 64 > what system provides (15)

lsof +c 15 is maximum

voltagex_2• 11 years ago

That limit is set somewhere in the kernel but it's not clear if lsof is just setting that as a maximum internally or probing somewhere - I used strace -etrace='!close' lsof +c 64 but I couldn't see anything related to the limit.

correxion2• 11 years ago

lsof | awk '/libc/{print $1 | "sort -u" }' you're welcome

jedisct1• 11 years ago

Debian security advisory: http://www.securityfocus.com/archive/1/534554/30/0/threaded

DangerousPie2• 11 years ago

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

mlrtime3• 11 years ago

RedHat has patches out for RHEL5 only so far

https://rhn.redhat.com/errata/RHSA-2015-0090.html

tonyhb3• 11 years ago

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

cylo• 11 years ago

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

jerematasno5• 11 years ago

I spent most of the day tracking down the status of various Linux distros. Blog post forthcoming, but the TL;DR is that you need to patch RedHat.

mlrtime3• 11 years ago

6/7 Release

https://rhn.redhat.com/errata/RHSA-2015-0092.html

ryan-c3• 11 years ago

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/005726.htm...

martius3• 11 years ago

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

rkwasny• 11 years ago

This looks like an "accident" by PR Agency:

http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... 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 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• 11 years ago

Yep, she published too soon. http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...

amlweems• 11 years ago

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

tonyhb3• 11 years ago

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.

ChuckMcM• 11 years ago

They give it away (which I find moderately not nice of them) by saying they used Exim (the mail server) in their POC.

kyboren• 11 years ago

    - 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• 11 years ago

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

0x04• 11 years ago

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

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• 11 years ago

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.

danielweber2• 11 years ago

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/

yk2• 11 years ago

Most importantly, it contains a test program at the beginning of section 4.

asveikau• 11 years ago

    101       *buffer_size = size_needed;
    102       new_buf = (char *) realloc (*buffer, *buffer_size);
    103
    104       if (new_buf == NULL)
    105         {
    ...
    114           goto done;
    115         }

It's a shame they put that "..." there, because this looked like another potential vulnerability to me, or at least something I would take very critically reading this code. (realloc fails, the caller's variable at buffer_size still gets assigned a larger value, next call thinks it has a larger buffer than it does). Line 110 assigns *buffer_size back to 0 so there is no such problem.

yeukhon• 11 years ago

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• 11 years ago

According to Canonical it is: http://www.ubuntu.com/usn/usn-2485-1/

jerematasno5• 11 years ago

Blog post coming soon, but 12.04 is vulnerable, but has a patch available.

smcquaid• 11 years ago

Here is a diff removing the vulnerability: https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/dig...

userbinator2• 11 years ago

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?

lmm• 11 years ago

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.

tedunangst6• 11 years ago

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.

rdtsc2• 11 years ago

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.

peterwwillis5• 11 years ago

So remove the ability to use pointers to directly access memory. Then you're only left with all of the other security vulnerabilities found in every such language.

cm21872• 11 years ago

Without trolling, it is true that string manipulation has been a fertile source of major bugs. I don't really see the benefit of having to manipulate arrays of characters manually instead of a string datatype. An unmanaged language doesn't really gain anything from this, apart from this sort of embarrassment.

pjmlp4• 11 years ago

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.

IshKebab• 11 years ago

Yeah, "I would have written it right."

sp3322• 11 years ago

There are only 2 really difficult problems in computer science: cache invalidation, naming things, and off-by-one errors.

mikeash2• 11 years ago

I have no idea if it would apply here, but many instances where a field is forgotten in a size calculation happen because the field wasn't originally there, and not all of the relevant code got updated when it was added. Beware any code that requires knowledge of all elements of some set, and still compiles if a new element is added and the code isn't updated for it.

mserdarsanli• 11 years ago

Counting is the hardest thing in programming.

MichaelGG7• 11 years ago

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.

indymike• 11 years ago

Reason why people defend unsafe languages:

If you make it idiot-proof, someone will make a better idiot.

AnthonyMouse4• 11 years ago

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.

driverdan• 11 years ago

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

tedunangst6• 11 years ago

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

mikeash2• 11 years ago

From what I can gather, it wasn't originally thought to be a security vulnerability so it was thought to be acceptable to leave it be on older systems. Now somebody has figured out how to exploit it.

tikums• 11 years ago

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

verelo2• 11 years ago

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?

danielweber2• 11 years ago

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• 11 years ago

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

verelo2• 11 years ago

Thanks, super helpful!

caf2• 11 years ago

Checking the libc version doesn't really tell you if you've fixed the problem, since most vulnerable distributions will be fixing it by patching their older version of libc, so the version number will remain the same.

jap• 11 years ago

Looks 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."

martius3• 11 years ago

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

zrm3• 11 years ago

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.

derf_• 11 years ago

Well, Ulrich Drepper has been trying to get people to stop using it since 2007: https://udrepper.livejournal.com/16116.html

And not just because of IPv6.

AnthonyMouse4• 11 years ago

That seems like a weak argument. It's still going to do the wrong thing when the local machine has a 10.x.x.x address and the local server has a 172.16.x.x address. The right solution is for the local admin to have the local DNS server return only the local address for local clients.

getaddrinfo() is also a much more complicated function than gethostbyname(). If you need the extra features, fine. If you're writing new code, fine. But going back and trying to update existing code is just going to introduce new bugs.

voidz• 11 years ago

Is Gentoo affected?

dewey• 11 years ago

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

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

ars• 11 years ago

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/

DangerousPie2• 11 years ago

Here is the test program, from http://www.openwall.com/lists/oss-security/2015/01/27/9

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• 11 years ago

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

fletchowns• 11 years ago

Might as well throw a --no-check-certificate in there

toddsiegel• 11 years ago

I agree, it is funny, but we run code we can't even see all day long. This is only 38 LOC. Anyone who is going to run it, however, should make sure they understand it.

tedunangst6• 11 years ago

As opposed to code in some other language?

fragmede3• 11 years ago

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?

cellover• 11 years ago

You know you can also read the source code right? Even if you are not proficient with c you can understand what it's doing.

voltagex_2• 11 years ago

Anyone know how reliable that test is? I've got a system reporting not vulnerable but I'm not sure what glibc it has.

pb2au• 11 years ago

glibc 2.18 and greater were already patched, but it wasn't recognized as an RCE vulnerability at the time. See the first bullet under the "Mitigating factors" section in the link.

You can check your libc version with:

  ldd --version

elijahpaul• 11 years ago

I've got a system reporting glibc 2.11, but the test reports 'not vulnerable'.

growthape2• 11 years ago

We have already started to patch servers at Cloudways. Our CTO Pere Hospital explains how: http://www.cloudways.com/blog/ghost-vulnerability-patching/

dampier• 11 years ago

All due respect, I think "explains that" would be more accurate than "explains how" here

yk2• 11 years ago

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

ubiquitousthey• 11 years ago

14.04 and 13.10 are not vulnerable

tlb• 11 years ago

URL changed from https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=h...

tonyg2• 11 years ago

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?

eyeareque• 11 years ago

If they aren't already a part of a botnet.

lunixbochs• 11 years ago

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.

tonyg2• 11 years ago

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.

pjmlp4• 11 years ago

But it is still C code, so...

gtrubetskoy2• 11 years ago

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

McGlockenshire• 11 years ago

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

darkr• 11 years ago

Apparently packages are built but currently awaiting signing + release. Hopefully within an hour or two they should hit the mirrors.

Thaxll• 11 years ago

It should be there once it's done: http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/

systemz• 11 years ago

Packages are ready, but if your mirror don't have them, use manual way: http://systemz.pl/post/fast-ghost-fix-for-cve-2015-0235/ It's for CentOS 6

nilic• 11 years ago

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.

rdtsc2• 11 years ago

Does it need a marketing moniker?

cozzyd2• 11 years ago

gethosedbyname

discordianfish• 11 years ago

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/

mootothemax• 11 years ago

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• 11 years ago

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

Erwin• 11 years ago

According to this update: 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.

mef• 11 years ago

Relevant AWS thread https://forums.aws.amazon.com/thread.jspa?threadID=170359&ts...

spjwebster• 11 years ago

ALAS covering this vulnerability:

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.

atom_enger2• 11 years ago

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

sandstrom• 11 years ago

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_enger2• 11 years ago

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

frabcus• 11 years ago

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

cozzyd2• 11 years ago

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

Animats3• 11 years ago

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.

YuriNiyazov• 11 years ago

Do we really know that the open source process doesn't converge? No specification for the length of time toward convergence exists, and you could argue that this case is an example of inching ever closer to no-bugs state

fragmede3• 11 years ago

Turns out, open source code is written by humans, same as at Microsoft. I remember, back in the day, it was absolutely pathetic that Microsoft Outlook had a buffer overflow in the subject line that could be tripped simply by receiving an email. Well, oops.

mackal• 11 years ago

I hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.

lazaroclapp2• 11 years ago

Except, "just use another language! All problems of this huge category solved!" is true in this case. You can't have buffer overflows on a memory-safe language. Sure, this is only true assuming the VM and all the stuff it depends on is formally verified not to have buffer overflows either, which is unlikely to happen. But even so, you get the slightly weaker guarantee: "just use another language! All problems of this huge category won't be your fault!" ;)

Now, it is not always practical to use safe languages for everything (specially low level libraries such as say, libc...), and that 'huge category' of problems is not even remotely close to being all the security problems. But using tools that prioritize not shooting yourself in the foot by default is not bad consideration to make, all other things being similar.

rkangel• 11 years ago

This bug was actually fixed 2 years ago, so I'm not sure this is the best example to make your point.

Natsu3• 11 years ago

We now know that the line "with many eyes, all bugs are shallow" is just wrong.

How many eyes have actually looked at this code?

ndesaulniers• 11 years ago

What we do know now is that the open source process does not converge to a no-bugs state.

And with closed source, who knows?!

C and C++ should not be used for new work.

It's funny how articles on C/C++ seem to shoot to the front page here...

tragomaskhalos• 11 years ago

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• 11 years ago

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.

bch• 11 years ago

What we do know now is that the open source process does not converge to a no-bugs state.

Nobody to be taken serious has ever thought or said this -- it says about as much as "You know, I'm not perfect...".

Go itself (as of 1.3) is still itself coded in C, and I have no idea if/how C and Rust are related... C isn't going away, and tooling (Coverity, valgrind, nice compilers like clang) are our friends, as well as work like OpenBSDs string-handling ammendments, malloc() guards, etc.

I really am sympathetic to the complaints against C, but "Burn it!! It's a witch!" doesn't grab me.

kyllo2• 11 years ago

Nobody to be taken serious has ever thought or said this

Linus Torvalds is nobody to be taken seriously?

stormbrew3• 11 years ago

Aside from the fact that this bug was seen by eyes and fixed years ago (long enough ago that there's been a new LTS release with it fixed of several if not most distributions), even if they didn't know it was a security fix, this:

We now know that the line "with many eyes, all bugs are shallow" is just wrong.

Remains approximately similar to saying, while watching the tide go out, that sea levels aren't rising. Anyone who ever thought it meant they were fixed instantaneously, and who uses the fact they get fixed and found as counter-proof of the sentiment, was wrong. It doesn't make the idea fundamentally wrong.

est• 11 years ago

It's time to start phasing out C/C++

Well, unless you get rid of C/C++ interfaces in all syscalls or Win32 APIs, hell Microsoft tried that with managed code, and utterly failed to deliver.

Animats3• 11 years ago

Then they did .NET and converted everybody to C#.

cm21872• 11 years ago

Garbage collection has a performance hit which may not be desirable. You don't really want your network stack to stall from time to time. And OS wouldn't be usable in any mission critical environment.

Array boundaries checking also has a performance hit but I am coming to think it is a necessary evil.

Dealing with strings as char arrays is just absurd. There isn't a significant performance hit to use some string datatype that reduce the opportunity for bugs.

Animats3• 11 years ago

Array bounds checking can often be optimized out. For constructs such as "for x in foo {}" this is trivial. The more general cases require a compiler which can hoist subscript checks out of loops when possible. The compiler has to be allowed to generate checks which fail early; that is, if the loop is going to subscript out of range at iteration 100 and there's no way to exit the loop early, then one check at loop entry is sufficient. This is hard to express to some optimizers.

sh943• 11 years ago

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

jonesnc• 11 years ago

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

rdhyee2• 11 years ago

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

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), 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... to make sense of the charts at http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20..., 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• 11 years ago

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

rdhyee2• 11 years ago

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

kungfooman• 11 years ago

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%...

beagle35• 11 years ago

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 , getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes' ssh setup vulnerable or not?

cft2• 11 years ago

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.

beagle35• 11 years ago

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.

jerematasno5• 11 years ago

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

mirimir• 11 years ago

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

SaveTheRbtz• 11 years ago

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

skeer5• 11 years ago

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

awkgeek• 11 years ago

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

brunes• 11 years ago

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?

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

Related Stories