Durante a semana, no dia 28 de janeiro para ser mais exato, vi minha linha do tempo no twitter ser infestada por gente falando sobre um tal de GHOST.
Não demorou muito tempo para que eu percebesse que não se falava sobre uma banda sueca de heavy rock ou do filme preferido da minha vó, e sim de mais uma nova séria vulnerabilidade que dessa vez afeta praticamente todos os sistemas Linux.
Então, após dar um tempo para que mais informações detalhadas surgissem sobre a tal, resolvi escrever sobre (assim como fiz com o bug Hearthbleed).
GHOST? Que porra é essa?
GHOST foi o nome dado para uma crítica vulnerabilidade encontrada na biblioteca glibc por pesquisadores da empresa de segurança Qualys. A mesma ganhou esse nome bonitinho por ser desencadeada pelas funções GetHOSTbyname*( ).
E por que tanto drama?
A biblioteca glibc é parte do coração dos sistemas linux, logo, a quantidade de sistemas usando versões vulneráveis é enorme. E ainda pior, pois a falha pode ser usada para a execução local e remota de código. Teoricamente, qualquer aplicativo, que use uma das funções gethostbyname para fazer a conversão de um nome de host para um endereço ip, é um alvo em potencial. A vulnerabilidade consiste em um belo heap overflow na espera de criatividade para ser explorado.
Essa vulnerabilidade existe desde da versão 2.2 da glibc que foi lançada em 2000 (!) e até foi corrigida em 2013, mas como não foi reconhecida como ameaça de segurança, deixou com que muitos sistemas continuassem a usar versões esculhambadas.
Uma explicação mais técnica
A vulnerabilidade GHOST é explorada por meio das funções gethostbyname*( ). O código vulnerável é chamado quando uma aplicação que faz uso da biblioteca glibc quer fazer uma resolução de DNS (algo bem comum).
Na prática o ataque ocorreria desta forma: o atacante envia um argumento malicioso como hostname, o aplicativo passa o argumento para a função vulnerável da glibc processar e é nessa hora que acontece um buffer overflow que pode finalizar o aplicativo ou dar ao atacante a possibilidade de executar código arbitrário.
Mas há algumas limitações para que a falha seja explorada. Por exemplo, como o argumento explorado é o hostname, o primeiro caractere precisa ser um número e o último não pode ser um ponto (.) e o hostname inteiro só pode ser feito de números e pontos, o que vai minar bastante a liberdade do atacante.
Para uma analise melhor e mais completa, deixo o link da própria Qualys (em english) para os amantes de bugs e exploração de software: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
Testando seu sistema
Fazer isso é simples. Compile e rode o código encontrado abaixo que roubei da analíse técnica da Qualys:
```#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) - 16sizeof(unsigned char) - 2sizeof(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); } ```
O real perigo
A Qualys tem seu PoC que explora o Exim Mail e prometeu um módulo para o Metasploit em breve e tentativas de explorar o bug in the wild estão sendo detectadas. Mas depois de todo burburinho sobre o bug, muitos estão concluindo que esta falha não é tão perigosa quanto parece e não é uma nova HeartBleed.
Nem todos aplicativos aceitam esse tipo de dado (o hostname) como uma entrada controlada pelo usuário e as limitações que citei acima também são outro empecilho. Alguns aplicativos também checam o argumento antes de passa-lo para a função vulnerável, o que também impede a exploração. Ainda é sabido que as funções vulneráveis estão obsoletas porque não são usadas para fazer a tradução de nomes de domínio para endereços IPv6 (novos aplicativos usam a função getaddrinfo( ), que dá suporte ao IPv6). E, claro, o patch para a correção da falha já existe e a solução é atualizar o sistema.
Então, caso já não esteja, atualize seu sistema, o reinicie (ou os aplicativos continuarão a usar a biblioteca antiga) e seja feliz.
Referências para esta postagem: