Concretamente la función __nss_hostname_digits_dots() no calcula correctamente el tamaño del buffer que tiene que reservar y, bajo ciertas circunstancias, se pueden sobrescribir datos arbitrariamente mediante este desbordamiento. Aunque en principio sólo se pueden sobrescribir 4 bytes de memoria, se ha demostrado que son suficientes para evadir mitigaciones como ASLR y PIE y conseguir la ejecución remota de código.
En la práctica, esto se podría explotar solicitando resolver un nombre de host lo suficientemente largo (al menos 1KB) que cumpla los requisitos normales de nomenclatura (a.b.c.d).
Esta vulnerabilidad bautizada como GHOST (por su paralelismo con el nombre de la función afectada) y con código CVE-2015-0235, puede hacer que el atacante tome el control de un servidor Linux con el usuario de la aplicación que está ejecutando la resolución de nombre: Apache, Exim, Sendmail, Nginx, MySQL, TAZAS, Samba, ... ¡la lista es enorme!
Las versiones afectadas son:
- glibc 2.2 a 2.17 (incluidas) son vulnerables
- glibc 2.18 a 2.20 (incluidas) NO son vulnerables
- las versiones anteriores de glibc (<= 2.1.3) NO son vulnerables
Mediante el siguiente script en C hecho por la Universidad de Chicago podemos comprobar si somos vulnerables:
GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
cat <<"EOF" > $GHOSTTEMP
#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);
}
EOF
gcc -x c $GHOSTTEMP -o $GHOSTEXEC
$GHOSTEXEC
rm -f $GHOSTTEMP $GHOSTEXECPaste your text here.
En caso que seamos vulnerables tendremos:
(...) # gcc -x c $GHOSTTEMP -o $GHOSTEXEC # $GHOSTEXEC vulnerable # rm -f $GHOSTTEMP $GHOSTEXEC
Las siguientes distribuciones de Linux tiene versiones vulnerables de glibc:
Ubuntu
10.04 LTS fix available fixed in libc6 2.11.1-0ubuntu7.20
12.04 LTS fix available fixed in libc6 2.15-0ubuntu10.10
14 and newer not vulnerable
Debian
6.x - squeeze vulnerable
6.x - squeeze (LTS) vulnerable
7.x - wheezy vulnerable
7.x - wheezy (security) fix available fixed in glib 2.13-38+deb7u7
8.0 - jesse not vulnerable
dev - sid not vulnerable
Red Hat Enterprise
fix information
Desktop (v. 6) fix available fixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7) fix available fixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6) fix available fixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7) fix available fixed in glibc-2.17-55.el7_0.5
Server (v. 6) fix available fixed in glibc-2.12-1.149.el6_6.5
Server (v. 7) fix available fixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z) fix available fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6) fix available fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7) fix available fixed in glibc-2.17-55.el7_0.5
Mint
13 “Maya” fix available Tracks Ubuntu 12.04, should get update from Ubuntu servers
17 “Qiana” not vulnerable
17.1 “Rebecca” not vulnerable
Gentoo
libc information
stable not vulnerable uses glibc 2.19-r1
Arch
fixed in all releases since August 2013, discussion here and package info here
anything recent not vulnerable
Fedora
discussion
19 and earlier vulnerable uses glibc 2.17 and earlier
20 not vulnerable uses glibc 2.18
21 not vulnerable uses glibc 2.20
Mandriva Linux
all vulnerable appears to use glibc 2.16
openSUSE
vulnerability information
Enterprise 11 & older vulnerable
Enterprise 12 not vulnerable
openSUSE 13.1 & newer not vulnerable
Slackware
current not vulnerable uses glibc 2.20
14.1 and earlier vulnerable uses glibc 2.17 and earlier
Knoppix
information about glibc versions
7.2 and earlier vulnerable uses glibc 2.17 and earlier
7.4 and later not vulnerable uses glibc 2.19 and later
Slax
all vulnerable appears to use glibc 2.15
Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente ayer, es que estaba en glibc desde el año 2000 y no fue resuelta hasta 2013; sin embargo, la corrección no se marcó como de seguridad, por lo que distribuciones de largo recorrido como las LTS de Ubuntu, Debian o RHEL, no aplicaron el parche.
Sea como fuere, si tu distribución tiene ya parches disponibles aplicalos cuanto antes:
- Actualiza a glibc 2.18 o más reciente
- Reinicia todos los procesos que cargan la biblioteca glibc
- Corrige los nuevos binarios de software que estén enlazados estáticamente contra versiones vulnerables de la biblioteca glibc.
Fuentes:
- The GHOST Vulnerability
- Critical “GHOST” Vulnerability Released
- GHOST, el fantasma que acechaba en glibc
- Comprobar si somos vulnerables a Ghost CVE-2015-0235
- Ghost, un agujero de seguridad en Linux más peligroso para Internet que Heartbleed
- Vulnerability Overview: Ghost (CVE-2015-0235)
- Severe “Ghost” flaw leaves Linux systems vulnerable to takeover
- Scary 'Ghost' vulnerability leaves Linux systems vulnerable to possession
- GHOST: glibc: buffer overflow en gethostbyname CVE-2015-0235
No hay comentarios:
Publicar un comentario