17 ms·

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

531 points by martius 12y ago

martius 12y ago
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 12y ago
  Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_dots.c;hb=HEAD 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.
  - tptacek 12y 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?
    - tedunangst 12y ago
      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 12y ago
        http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_... 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 12y ago
        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.
        cbsmith 12y ago
        In this case the bug isn't caused by dynamic allocation though, is it? The problem is the validation logic for detecting if the caller didn't allocate a big enough buffer when making the call. In fact, it looks like if you get to the dynamic allocation section, it will fix the problem. One could argue that the whole problem stems from having a bug in a complex computation of buffer size to handle lots of different bits of data, rather than dynamically allocating the individual bits as needed.
    - deleted 12y ago
      [deleted]
      - tptacek 12y ago
        Right, but they only need to do that computation because they're dynamically allocating storage. But the maximum size of a hostname is so small that hitting the allocator is costing them more than static allocation would.
    - zrm 12y ago
      gethostbyname() and friends fill in struct hostent: struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ } The pointers in the structure point into the buffer. There could be any number of host aliases or IP addresses.
      - tptacek 12y ago
        That's true and a good point, but not (it seems) applicable to this particular function, which validates whether or not the name is one of two fixed-sized formats, right? (edit) You may be totally right here, by the way.
        zrm 12y ago
        It looks like what's going on is that gethostbyname() calls __nss_hostname_digits_dots() which checks to see if the string you passed it was an IPv4 or IPv6 address rather than a name, and in that case it functions like inet_aton/inet_pton and converts the IP address string to a binary IP address as though the "name" 1.2.3.4 resolved to IP address 1.2.3.4. In that specific case there are no aliases and exactly one IP address, but the buffer could still be too small (e.g. if caller-supplied with gethostbyname_r()).
nodata 12y ago
Ouch. Ouch. Ouch.
csmeu 12y 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.
- Karunamon 12y 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 12y ago
    I think the parent comment was sarcastic.
    - fragmede 12y ago
      I don't think so. Between Heartbleed and Shellshock, and now this, a PR firm marketing vulnerabilities like this seems... crass.
    - csmeu 12y ago
      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 12y ago
        "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!
Karunamon 12y 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 12y ago
  It seems it was made public by accident, so it is not totally surprising that information is sparse :(
  - vezzy-fnord 12y ago
    Given that I recently received a Debian Security Advisory which specifically addressed this CVE, I don't think it was accidental at all.
    - tedunangst 12y ago
      I think the timing was accidental due to leaking. The coordinated release became uncoordinated.
    - sp332 12y ago
      The embargo was cancelled half an hour after the leak.
- tonfa 12y ago
  The example given in the article is an MTA, but I'm there there's others.
- deanclatworthy 12y 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 12y 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 12y ago
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=d5dd6189d506068ed11c8bfa1e1e9bffde04decd https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hp=fef94eab0bd308d5059a2588c753bf9a4926845d 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 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 12y 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.
antocv 12y 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-c 12y 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?
  - deleted 12y ago
    [deleted]
  - zwp 12y ago
    > If it affects gethostbyaddr The release at http://www.frsag.org/pipermail/frsag/2015-January/005722.html http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... says that it affects both gethostbyname() and gethostbyaddr().
WestCoastJustin 12y 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-gethostbyname-calls/ http://ma.ttias.be/critical-glibc-update-cve-2015-0235-getho...
- contingencies 12y ago
  For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.
  - beagle3 12y 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.
    - beagle3 12y ago
      ... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers. "UseDNS no" in your sshd_config is a good idea in general.
- michaelx386 12y 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.
jedisct1 12y ago
Debian security advisory: http://www.securityfocus.com/archive/1/534554/30/0/threaded http://www.securityfocus.com/archive/1/534554/30/0/threaded
DangerousPie 12y 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...
mlrtime 12y ago
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 12y 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 http://www.openwall.com/lists/oss-security/2015/01/27/9
  - cylo 12y 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."
    - tonyhb 12y ago
      Oh yeah, that was obvious, not sure how I missed it. Thanks.
    - mlrtime 12y ago
      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.
  - jerematasno 12y 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.
- mlrtime 12y ago
  6/7 Release https://rhn.redhat.com/errata/RHSA-2015-0092.html https://rhn.redhat.com/errata/RHSA-2015-0092.html
deleted 12y ago
[deleted]
ryan-c 12y ago
Reading the thread, it does appear that someone broke embargo on this. http://www.frsag.org/pipermail/frsag/2015-January/005727.html http://www.frsag.org/pipermail/frsag/2015-January/005727.htm... http://www.frsag.org/pipermail/frsag/2015-January/005726.html http://www.frsag.org/pipermail/frsag/2015-January/005726.htm...
- martius 12y 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 12y ago
This looks like an "accident" by PR Agency: http://www.frsag.org/pipermail/frsag/2015-January/005722.html 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 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 12y ago
  Yep, she published too soon. http://www.frsag.org/pipermail/frsag/2015-January/005727.html http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...
amlweems 12y ago
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
- tonyhb 12y 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 12y ago
    They give it away (which I find moderately not nice of them) by saying they used Exim (the mail server) in their POC.
    - ryan-c 12y ago
      The default exim config seems to not be vulnerable. I checked the configs on two of my systems, one default, and one heavily customized, neither had the helo verification turned on.
- kyboren 12y 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.
0x0 12y ago
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 12y 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.
  - danielweber 12y 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/ http://ftp.gnu.org/gnu/glibc/
- yk 12y ago
  Most importantly, it contains a test program at the beginning of section 4.
- deleted 12y ago
  [deleted]
- asveikau 12y 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 12y 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 12y ago
  According to Canonical it is: http://www.ubuntu.com/usn/usn-2485-1/ http://www.ubuntu.com/usn/usn-2485-1/
- jerematasno 12y ago
  Blog post coming soon, but 12.04 is vulnerable, but has a patch available.
smcquaid 12y ago
Here is a diff removing the vulnerability: https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/digits_dots.c;h=e007ef47a41b69437655c26565689be393705a82;hp=2b862956e9a8c39bbccbea982add1d7ab2d16ab2;hb=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hpb=fef94eab0bd308d5059a2588c753bf9a4926845d https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/dig...
userbinator 12y 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?
- rdtsc 12y 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.
  - peterwwillis 12y 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.
    - pjmlp 12y ago
      It would still be an improvement.
    - AgentME 12y ago
      Uh, how often do code execution vulnerabilities show up in non-C programs compared to how often they show up in C programs?
      - Ded7xSEoPKYNsDd 12y ago
        All the time: SQLi, XSS, arbitrary file upload, ...
        tedunangst 12y ago
        The fun part is that when you find a language/framework that (e.g.) deserializes data by running eval(), it's so much easier to write portable exploits. 32 bit, 64 bit, x86, arm, mips, aslr? None of that matters. Literally eval(system("/bin/sh")) and done.
driverdan 12y ago
If this was patched in 2013 why is it an issue now?
- tedunangst 12y ago
  Because it was "silently" fixed so nobody applied the patch to existing, shipping systems.
  - mikeash 12y 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 12y 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."
verelo 12y 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?
- danielweber 12y 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 12y ago
    You can check your libc version by running libc - e.g. `/lib/x86_64-linux-gnu/libc.so.6`
  - verelo 12y ago
    Thanks, super helpful!
  - caf 12y 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.
  - deleted 12y ago
    [deleted]
jap 12y ago
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 12y 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-Core-generic/normativerefs.html#STD.SUSV3 http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB...
  - zrm 12y 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_ 12y ago
  Well, Ulrich Drepper has been trying to get people to stop using it since 2007: https://udrepper.livejournal.com/16116.html https://udrepper.livejournal.com/16116.html And not just because of IPv6.
  - AnthonyMouse 12y 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 12y ago
Is Gentoo affected?
- dewey 12y 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 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
ars 12y 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/ http://security.debian.org/pool/updates/main/e/eglibc/
DangerousPie 12y ago
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 12y ago
  I always laugh when people give you a URL to C code to test for remote code execution...
  - fletchowns 12y ago
    Might as well throw a --no-check-certificate in there
  - toddsiegel 12y 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.
  - tedunangst 12y ago
    As opposed to code in some other language?
  - fragmede 12y 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?
    - Natsu 12y ago
      You're piping random executables from the internet without even looking at them to see what they do if you run that command.
yk 12y 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 http://www.openwall.com/lists/oss-security/2015/01/27/9
- ubiquitousthey 12y ago
  14.04 and 13.10 are not vulnerable
tlb 12y ago
URL changed from https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.frsag.org%2Fpipermail%2Ffrsag%2F2015-January%2F005722.html https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=h...
tonyg 12y 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 12y ago
  If they aren't already a part of a botnet.
- lunixbochs 12y 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.
  - tonyg 12y 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.
  - pjmlp 12y ago
    But it is still C code, so...
- deleted 12y ago
  [deleted]
gtrubetskoy 12y ago
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 12y ago
  Does anyone have any insight into when we'll see CentOS packages start hitting the mirrors?
  - deleted 12y ago
    [deleted]
    - kokey 12y ago
      That release seems to be dated 7 January 2015.
    - hackersword 12y ago
      This is for https://rhn.redhat.com/errata/RHSA-2015-0016.html https://rhn.redhat.com/errata/RHSA-2015-0016.html This was related to iconv() and UTF8. This is NOT the fix for this CVE.
  - darkr 12y ago
    Apparently packages are built but currently awaiting signing + release. Hopefully within an hour or two they should hit the mirrors.
  - deleted 12y ago
    [deleted]
  - Thaxll 12y ago
    It should be there once it's done: http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/ http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/
  - systemz 12y 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/ http://systemz.pl/post/fast-ghost-fix-for-cve-2015-0235/ It's for CentOS 6
rdtsc 12y ago
Does it need a marketing moniker?
- cozzyd 12y ago
  gethosedbyname
discordianfish 12y 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/ https://5pi.de/2015/01/27/find-ghosts-in-your-docker-images/
- mootothemax 12y 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 12y ago
    I see a chain error - looks like the intermediate certificate is missing.
Erwin 12y ago
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.
mef 12y ago
Relevant AWS thread https://forums.aws.amazon.com/thread.jspa?threadID=170359&tstart=0 https://forums.aws.amazon.com/thread.jspa?threadID=170359&ts...
- spjwebster 12y ago
  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.
atom_enger 12y 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-aka-ghost-2/ http://product.reverb.com/2015/01/28/patching-cve-2015-0235-...
- sandstrom 12y 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_enger 12y ago
    Thanks for the feedback. I've updated the post to omit that statement since it's not entirely helpful.
frabcus 12y ago
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 12y ago
  yeah by using python, you will never run into problems like this https://github.com/python/cpython/search?utf8=✓&q=gethostbyname https://github.com/python/cpython/search?utf8=✓&q=gethostbyn...
Animats 12y 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 12y 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
- fragmede 12y 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 12y ago
  I hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.
  - lazaroclapp 12y 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.
sh943 12y 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 12y 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-wont-update-libc6-to-2-15-0ubuntu10-10 http://askubuntu.com/questions/578565/ubuntu-12-04-5-lts-won...
rdhyee 12y 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-2015-0235.html 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 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-instead-of-glibc/372880#372880 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-2015-0235.html 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 12y 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 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.
  - 12y ago
kungfooman 12y 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%28%29-Remote-Exploit&p=11295#post11295 http://killtube.org/showthread.php?2118-GHOST-gethostbyname%...
kungfooman 12y 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%28%29-Remote-Exploit&p=11295#post11295 http://killtube.org/showthread.php?2118-GHOST-gethostbyname%...
beagle3 12y 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 https://news.ycombinator.com/item?id=8954458 , getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes' ssh setup vulnerable or not?
- cft 12y 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.
  - beagle3 12y 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.
    - cft 12y ago
      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.
jerematasno 12y 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-overview-ghost-cve-2015-0235.html#versions http://chargen.matasano.com/chargen/2015/1/27/vulnerability-...
mirimir 12y 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> http://seclists.org/oss-sec/2015/q1/283>.
- SaveTheRbtz 12y ago
  nginx on most supporting platforms (`NGX_HAVE_GETADDRINFO && NGX_HAVE_INET6`) uses `getaddrinfo(3)`.
skeer5 12y ago
Do you know the sensitivity pattern of the vulnerability? (IDS/IPS)
awkgeek 12y 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-recap-of-what-you-need-to-know http://blog.wallarm.com/post/109402223343/ghost-a-brief-reca...
brunes 12y 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?

531 points by martius 12y ago

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 12y ago
Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_dots.c;hb=HEAD 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.
- tptacek 12y 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?
  - tedunangst 12y ago
    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 12y ago
      http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_... 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 12y ago
        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.
      - cbsmith 12y ago
        In this case the bug isn't caused by dynamic allocation though, is it? The problem is the validation logic for detecting if the caller didn't allocate a big enough buffer when making the call. In fact, it looks like if you get to the dynamic allocation section, it will fix the problem. One could argue that the whole problem stems from having a bug in a complex computation of buffer size to handle lots of different bits of data, rather than dynamically allocating the individual bits as needed.
  - deleted 12y ago
    [deleted]
    - tptacek 12y ago
      Right, but they only need to do that computation because they're dynamically allocating storage. But the maximum size of a hostname is so small that hitting the allocator is costing them more than static allocation would.
  - zrm 12y ago
    gethostbyname() and friends fill in struct hostent: struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ } The pointers in the structure point into the buffer. There could be any number of host aliases or IP addresses.
    - tptacek 12y ago
      That's true and a good point, but not (it seems) applicable to this particular function, which validates whether or not the name is one of two fixed-sized formats, right? (edit) You may be totally right here, by the way.
      - zrm 12y ago
        It looks like what's going on is that gethostbyname() calls __nss_hostname_digits_dots() which checks to see if the string you passed it was an IPv4 or IPv6 address rather than a name, and in that case it functions like inet_aton/inet_pton and converts the IP address string to a binary IP address as though the "name" 1.2.3.4 resolved to IP address 1.2.3.4. In that specific case there are no aliases and exactly one IP address, but the buffer could still be too small (e.g. if caller-supplied with gethostbyname_r()).

nodata 12y ago

Ouch. Ouch. Ouch.

csmeu 12y 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.

Karunamon 12y 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 12y ago
  I think the parent comment was sarcastic.
  - fragmede 12y ago
    I don't think so. Between Heartbleed and Shellshock, and now this, a PR firm marketing vulnerabilities like this seems... crass.
  - csmeu 12y ago
    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 12y ago
      "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!

Karunamon 12y 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 12y ago
It seems it was made public by accident, so it is not totally surprising that information is sparse :(
- vezzy-fnord 12y ago
  Given that I recently received a Debian Security Advisory which specifically addressed this CVE, I don't think it was accidental at all.
  - tedunangst 12y ago
    I think the timing was accidental due to leaking. The coordinated release became uncoordinated.
  - sp332 12y ago
    The embargo was cancelled half an hour after the leak.
tonfa 12y ago
The example given in the article is an MTA, but I'm there there's others.
deanclatworthy 12y 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 12y 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 12y ago

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=d5dd6189d506068ed11c8bfa1e1e9bffde04decd https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hp=fef94eab0bd308d5059a2588c753bf9a4926845d 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 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 12y 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.

antocv 12y 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-c 12y 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?
- deleted 12y ago
  [deleted]
- zwp 12y ago
  > If it affects gethostbyaddr The release at http://www.frsag.org/pipermail/frsag/2015-January/005722.html http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... says that it affects both gethostbyname() and gethostbyaddr().

WestCoastJustin 12y 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-gethostbyname-calls/ http://ma.ttias.be/critical-glibc-update-cve-2015-0235-getho...

contingencies 12y ago
For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.
- beagle3 12y 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.
  - beagle3 12y ago
    ... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers. "UseDNS no" in your sshd_config is a good idea in general.
michaelx386 12y 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.

jedisct1 12y ago

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

DangerousPie 12y 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...

mlrtime 12y ago

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 12y 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 http://www.openwall.com/lists/oss-security/2015/01/27/9
- cylo 12y 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."
  - tonyhb 12y ago
    Oh yeah, that was obvious, not sure how I missed it. Thanks.
  - mlrtime 12y ago
    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.
- jerematasno 12y 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.
mlrtime 12y ago
6/7 Release https://rhn.redhat.com/errata/RHSA-2015-0092.html https://rhn.redhat.com/errata/RHSA-2015-0092.html

deleted 12y ago

[deleted]

ryan-c 12y ago

Reading the thread, it does appear that someone broke embargo on this. http://www.frsag.org/pipermail/frsag/2015-January/005727.html http://www.frsag.org/pipermail/frsag/2015-January/005727.htm... http://www.frsag.org/pipermail/frsag/2015-January/005726.html http://www.frsag.org/pipermail/frsag/2015-January/005726.htm...

martius 12y 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 12y ago

This looks like an "accident" by PR Agency: http://www.frsag.org/pipermail/frsag/2015-January/005722.html 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 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 12y ago
Yep, she published too soon. http://www.frsag.org/pipermail/frsag/2015-January/005727.html http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...

amlweems 12y ago

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

tonyhb 12y 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 12y ago
  They give it away (which I find moderately not nice of them) by saying they used Exim (the mail server) in their POC.
  - ryan-c 12y ago
    The default exim config seems to not be vulnerable. I checked the configs on two of my systems, one default, and one heavily customized, neither had the helo verification turned on.
kyboren 12y 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.

0x0 12y ago

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 12y 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.
- danielweber 12y 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/ http://ftp.gnu.org/gnu/glibc/
yk 12y ago
Most importantly, it contains a test program at the beginning of section 4.
deleted 12y ago
[deleted]
asveikau 12y 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 12y 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 12y ago
According to Canonical it is: http://www.ubuntu.com/usn/usn-2485-1/ http://www.ubuntu.com/usn/usn-2485-1/
jerematasno 12y ago
Blog post coming soon, but 12.04 is vulnerable, but has a patch available.

smcquaid 12y ago

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

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

rdtsc 12y 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.
- peterwwillis 12y 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.
  - pjmlp 12y ago
    It would still be an improvement.
  - AgentME 12y ago
    Uh, how often do code execution vulnerabilities show up in non-C programs compared to how often they show up in C programs?
    - Ded7xSEoPKYNsDd 12y ago
      All the time: SQLi, XSS, arbitrary file upload, ...
      - tedunangst 12y ago
        The fun part is that when you find a language/framework that (e.g.) deserializes data by running eval(), it's so much easier to write portable exploits. 32 bit, 64 bit, x86, arm, mips, aslr? None of that matters. Literally eval(system("/bin/sh")) and done.

driverdan 12y ago

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

tedunangst 12y ago
Because it was "silently" fixed so nobody applied the patch to existing, shipping systems.
- mikeash 12y 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 12y 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."

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

danielweber 12y 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 12y ago
  You can check your libc version by running libc - e.g. `/lib/x86_64-linux-gnu/libc.so.6`
- verelo 12y ago
  Thanks, super helpful!
- caf 12y 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.
- deleted 12y ago
  [deleted]

jap 12y ago

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 12y 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-Core-generic/normativerefs.html#STD.SUSV3 http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB...
- zrm 12y 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_ 12y ago
Well, Ulrich Drepper has been trying to get people to stop using it since 2007: https://udrepper.livejournal.com/16116.html https://udrepper.livejournal.com/16116.html And not just because of IPv6.
- AnthonyMouse 12y 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 12y ago

Is Gentoo affected?

dewey 12y 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 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

ars 12y 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/ http://security.debian.org/pool/updates/main/e/eglibc/

DangerousPie 12y ago

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 12y ago
I always laugh when people give you a URL to C code to test for remote code execution...
- fletchowns 12y ago
  Might as well throw a --no-check-certificate in there
- toddsiegel 12y 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.
- tedunangst 12y ago
  As opposed to code in some other language?
- fragmede 12y 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?
  - Natsu 12y ago
    You're piping random executables from the internet without even looking at them to see what they do if you run that command.

yk 12y 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 http://www.openwall.com/lists/oss-security/2015/01/27/9

ubiquitousthey 12y ago
14.04 and 13.10 are not vulnerable

tlb 12y ago

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

tonyg 12y 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 12y ago
If they aren't already a part of a botnet.
lunixbochs 12y 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.
- tonyg 12y 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.
- pjmlp 12y ago
  But it is still C code, so...
deleted 12y ago
[deleted]

gtrubetskoy 12y ago

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 12y ago
Does anyone have any insight into when we'll see CentOS packages start hitting the mirrors?
- deleted 12y ago
  [deleted]
  - kokey 12y ago
    That release seems to be dated 7 January 2015.
  - hackersword 12y ago
    This is for https://rhn.redhat.com/errata/RHSA-2015-0016.html https://rhn.redhat.com/errata/RHSA-2015-0016.html This was related to iconv() and UTF8. This is NOT the fix for this CVE.
- darkr 12y ago
  Apparently packages are built but currently awaiting signing + release. Hopefully within an hour or two they should hit the mirrors.
- deleted 12y ago
  [deleted]
- Thaxll 12y ago
  It should be there once it's done: http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/ http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/
- systemz 12y 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/ http://systemz.pl/post/fast-ghost-fix-for-cve-2015-0235/ It's for CentOS 6

rdtsc 12y ago

Does it need a marketing moniker?

cozzyd 12y ago
gethosedbyname

discordianfish 12y 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/ https://5pi.de/2015/01/27/find-ghosts-in-your-docker-images/

mootothemax 12y 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 12y ago
  I see a chain error - looks like the intermediate certificate is missing.

Erwin 12y ago

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.

mef 12y ago

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

spjwebster 12y ago
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.

atom_enger 12y 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-aka-ghost-2/ http://product.reverb.com/2015/01/28/patching-cve-2015-0235-...

sandstrom 12y 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_enger 12y ago
  Thanks for the feedback. I've updated the post to omit that statement since it's not entirely helpful.

frabcus 12y ago

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 12y ago
yeah by using python, you will never run into problems like this https://github.com/python/cpython/search?utf8=✓&q=gethostbyname https://github.com/python/cpython/search?utf8=✓&q=gethostbyn...

Animats 12y 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 12y 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
fragmede 12y 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 12y ago
I hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.
- lazaroclapp 12y 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.

sh943 12y 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 12y 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-wont-update-libc6-to-2-15-0ubuntu10-10 http://askubuntu.com/questions/578565/ubuntu-12-04-5-lts-won...

rdhyee 12y 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-2015-0235.html 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 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-instead-of-glibc/372880#372880 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-2015-0235.html 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 12y 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 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.
- 12y ago

kungfooman 12y 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%28%29-Remote-Exploit&p=11295#post11295 http://killtube.org/showthread.php?2118-GHOST-gethostbyname%...

kungfooman 12y ago

beagle3 12y 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 https://news.ycombinator.com/item?id=8954458 , getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes' ssh setup vulnerable or not?

cft 12y 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.
- beagle3 12y 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.
  - cft 12y ago
    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.

jerematasno 12y 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-overview-ghost-cve-2015-0235.html#versions http://chargen.matasano.com/chargen/2015/1/27/vulnerability-...

mirimir 12y 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> http://seclists.org/oss-sec/2015/q1/283>.

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

skeer5 12y ago

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

awkgeek 12y 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-recap-of-what-you-need-to-know http://blog.wallarm.com/post/109402223343/ghost-a-brief-reca...

brunes 12y 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?