Hace par de días el colega @elmor3no me alertaba vía email de una nueva vulnerabilidad en Wget y la necesidad o posibilidad de compartir la solución en GUTL. Hoy les traigo el chisme completo, con la posible solución y todo. Si bien hace poco hablábamos de la vulnerabilidad encontrada en Bash, esta semana que recién concluyó estuvo marcada para la familia GNU por la falla de seguridad encontrada en GNU Wget, la popular herramienta usada para la recuperación de archivos de la Web. Veamos de que se trata.
Según nos cuenta Antonio Ropero en Hispasec (noticia que fue difundida oportunamente en nuestra lista de correos), se ha anunciado una vulnerabilidad en wget que podría permitir a un atacante remoto crear archivos arbitrarios, directorios y enlaces simbólicos en el sistema afectado.
GNU Wget es una herramienta libre para la descarga de contenidos desde servidores web de una forma simple, soporta descargas mediante los protocolos http, https y ftp. Entre las características más destacadas está la posibilidad de fácil descarga de mirrors complejos de forma recursiva (cualidad que permite la vulnerabilidad descubierta), conversión de enlaces para la visualización de contenidos HTML localmente, soporte para proxies, etc.
El problema, con CVE-2014-4877, reside en un ataque de enlace simbólico, de forma que un atacante remoto podría crear un directorio específicamente manipulado que al ser recuperado de forma recursiva a través de ftp, podría crear archivos arbitrarios, directorios o enlaces simbólicos y asignar sus permisos en el sistema.
Fue HD Moore, jefe de investigación de Rapid 7 y creador del framework de pruebas Metasploit, quien descubrió la vulnerabilidad y dio aviso al proyecto GNU Wget. Esto permitió a sus desarrolladores crear un parche para poner a salvo a los usuarios de la mayoría de las grandes distribuciones de Linux antes de que el tema llegara a los primeros planos y pudiera ser explotado en forma maliciosa, algo que por desgracia no sucedió en el caso de Shellshock.
Esto deja en evidencia una vez más el gran potencial de seguridad que el open source tiene como plataforma, puesto que no solo es mucho más segura que el software propietario sino que cuando se produce algun que otro fallo o vulnerabilidad (porque de vez en cuando los hay claro) estos se solucionan en forma mucho más rápida ya que no hay que esperar a que una gran compañía (como Apple o Microsoft) lance un parche de seguridad.
Se ha publicado la versión 1.16 que soluciona el problema, disponible en:
ftp://ftp.gnu.org/gnu/wget/wget-1.16.tar.gz
ftp://ftp.gnu.org/gnu/wget/wget-1.16.tar.xz
también existe una corrección en forma de código fuente:
http://git.savannah.gnu.org/cgit/wget.git/commit/?id=18b0979357ed7dc4e11d4f2b1d7e0f5932d82aa7
Debido a lo sensible del tema, creemos pertinente compartir la descarga del paquete actualizado con las fuentes de Wget corregido también para los que solo tienen acceso a la Intranet nacional. Aunque me detengo y me pregunto… ¿Quién podría atacar a los que solo tienen acceso al .cu?. Igual, acá les dejo el enlace:
Ahora les va a tocar compilar el paquetico compartido más arriba o sentarse a esperar que llegue la solución vía repositorios a su distribución en particular. Como esto suele en ocasiones tardar algunos días, yo preferí compilar la nueva versión de Wget.
Preparando el camino para compilar la versión corregida de Wget
Compilando la versión 1.16 de Wget
Más tranquilo, todo en orden
Fuente:
¿Te resultó interesante? Compártelo ...
Gracias por compartir Maikel. Habia leido algo de esto hace un par de días.
Saludos.
Vaya realmente no habia escuchado sobre esto asi que paradojicamente estoy descargando el codigo fuente del wget 1.16 usando wget 1.13.4 😉
En la lista Lazaro inicio el debate sobre el tema:
https://listas.jovenclub.cu/pipermail/gutl-l/2014-October/023132.html
No se por que pero me está dando error a la hora de compilarlo… dice que no encuentra las cosas pero al menos se que tengo GCC y MAKE instalados
Ademas de estas dos cosas que mas necesito porque hago el ./configure y el config.log no veo problemas.
Si, lee bien las cosas que te pide, ahora mismo no estoy en mi PC, pero anoche para compilarlo en casa tuve que instalar dos o tres cosillas mas, lo iba a anotar para aclararlo a quienes tuvieran duda pero lo olvide… Mira bien lo que te devuelve al terminar de ejecutar el ./configure, ahi te dice que le falta, recuerda que lo que te pida, son generalmente librerias de desarrollo asi que búscalas primeramente por libloquesea-dev
lo unico que pudiera estar dando problemas en el config.log sería lo del libgnutls que me dice algo como:
configure: error: –with-ssl=gnutls was given, but GNUTLS is not available.
Ya le instale el libgnutls pero parece que no es ese el paquete que el quiere
aptitude install libgnutls-devExactamente que error te da????
bueno la salida del .config es un tanto larga pero el unico error que me da es ese que de que «gnutls ha sido dado pero GNUTLS no está diponible». No te preocupes… cuando tengas un tiempo y estes en casa me escribes un correo con las dependencias que seguro me faltan.
Probaste esto???
el -dev da un error de dependencias ahí con 3 paquetes que segun el sistema estan obsoletos (el precio de no poder tener un repo lo mas actualizado posible).
Tienes declarado el repo backports??? De ser asi, comenta (#) esa linea en el sources.list y prueba nuevamente. De todas maneras no deberia haber errores de dependencias aunque tu repo este desactualizado, porque si esta desactualizado, al menos esa copia que tienes debe tener coherencia entre todos sus paquetes…
No es necesario compilar: https://www.debian.org/security/2014/dsa-3062
En todo caso el que no tenga acceso a los repos se puede conseguir el deb.
Corred insensatos, que seguro algún Hacker, pasará por los Proxies, DMZ y demás artilugios de nuestras redes y usando Wget, nos robará las carpetas de fotos de nuestra familia…
O sea.. no hay que hacer un lío de todo esto por favor.. 😛