Tags: seguridad, redes-sociales

Comenta este interesante artículo de EL PAÍS "Mi Twitter es también de mi empresa" que

• una encuesta de la consultora Manpower Professional revela que el 75% de los empleados afirma que sus empresas no cuentan con una política formal sobre el uso de las redes sociales en el trabajo. "Esto sugiere que una amplia mayoría de empresas está adoptando la postura de 'esperar a ver qué sucede' antes de desarrollar sus propias políticas sobre el uso de las redes sociales", dice el estudio.

lo cual indica que la mayoría de las empresas ni siquiera se han planteado redactar una "Política de Seguridad", que, en una primera aproximación podríamos definir como hace la Wikipedia:

• La política de seguridad es un documento de alto nivel que denota el compromiso de la gerencia con la seguridad de la información. Contiene la definición de la seguridad de la información bajo el punto de vista de cierta entidad. Debe ser enriquecida y compatibilizada con otras políticas dependientes de ésta, objetivos de seguridad, procedimientos (véase referencias más adelante). Debe estar fácilmente accesible de forma que los empleados estén al tanto de su existencia y entiendan su contenido. Puede ser también un documento único o inserto en un manual de seguridad. Se debe designar un propietario que será el responsable de su mantenimiento y su actualización a cualquier cambio que se requiera.

Es decir que una Política de Seguridad se asemeja a una Constitución porque marca las líneas maestras de actuación, pero también se asemeja a una Ley porque contiene acciones concretas sobre cómo implementar esas ideas en el escenario actual. La política se seguridad debe de ser constantemente enriquecida, tanto en las líneas maestras de actuación (que cambian al surgir nuevas tecnologías) como en la forma de abordar esas líneas maestras (ya que el escenario tecnológico y empresarial es cambiante).

Como Constitución la política de seguridad contesta a tres preguntas:

• [1] ¿Qué necesito proteger?
• [2] ¿De qué necesito protegerme?
• [3] ¿Cómo voy a protegerme?

Como Ley la política de seguridad propone normas de actuación semejantes a los diez mandamientos. Semejantes porque no solo dicta qué NO hacer sino también (preferentemente) qué SÍ hacer.

Podemos decir que ha habido tres GENERACIONES de políticas de seguridad:

• Generación 1 que trata de aspectos muy tecnológicos y de seguridad de red
• Generación 2 que trata de regular el uso del ordenador que maneja el usuario
• Generación 3 en la que estamos ahora, que trata de regular el impacto en la reputación empresarial del uso de las redes sociales por parte de sus empleados desde sus cuentas personales

Primera generación

Esta es la única conocida en la mayoría de las empresas.

Inicialmente se asoció el término Política de Seguridad con cortafuegos, hacking, intrusiones, con lo que el tema se abordó desde un punto de vista puramente tecnológico, contestando de esta forma a las tres preguntas básicas que orientan una política de seguridad:

[1] ¿Qué necesito proteger? La continuidad de mis sistemas de información: servidores, servicios y líneas de comunicaciones; y los datos que en ellos se gestionan.

[2] ¿De qué necesito protegerme? De las vulnerabilidades del software, de errores de configuración y de malas prácticas de uso

[3] ¿Cómo voy a protegerme? Aplicando parches de seguridad, auditando el código que programo yo mismo, haciendo copias de seguridad de datos y de configuraciones y mediante la formación contínua del personal técnico.

Esto es un error porque como voy a comentar a continuación, la política de seguridad es, en realidad, el contrato por el que se regula el uso de los medios tecnológicos en una empresa, y no son solo los técnicos los que usan dichos medios, sino todos los usuarios, así que ¿por qué no se incluye en la política de seguridad la regulación de las actividades informáticas de los usuarios?

Que una empresa se planteara hacer al menos la primera aproximación a la política de seguridad, la que solo trate solo detalles tecnicos ya sería un logro: Sony acaba de reconocer que usaban un software para su servidor web que tenía muchas vulnerabilidades conocidas y además no lo protegían con un cortafuegos. Esto indica que o no había una política de seguridad o no se cumplió.

Si suponemos que Sony es una empresa seria con buenos profesionales, no vamos a entrar en cómo gestiona su seguridad una empresa que reutiliza al "informático" de chico para todo: para configurar un servidor, instalar Office, configurar el router. De hacer auditorías de código a las aplicaciones que la propia empresa desarrolla mejor ni hablamos. Ciencia ficción.

Pues en estas estamos, aún intentando implementar la forma más básica de una política de seguridad para que la gestión de la informática se parezca a una ingeniería y genere sistemas predecibles y repetibles cuando los usuarios empiezan a hacer cosas que repercuten en la seguridad de los sistemas.

Segunda generación

Nueva versión de las tres preguntas basicas de la política de seguridad en la que empezamos a incluir a los usuarios:

[1] ¿Qué necesito proteger? La continuidad de servicio de los PCs de escritorio y la privacidad de lo que en ellos se teclea y almacena

[2] ¿De qué necesito protegerme? Del software que el usuario se instala en su PC que contiene programas espía, troyanos, keyloggers, virus y otros ataques al navegador.

[3] ¿Cómo voy a protegerme? Usando siempre navegadores seguros, aplicando en ellos los parches de seguridad que los fabricantes recomienden. Formando a los usuarios para que conozcan las amenazas de sitios web inseguros.

En este punto empieza a surgir lo que yo denomino dictadura tecnoaristocrática: aquellos técnicos que conocen las amenazas (y el trabajo que les va a dar solucionarlas si se consuman) toman decisiones radicales con la esperanza de mitigar las amenazas mediante el recorte de las libertades de los usuarios (forma de pensar muy de moda desde hace unos años, y no solo en temas informáticos). Así que nuestro administrador de sistemas empieza a tomar unilateralmente decisiones que (según él) mejoran la seguridad de la instalación sin que haya (según él) ninguna consecuencia negativa para los usuarios.

Nuestro sysadmin emite desde su Sinaí Tecnológico los diez mandamientos de la seguridad:

1. No instalarás nada que yo no autorice
2. ¿Que quieres usar un Mac? ¿Linux? ¡Estás loco! ¡Aquí solo se usan PCs con Windows!
3. Yo soy quien decido qué sitios web visitas
4. Yo soy quien decido si algo es personal o de trabajo
5. No puedes usar el disco duro del ordenador para almacenar música o fotos personales, es una herramienta de la empresa
6. No pincharás ningúna llave USB en tu equipo para que no puedas llevarte nada a casa
7. El Flash 9 ha funcionado toda la vida así que la versión 10 es para ver chorradas en Internet
8. ¿Para qué quieres instalar Firefox si tenemos Explorer?
9. ¿Plugins de navegador? ¿Para jugar a qué?
10. Como me hartes te corto la red (arrieros somos...)

Aseguro que he visto en acción estos diez mandamientos, si bien no todos a la vez.

La dirección de la empresa, que no tiene ni idea de tecnología, ve muy razonable este recorte de libertades puesto que en el fondo siempre ha creído que la gente usa el ordenador para jugar y chatear y ve con buenos ojos un poco de mano dura tecnológica.

Este recorte tecnológico es exactamente lo contrario de lo que pide la política de seguridad, cuyo objetivo no es principalmente impedir sino de promover.

Compare los anteriores con estos nuevos diez mandamientos de la seguridad:

1. Todas las aplicaciones críticas para la empresa estarán alojadas en servidores, a los que los usuarios se conectarán desde sus PCs como si de terminales se tratara
2. Los datos de las aplicaciones y el perfil del usuario estarán almacenados en servidores, nunca en el PC del usuario. De estos datos se hará copia de seguridad
3. La ofimática puede ser usada en el PC del usuario pero siempre habrá esas mismas aplicaciones disponibles en modo terminal
4. El usuario puede instalar en su PC cualquier software que considere útil y que parezca seguro según los criterios que se le transmitieron en el curso de formación de seguridad.
5. El usuario puede usar para sus datos personales el disco duro de su ordenador, no así las unidades de red. Es responsable de hacer copias de seguridad de los datos de su PC si así lo desea. La empresa no lo hará.
6. El usuario debe avisar rápidamente al Centro de Atención de Usuarios si el programa software que le permite convertir su PC en terminal y acceder a las aplicaciones ha dejado de funcionar por haber instalado nuevo software o por cualquier otra causa.
7. En caso de que el PC del usuario se estropee, se le cambiará inmediatamente por un Thin Client con funciones de Terminal y el PC del usuario se devolverá a la configuración original, perdiéndose todos los datos que tuviera almacenados.
8. Los sitios web que el usuario no puede visitar serán los que infrinjan la legislación vigente y aquellos que la mesa interdepartamental de seguridad decida. En todo caso serán conocidos por los usuarios mediante información publicada en la intranet.
9. El usuario recibirá un folleto en el que se le detallan estas instrucciones y será formado para que pueda comprenderlas y seguirlas. Deberá expresar su aceptación mediante devolver a la mesa interdepartamental de seguridad el formulario de aceptación debidamente firmado.
10. Si un empleado cree que cualquiera de estas normas obstaculiza su trabajo de alguna forma debe informar a la mesa interdepartamental de seguridad para que se pueda revisar la norma.

Nada que ver ¿verdad? Probablemente haya que incluir algún mandamiento más, pero una empresa que adopte este estilo de mandamientos entiende que la seguridad es un proceso contínuo y que se regula desde un documento de política de seguridad redactado por una mesa interdepartamental. No solo eso, también entiende que la máxima para que una política de seguridad sea aceptada es que todos ganen, tanto el usuario como la empresa.

Tercera generación

Pues bien, llegamos al tercer escenario, que no es planteado por la navegación por Internet de los usuarios, sino por sus comentarios en las redes sociales.

Tercera versión de las preguntas de la política de seguridad, que incluyen las actividad en las redes sociales de los empleados:

[1] ¿Qué necesito proteger? La imagen que de mi empresa quiero fabricar en Internet, la reputación online.

[2] ¿De qué necesito protegerme? De empleados insatisfechos con sed de venganza, de usos ingénuos y torpes de las redes sociales.

[3] ¿Cómo voy a protegerme? Mediante formar a los empleados en los conceptos de reputación online y permitirles participar en su construcción mediante su participación en las redes sociales. Mediante una presencia activa y permanente en la red que neutralice los comentarios negativos o los reconduzca hacia un diálogo positivo.

Ahora el que se pone en el papel de "aristócrata" y trata de regular unilateralmente no es el técnico sino el directivo que vela por el prestigio de la empresa ante la sociedad y que no quiere que los trapos sucios se ventilen fuera (probalemente tampoco dentro).

Esta nueva aristocracia de la moral empresarial no soporta que alguien diga en Twitter que está aburrido una mañana mientras trabaja, o que algún empleado diga en su red social lo que dice en la fotocopiadora ante compañeros de oficina sobre sus jefes. Este nuevo aristócrata que confunde la reputación de los directivos con la de la empresa es el mismo que no sabe encajar críticas de los consumidores de sus productos, pues su sonrisa forzada esconde un "¿tú qué sabrás?" inefable.

También él, desde su "Sinaí moral" emite sus diez mandamientos, que tienen la ventaja de que son mucho más fáciles de memorizar que cuando los redacta un técnico:

1. No usaras las redes sociales desde el trabajo
2. Voy a espiar lo que dices de nosotros y como digas algo que me incomode te vas a enterar
3. No usaras las redes sociales desde el trabajo
4. Voy a espiar lo que dices de nosotros y como digas algo que me incomode te vas a enterar
5. No usaras las redes sociales desde el trabajo
6. Voy a espiar lo que dices de nosotros y como digas algo que me incomode te vas a enterar
7. No usaras las redes sociales desde el trabajo
8. Voy a espiar lo que dices de nosotros y como digas algo que me incomode te vas a enterar
9. No usaras las redes sociales desde el trabajo
10. Voy a espiar lo que dices de nosotros y como digas algo que me incomode te vas a enterar

A este estilo se opone el de quienes tratan de incluir en la política de seguridad de la empresa un código de conducta que permita a los empleados ejercer una medida de expresión y libertad al tiempo que se salvaguarda la reputación empresarial.

El artículo de EL PAÍS antes citado contiene ideas interesantes que implícitamente proponen la idea de una política de seguridad aunque erróneamente propone una ad-hoc, cometiendo en el terreno de las redes sociales el mismo error que se cometió en el terreno del uso del PC empresarial: la falta de visión global:

• demandó a American Medical Response, la empresa en la que trabajaba Souza al entender que la política que imponía a sus trabajadores de publicación en Internet era "demasiado vaga" y "contenía disposiciones ilegales"

• el 75% de los empleados afirma que sus empresas no cuentan con una política formal sobre el uso de las redes sociales en el trabajo

• una amplia mayoría de empresas está adoptando la postura de 'esperar a ver qué sucede' antes de desarrollar sus propias políticas sobre el uso de las redes sociales

¿Alguna propuesta para "diez" mandamientos que engloben las tres generaciones de políticas de seguridad? ¿Hacemos una lista unificada?

Tags: google, gmail, correo, seguridad

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

Tags: ssh, openssh

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.

Tags: vmsplice, linux, freebsd, kernel, exploits, seguridad, vulnerabilidades, patch

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.

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.

Tags: vmsplice, linux, freebsd, kernel, exploits, seguridad, vulnerabilidades

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

Tags: seguridad 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?