Ghost, nuevo 0day en linux (CVE-2015-0235)

Ghost, nuevo 0day en linux (CVE-2015-0235)

9:40 0 Comments A+ a-


Qualys ha publicado una vulnerabilidad grave de desbordamiento de buffer en la función __nss_hostname_digits_dots() usada por otras funciones tan comunes como gethostbyname() y gethostbyname2() de glibc, que un atacante podría provocar al intentar resolver un nombre de host inválido (/etc/hosts o DNS).

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:

Código: C
  1. GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
  2. GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
  3. cat <<"EOF" > $GHOSTTEMP
  4. #include <netdb.h>
  5. #include <stdio.h>
  6. #include <stdlib.h>
  7. #include <string.h>
  8. #include <errno.h>
  9.  
  10. #define CANARY "in_the_coal_mine"
  11.  
  12. struct {
  13.   char buffer[1024];
  14.   char canary[sizeof(CANARY)];
  15. } temp = { "buffer", CANARY };
  16.  
  17. int main(void) {
  18.   struct hostent resbuf;
  19.   struct hostent *result;
  20.   int herrno;
  21.   int retval;
  22.  
  23.   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  24.   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  25.   char name[sizeof(temp.buffer)];
  26.   memset(name, '0', len);
  27.   name[len] = '\0';
  28.  
  29.   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
  30.  
  31.   if (strcmp(temp.canary, CANARY) != 0) {
  32.     puts("vulnerable");
  33.     exit(EXIT_SUCCESS);
  34.   }
  35.   if (retval == ERANGE) {
  36.     puts("not vulnerable");
  37.     exit(EXIT_SUCCESS);
  38.   }
  39.   puts("should not happen");
  40.   exit(EXIT_FAILURE);
  41. }
  42. EOF
  43. gcc -x c $GHOSTTEMP -o $GHOSTEXEC
  44. $GHOSTEXEC
  45. 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:

Código: Text
  1. Ubuntu
  2. 10.04 LTS     fix available     fixed in libc6 2.11.1-0ubuntu7.20
  3. 12.04 LTS     fix available     fixed in libc6 2.15-0ubuntu10.10
  4. 14 and newer     not vulnerable
  5.  
  6. Debian
  7. 6.x - squeeze     vulnerable
  8. 6.x - squeeze (LTS)     vulnerable
  9. 7.x - wheezy     vulnerable
  10. 7.x - wheezy (security)     fix available     fixed in glib 2.13-38+deb7u7
  11. 8.0 - jesse     not vulnerable
  12. dev - sid     not vulnerable
  13.  
  14. Red Hat Enterprise
  15. fix information
  16. Desktop (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  17. Desktop (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  18. HPC Node (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  19. HPC Node (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  20. Server (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  21. Server (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  22. Server EUS (v. 6.6.z)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  23. Workstation (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  24. Workstation (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  25.  
  26. Mint
  27. 13 “Maya”     fix available     Tracks Ubuntu 12.04, should get update from Ubuntu servers
  28. 17 “Qiana”     not vulnerable
  29. 17.1 “Rebecca”     not vulnerable
  30.  
  31. Gentoo
  32. libc information
  33. stable     not vulnerable      uses glibc 2.19-r1
  34.  
  35. Arch
  36. fixed in all releases since August 2013, discussion here and package info here
  37. anything recent     not vulnerable
  38.  
  39. Fedora
  40. discussion
  41. 19 and earlier     vulnerable     uses glibc 2.17 and earlier
  42. 20     not vulnerable     uses glibc 2.18
  43. 21     not vulnerable     uses glibc 2.20
  44.  
  45. Mandriva Linux
  46. all     vulnerable     appears to use glibc 2.16
  47.  
  48. openSUSE
  49. vulnerability information
  50. Enterprise 11 & older     vulnerable
  51. Enterprise 12     not vulnerable
  52. openSUSE 13.1 & newer      not vulnerable
  53.  
  54. Slackware
  55. current     not vulnerable     uses glibc 2.20
  56. 14.1 and earlier     vulnerable     uses glibc 2.17 and earlier
  57.  
  58. Knoppix
  59. information about glibc versions
  60. 7.2 and earlier     vulnerable     uses glibc 2.17 and earlier
  61. 7.4 and later     not vulnerable     uses glibc 2.19 and later
  62.  
  63. Slax
  64. all     vulnerable     appears to use glibc 2.15

Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente el día 27 de enero, 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.

Fuente: Hackplayers

Suscribirse a: Enviar comentarios (Atom)