Bug di GHOST: esiste un modo semplice per verificare se il mio sistema è sicuro?

Sembra che tu possa scaricare uno strumento da l'Università di Chicago che ti permetterà di testare il tuo sistema per vulnerabilità.

Questo non ripara o riavvia nulla ti dirà solo se il tuo sistema è vulnerabile.

$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]

Eseguito su uno dei miei server remoti ottengo:

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

Il codice sorgente di quello script appare come il prossimo blocco di codice , ma dovresti comunque ispezionare il codice di origine . Come altri hanno sottolineato, se esegui arbitrariamente un codice da Internet senza sapere cosa fa, potrebbero accadere cose brutte :

/*
 * 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] = '
$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]
';

  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);
}

Modifica : Ho aggiunto un playbook ansible qui se è utile a chiunque, se hai un gran numero di i sistemi per testare quindi ansible ti permetteranno di farlo rapidamente.

Inoltre, come descritto di seguito, se ritieni che i server siano vulnerabili e applichi le patch disponibili, è altamente consigliato riavviare il sistema .

PHP one-liner:

php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }'

One-liner Python:

python -c 'import socket;y="0"*50000000;socket.gethostbyname(y)'

Se quelli ti danno segfaults (sì, un segfault di Python, un raro esemplare) allora sei vulnerabile. Non so se consideri Python uno "strumento di sviluppo", ma PHP è un programma comune da avere.

Se il dispositivo di destinazione è un router, non so nulla di ciò che potreste fare su di esso che vi dirà, ad eccezione di scavare nelle specifiche del produttore e / o in attesa di avvisi del produttore e aggiornamenti del firmware.

La risposta di aaronfay è già stata valutata determinando se il tuo sistema sottostante è vulnerabile, ma non rileva se ci sono programmi che sono ancora in esecuzione usando la vecchia versione di glibc dopo l'aggiornamento. Ovvero, è possibile eseguire l'aggiornamento senza riavviare i processi interessati e lo script segnalerebbe "non vulnerabile" anche se la vecchia libreria vulnerabile è ancora in uso.

Ecco un modo per verificare se ci sono dei programmi collegati dinamicamente che usano ancora la vecchia versione di glibc:

sudo lsof | grep libc- | grep DEL

Se ci sono risultati, le versioni cancellate di glibc sono in uso e i processi che li utilizzano potrebbero essere vulnerabili.

Naturalmente, questo non copre il caso in cui glibc è stato collegato staticamente. La buona notizia (?) È che è molto raro trovare glibc staticamente collegati in un binario, sia a causa delle dimensioni, sia perché presenta altri fastidi e difficoltà. Nel caso in cui fai abbia programmi che usano glibc compilati staticamente (che quasi certamente non fanno), dovresti ricompilarli.

Se hai un account su Redhat, puoi accedere al loro "rilevatore di GHOST" all'indirizzo questo URL . È un piccolo script di shell che ti dirà se il tuo glibc è vulnerabile.

Red Hat è tornato e ha dichiarato che il loro script del detentore è difettoso. Si noti che c'è anche un problema su RHEL6.6 quando si utilizza yum --security per correggere la vulnerabilità in quanto è stata omessa in base a link .