Bug GHOST: existe uma maneira simples de testar se meu sistema é seguro?

Parece que você pode baixar uma ferramenta da University of Chicago que permitirá que você teste a vulnerabilidade do seu sistema .

Isso não repara ou reinicia nada , apenas informa se o seu sistema está vulnerável.

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

Executando isso em um de meus servidores remotos, recebo:

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 

O o código-fonte desse script se parece com o próximo bloco de código , mas você deve inspecionar o código de origem primeiro de qualquer maneira . Como outros apontaram, se você está executando código arbitrariamente fora da Internet sem saber o que ele faz, coisas ruins podem acontecer :

/* * 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 : adicionei um manual do ansible aqui se for útil para qualquer pessoa, se você tiver um grande número de sistemas para testar, em seguida, ansible permitirá que você faça isso rapidamente.

Além disso, conforme a discussão abaixo, se você achar que seus servidores estão vulneráveis e aplicar os patches disponíveis, é altamente recomendado que você reinicie o sistema .

Comentários

• @KasperSouren Bem, sim. Se estiver vulnerável, aplique o patch / upgrade e reinicie.
• @KasperSouren O que você ‘ está perguntando é francamente um pouco bobo. Essa resposta responde perfeitamente à sua pergunta: como faço para detectar essa vulnerabilidade. Isso ‘ foi tudo o que você perguntou. Pedir um ” um liner ” também é um pouco bobo. Eu executei o teste que ele postou aqui em todos os meus servidores em menos de 2 minutos. É ‘ muito simples. Basta ” desligar -r agora ” depois de ‘ terminar ….. ..
• Eu atualizei, executei o teste, ‘ não reiniciei. Só voltei a fazer isso quando descobri que precisava reiniciar. Isso pode acontecer com algumas pessoas e seus servidores podem ser vulneráveis e podem ser hackeados, apesar de sua falsa sensação de segurança. Portanto, não é tão bobo entender isso se possível IMHO.
• O GHOST.c POC se origina do Qualys original aviso .
• um teste @KasperSouren pode dizer que novos programas usarão uma versão segura da glibc. No entanto, você pode ter programas em execução em segundo plano que foram iniciados antes da atualização e, portanto, carregaram a versão antiga.

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

Se eles fornecerem segfaults (sim, um segfault do Python, um espécime raro), então você está vulnerável. Não sei se você considera o Python uma “ferramenta de desenvolvedor”, mas PHP é um programa comum.

Se o dispositivo de destino for um roteador, não sei de nada que você possa fazer nele que diga a você, exceto cavar nas especificações do fabricante e / ou esperar por avisos do fabricante e atualizações de firmware.

Comentários

• É possível combinar isso com sudo lsof | grep libc- | grep DEL"? Fornecido em outro comentário, para evitar que as pessoas pensam que ‘ estão seguras enquanto a libc antiga ainda está em uso. Com esta adição, eu ‘ distribuirei a recompensa imediatamente.
• É ‘ um comando shell sa, para que você possa juntar as coisas com & &. E esse comando é apenas depois de atualizar seus pacotes glibc.Se você ‘ tiver atualizado, esses liners irão falhar. Então, coloque sua atualização vommamd no meio?
• Usei o php no SUSE 11SP3 e não vi nenhum segfault antes ou depois do patch. Alguma ideia?
• @marcin Isso ‘ é interessante. Extraí de fontes da Internet e muitas pessoas relataram falha em seg. Aumentar a contagem do loop faz alguma coisa? (Pelo que ‘ vale, o segfault para Python irá segregar também em alguns sistemas corrigidos … nenhuma palavra sobre o motivo disso ‘ está acontecendo.)
• Ao brincar com o código uchicago, parece que se você tentar estourar em mais de 4 bytes ou mais, gethostbyname () retornará um erro (EINVAL) em vez de estourar. Com C, você pode controlar exatamente o que é sobrescrito. Com PHP ou Python, o que é sobrescrito pode ser importante e causar falha de segurança ou pode não ser nada; ele ‘ será dependente da construção exata do sistema. E o segfault do Python em gethostbyname("0"*50000000) parece mais um bug do Python para mim. (Ghost Python?)

a resposta de aaronfay já abordada para determinar se seu sistema subjacente é vulnerável, mas não detecta se há programas que ainda estão sendo executados usando a versão antiga do glibc após a atualização. Ou seja, você poderia atualizar sem reiniciar os processos afetados, e o script relataria “não vulnerável”, embora a biblioteca antiga e vulnerável ainda esteja em uso.

Esta é uma maneira de verificar se há alguma programas vinculados dinamicamente ainda usando a versão antiga da glibc:

sudo lsof | grep libc- | grep DEL 

Se houver resultados, versões excluídas da glibc estão em uso e os processos que as usam podem estar vulnerável.

Claro, isso não cobre o caso em que a glibc foi vinculada estaticamente. A boa (?) notícia é que é muito raro encontrar a glibc vinculada estaticamente em um binário, tanto porque do tamanho, e porque apresenta alguns outros incómodos e dificuldades. No caso de você possuir programas usando um glibc compilado estaticamente (o que você quase certamente não tem), você precisará recompilá-los.

Comentários

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" um pouco mais preciso, mostra os nomes completos dos processos e procura links para arquivos que foram excluídos.

Se você tiver uma conta no Redhat, poderá acessar o “detector GHOST” em este URL . É um pequeno script de shell que dirá se o seu glibc está vulnerável.

O Red Hat agora voltou e declarou que o script do detector está com falhas. Observe que também há uma preocupação no RHEL6.6 ao usar yum –security para corrigir a vulnerabilidade, pois ela foi perdida de acordo com https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Comentários

• A ferramenta RedHat verifica apenas a versão do RPM glibc , e só conhece as versões do RedHat (e provavelmente derivados). Na verdade, não funciona em nenhum outro sistema operacional.
• Isso também não está mais disponível para download, provavelmente para as falhas.