error de GHOST: ¿hay alguna forma sencilla de comprobar si mi sistema es seguro?

Parece que puede descargar una herramienta de University of Chicago que le permitirá probar su sistema para vulnerabilidad.

Esto no repara ni reinicia nada solo te dirá si tu sistema es vulnerable.

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

Al ejecutar esto en uno de mis servidores remotos, obtengo:

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

El código fuente de ese script se ve así en el siguiente bloque de código , pero debe inspeccionar el código de origen primero de todos modos . Como han señalado otros, si ejecuta código arbitrariamente fuera de Internet sin saber qué hace, entonces pueden suceder cosas malas :

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

Editar : He añadido un libro de juego ansible aquí si es de utilidad para cualquiera, si tiene una gran cantidad de Los sistemas para probar y luego ansible te permitirán hacerlo rápidamente.

Además, como se explica a continuación, si encuentra que sus servidores son vulnerables y aplica los parches disponibles, es muy recomendable que reinicie su sistema.

PHP de una sola línea:

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)'

Si esos te dan segregaciones (sí, una falla de Python, una muestra rara) entonces eres vulnerable. No sé si considera a Python como una "herramienta de desarrollo", pero PHP es un programa común.

Si el dispositivo de destino es un enrutador, no conozco nada que pueda hacer en él que le diga, excepto investigar las especificaciones del fabricante y / o esperar las advertencias del fabricante y las actualizaciones de firmware.

aaronfay ya cubría la determinación de si su sistema subyacente es vulnerable, pero no detecta si hay programas que aún se están ejecutando con la versión anterior de glibc después de la actualización. Es decir, podría actualizar sin reiniciar los procesos afectados, y la secuencia de comandos informaría "no vulnerable" aunque la biblioteca antigua y vulnerable aún esté en uso.

Esta es una forma de verificar si hay programas vinculados dinámicamente que aún utilizan la versión anterior de glibc:

sudo lsof | grep libc- | grep DEL

Si hay resultados, las versiones eliminadas de glibc están en uso y los procesos que las utilizan pueden ser vulnerables.

Por supuesto, esto no cubre el caso en el que glibc estaba vinculado estáticamente. La buena (?) Noticia es que es muy raro encontrar glibc estáticamente vinculado en un binario, tanto por el tamaño como por el hecho de que presenta otras molestias y dificultades. En el caso de que tengas programas que utilicen un glibc compilado estáticamente (que casi seguro que no tienes), deberías recompilarlos.

Si tiene una cuenta en Redhat, puede acceder a su 'detector GHOST' en esta URL . Es un script de shell pequeño que le dirá si su glibc es vulnerable.

Red Hat ha regresado y ha declarado que su secuencia de comandos de detección es defectuosa. Tenga en cuenta que también existe una preocupación sobre RHEL6.6 al usar yum --security para parchear la vulnerabilidad, ya que se ha perdido de acuerdo con enlace .