GHOST (CVE-2015-0235) just popped up. How can I quickly check if a system of mine is secure? Ideally with a one line shell command.
According to the ZDNet article "you should then reboot the system". Ideally the test would also indicate this...
GHOST (CVE-2015-0235) just popped up. How can I quickly check if a system of mine is secure? Ideally with a one line shell command.
According to the ZDNet article "you should then reboot the system". Ideally the test would also indicate this...
It appears you can download a tool from the University of Chicago that will let you test your system for the vulnerability.
This does not repair or restart anything it will only tell you if your system is vulnerable.
$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]
Running this on one of my remote servers I get:
user@host:~# wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
--2015-01-27 22:30:46-- https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
Resolving webshare.uchicago.edu (webshare.uchicago.edu)... 128.135.22.61
Connecting to webshare.uchicago.edu (webshare.uchicago.edu)|128.135.22.61|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1046 (1.0K) [text/x-csrc]
Saving to: `GHOST.c'
100%[============================================>] 1,046 --.-K/s in 0s
2015-01-27 22:30:48 (237 MB/s) - `GHOST.c' saved [1046/1046]
user@host:~# gcc GHOST.c -o GHOST
user@host:~# ./GHOST
vulnerable
The source code of that script looks like this next code block but you should inspect the origin code first anyway. As others have pointed out, if you are arbitrarily running code off the internet without knowing what it does then bad things may happen:
/*
* GHOST vulnerability check
* http://www.openwall.com/lists/oss-security/2015/01/27/9
* Usage: gcc GHOST.c -o GHOST && ./GHOST
*/
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#define CANARY "in_the_coal_mine"
struct {
char buffer[1024];
char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };
int main(void) {
struct hostent resbuf;
struct hostent *result;
int herrno;
int retval;
/*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
char name[sizeof(temp.buffer)];
memset(name, '0', len);
name[len] = '\0';
retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
if (strcmp(temp.canary, CANARY) != 0) {
puts("vulnerable");
exit(EXIT_SUCCESS);
}
if (retval == ERANGE) {
puts("not vulnerable");
exit(EXIT_SUCCESS);
}
puts("should not happen");
exit(EXIT_FAILURE);
}
Edit: I've added an ansible playbook here if it's of use to anyone, if you have a large number of systems to test then ansible will allow you to do it quickly.
Also, as per discussion below, if you find your servers are vulnerable and apply available patches, it is highly recommended that you reboot your system.
PHP one-liner:
php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }'
Python one-liner:
python -c 'import socket;y="0"*50000000;socket.gethostbyname(y)'
If those give you segfaults (yes, a Python segfault, a rare specimen) then you're vulnerable. I don't know if you consider Python a "developer tool" but PHP is a common program to have.
If the target device is a router, I don't know of anything you could do on it that would tell you, except digging into the manufacturer specifications and/or waiting for manufacturer advisories and firmware updates.
aaronfay's answer already covered determining whether your underlying system is vulnerable, but it doesn't detect if there are programs that are still running using the old version of glibc after upgrade. That is, you could upgrade without restarting the affected processes, and the script would report "not vulnerable" even though the old, vulnerable library is still in use.
Here is one way to check if there are any dynamically linked programs still using the old version of glibc:
sudo lsof | grep libc- | grep DEL
If there are results, deleted versions of glibc are in use, and the processes using them may be vulnerable.
Of course, this doesn't cover the case in which glibc was statically linked. The good(?) news is that it's very rare to find glibc statically linked in a binary, both because of the size, and because it presents some other annoyances and difficulties. In the case that you do have programs using a statically compiled glibc (which you almost certainly don't), you would need to recompile them.
If you have an account in Redhat, you can access their 'GHOST detector' at this URL . Its a small shell script that will tell you whether your glibc
is vulnerable.
Red Hat has now come back and stated that their detector script is flawed. Note that there is also a concern on RHEL6.6 when using yum --security to patch the vulnerability as it has been missed according to https://bugzilla.redhat.com/show_bug.cgi?id=1186717.