Error de GHOST: ¿hay una forma sencilla de probar si mi sistema es seguro?

Parece que puedes descargar una herramienta de la Universidad de Chicago que te permitirá probar tu sistema para detectar la 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 ] 

Ejecutando 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 El código fuente de esa secuencia de comandos se parece al siguiente bloque de código , pero de todos modos debe inspeccionar el código de origen primero . Como otros han señalado, si está ejecutando código arbitrariamente desde Internet sin saber qué hace, 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] = "\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); } 

Editar : agregué un libro de jugadas ansible aquí si es útil para alguien, si tiene un gran número de sistemas para probar, entonces ansible le permitirá hacerlo rápidamente.

Además, según la discusión a continuación, si encuentra que sus servidores son vulnerables y aplica los parches disponibles, es muy recomendable que reinicie su sistema .

Comentarios

• @KasperSouren Bueno, sí. Si es vulnerable, aplique el parche / actualización y reinicie.
• @KasperSouren Lo que ‘ está preguntando es francamente un poco tonto. Esta respuesta responde perfectamente a su pregunta: ¿cómo detecto esta vulnerabilidad? Eso ‘ es todo lo que pediste. Pedir un » one liner » también es un poco tonto. Ejecuté la prueba que publicó aquí en todos mis servidores en menos de 2 minutos. Es ‘ absolutamente simple. Solo » shutdown -r now » después de ‘ haber terminado ….. ..
• Actualicé, ejecuté la prueba, no ‘ t reiniciar. Solo volví a esto cuando descubrí que tenía que reiniciar. Esto puede sucederle a muchas personas y sus servidores pueden ser vulnerables y pueden ser pirateados a pesar de su falsa sensación de seguridad. Así que no es tan tonto aclarar esto si es posible en mi humilde opinión.
• El GHOST.c POC se origina en el Qualys original advisory .
• @KasperSouren una prueba puede decirle que los nuevos programas utilizarán una versión segura de glibc. Sin embargo, es posible que tenga programas ejecutándose en segundo plano que se iniciaron antes de la actualización y, por lo tanto, haya cargado la versión anterior.

PHP de una sola línea:

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

Python de una sola línea:

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

Si te dan segfaults (sí, un segfault de Python, un espécimen raro) entonces eres vulnerable. No sé si consideras Python como una «herramienta de desarrollo» pero PHP es un programa común.

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

Comentarios

• ¿Es posible combinar esto con sudo lsof | grep libc- | grep DEL"? Se proporciona en otro comentario, para evitarlo. la gente piensa que ‘ están a salvo mientras la antigua libc todavía está en uso. Con esta adición, ‘ daré la recompensa de inmediato.
• Es ‘ un comando de shell, por lo que puede agregar cosas con & &. Y ese comando es solo después de haber actualizado sus paquetes glibc.Si ‘ ha actualizado, estas líneas únicas fallarán. Entonces, ¿coloca su actualización vommamd en el medio?
• Usé el php en SUSE 11SP3, y no vi ningún error de segmentación antes o después del parche. ¿Alguna idea?
• @marcin Eso ‘ es interesante. Los extraje de fuentes de Internet y muchas personas informan que se han producido errores de segmentación. ¿El aumento del recuento de bucles hace algo? (Por lo que ‘ vale, el segfault para Python también lo hará en algunos sistemas parcheados … no se sabe por qué eso ‘ está sucediendo.)
• Después de jugar con el código uchicago, parece que si intenta desbordar más de 4 bytes, gethostbyname () devolverá un error (EINVAL) en lugar de desbordarse. Con C puede controlar exactamente lo que se sobrescribe. Con PHP o Python, lo que se sobrescribe puede ser importante y segregado, o puede que no sea nada; ‘ dependerá de la compilación exacta del sistema. Y el segfault de Python en gethostbyname("0"*50000000) me parece más un error en Python. (¿Ghost Python?)

La respuesta de Aaronfay ya está cubierta para determinar si su sistema subyacente es vulnerable, pero no detecta si hay programas que todavía se están ejecutando usando la versión anterior de glibc después de la actualización. Es decir, podría actualizar sin reiniciar los procesos afectados, y el script informaría «no vulnerable» aunque la biblioteca antigua y vulnerable todavía esté en uso.

Aquí hay una forma de verificar si hay alguna Los programas vinculados dinámicamente que todavía usan 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 usan pueden estar vulnerable.

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 vinculado estáticamente en un binario, tanto porque del tamaño, y porque presenta algunas otras molestias y dificultades. En el caso de que sí tenga programas que utilicen un glibc compilado estáticamente (que es casi seguro que no lo haga), necesitará volver a compilarlos.

Comentarios

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" un poco más preciso, muestra los nombres completos de los procesos y busca vínculos a archivos que fueron eliminados.

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

Red Hat ha regresado y declaró que su script detector es defectuoso. Tenga en cuenta que también existe una preocupación en RHEL6.6 cuando se usa yum –security para parchear la vulnerabilidad, ya que se ha pasado por alto de acuerdo con https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Comentarios

• La herramienta RedHat solo verifica la versión de glibc RPM , y solo conoce las versiones de RedHat (y probablemente las derivadas). En realidad, no funciona en ningún otro sistema operativo.
• Esto tampoco está disponible para descargar, probablemente se deba a las fallas.