Check the presence of the OpenSSL's bug Heartbleed (CVE-2014-0160)

What is it?

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

What leaks in practice?

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

How to stop the leak?

As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.

How to check if my server (https) or application (linked with OpenSSL library) has it?

For your web server Heartbleed test site and specify the hostname (or IP address) and port of your HTTPS server

For your Android’s mobile apps, install Bluebox Heartbleed Scanner and run it, it will check for any vulnerable apps installed on your phone.

Resources

Solventando el desconcertante problema del clic izquierdo en Flash bajo Ubuntu 10.04

Introducción.

Este desconcertante problema me empezó a suceder desde que actualicé mis equipos a la versión 9.10 de GNU/Linux Ubuntu, debido a este bug las aplicaciones desarrolladas en Flash perciben correctamente los eventos del ratón con la excepción del clic izquierdo, haciendo imposible en la mayoría de los casos utilizar la aplicación.  Esto se puede apreciar muy bien en sitios como YouTube donde no es posible presionar el botón de Play para iniciar la reproducción del video.

Una “solución” parcial.

Hasta hace poco la única solución que le había encontrado a este problema tan molesto era el hacer un clic derecho sobre el botón o área que deseaba activar y con el menú contextual desplegado hacer un clic izquierdo sobre el mismo lugar.  Con esto y por alguna extraña razón Flash recibe exitosamente el evento del ratón.  Esta aproximación funciona bien pero después del tercer uso se hace terriblemente dispendiosa.

El problema.

Todo parece indicar que el problema surge debido a cambios importantes en el GDK (GIMP Drawing Kit) de la librería de gráficos GTK (The Gimp ToolKit) sobre la cual se ha desarrollado GNOME.  Con esta actualización, probablemente desde la versión 2.18, se ha implementado algo llamado client-side windows que hace que las ventanas GDK se comporten diferente en contravía de lo que se conocía anteriormente.  En ese órden de ideas, el plugin de Flash debería ser actualizado según los nuevos supuestos para permitirle funcionar con estas versiones nuevas de GTK.

El motivo del problema resultó ser el mismo que hace unos meses encontré utilizando Eclipse.

Las posibles soluciones.

Según el registro del bug 410407 en el LaunchPad de Ubuntu, existen tres posibles soluciones al problema, que no eliminan las causas por si mismos pero que las solventan y permiten utilizar normalmente las aplicaciones basadas en Flash.

  1. Deshabilitar Compiz.
  2. Remover los plugins instalados de Flash (como flashplugin-nonfree y flashplugin-installer)  e instalar los provistos directamente por Adobe.
  3. Manipular la variable GDK_NATIVE_WINDOWS para forzar a GDK crear ventanas X11.

En mi opinión, la solución mas práctica es la número 3.  Ya que con esta solución no se pierden los efectos del Compiz ni es necesario descargar e instalar nuevos paquetes.

Implementación de la solución #3.

Desde una terminal (shell) o la ventana de ejecución de programas (ALT+F2) invoque la siguiente instrucción (sin el símbolo $ por supuesto).

$ gksudo gedit /usr/lib/nspluginwrapper/i386/linux/npviewer

Agregue la siguiente línea justo antes de la última, es decir, está nueva línea deberá convertirse en la antepenúltima línea del script.

export GDK_NATIVE_WINDOWS=1

El contenido resultante de este archivo en mi máquina especificamente es el siguiente.

#!/bin/sh
TARGET_OS=linux
TARGET_ARCH=i386
export GDK_NATIVE_WINDOWS=1
. /usr/lib/nspluginwrapper/noarch/npviewer

Reinicie el equipo o al menos su entorno grafico para tener en cuenta este nuevo valor de configuración del GDK.

Enlaces.

Bug de IE – radiobutton olvidadizos al ser movidos entre el DOM

Esta semana tuve que invertir (perder) mi tiempo intentando entender y solucionar un comportamiento extraño de IE que resultó ser un bug que aparentemente existe en todas las versiones de este navegador y que fue solucionado según dicen en la versión 8 beta2.

A grandes razgos el problema sucede cuando se tiene una lista de radiobuttons (no sucede con otros componentes incluyendo el text o los checkboxes) y esta es trasladada entre el árbol DOM de la página, como por ejemplo cuando se mueve el formulario de un div a otro.  Cuando esto sucede, a IE se le olvida mágicamente cual era el radio seleccionado.

Para no volver a perder el tiempo con este error de IE hice una pequeña implementación de un formulario que reproduce las condiciones del error y le indica al usuario si el navegador utilizado padece o no del bug.

Inicialmente se tiene un formulario dentro del div seccion1 y otro div seccion2 vacío.

<div id='seccion1'>
    <form id='formulario' action='#' onSubmit='return procesarEnvio()'>

        <input type='radio' id='uno'    name='grupo' value='1' />
        <label for="uno">Primera opción.</label><br />
        <input type='radio' id='dos'    name='grupo' value='2' />
        <label for="dos">Segunda opción.</label><br />
        <input type='radio' id='tres'   name='grupo' value='3' />
        <label for="tres">Tercera opción.</label><br />
        <input type='radio' id='cuatro' name='grupo' value='4' />
        <label for="cuatro">Cuarta opción.</label><br />
        <input type='radio' id='cinco'  name='grupo' value='5' />
        <label for="cinco">Quinta opción.</label><br />

        <br />

        <input type='submit' value='Enviar' />

    </form>
</div>

<div id='seccion2'>
</div>

Cuando el usuario envía el formulario se obtiene el radio seleccionado.

        var seleccion1 = obtSeleccionValor('seccion1', 'formulario', 'grupo');

        alert("[1] El 'radiobutton' seleccionado es: " + seleccion1);

No hay problemas.  Para reproducir las condiciones del bug, se mueve, para este ejemplo con la ayuda de Prototype, al formulario de la seccion1 a la seccion2.

        var formulario = $$('#seccion1 #formulario').first();

        $('seccion2').insert(formulario);

Se vuelve a consultar cual es el radio seleccionado.

        var seleccion2 = obtSeleccionValor('seccion2', 'formulario', 'grupo');

        alert("[2] El 'radiobutton' seleccionado es: " + seleccion2);

Si seleccion1 == seleccion2 significa que se está utilizando un buen navegador, de lo contrario significa que se está utilizando un navegador ampliamente conocido por desconocer estándares y ser la pesadilla de los desarrolladores.

Desafortunadamente no encontré una solución elegante para este problema diferente de almacenar temporalmente cual es el radio seleccionado antes de realizar su movimiento en el DOM y actualizar su valor posteriormente.

Esto es práctico de hacer con Prototype.

        var formulario = $$('#' + secc + ' #' + form).first();

        var seleccion = formulario.getInputs('radio', grp).find(
            function(re)
            {
                return re.checked;
            });

Esta sección de código obtiene los radios del formulario form que se encuentran contenidos en el div secc, que pertenecen al grupo grp y que se encuentran seleccionados.  seleccion será undefined si ninguno de los radios se encuentra actualmente seleccionado.

        var seleccion = formulario.getInputs('radio', grp);

        if(seleccion[sel] != undefined)
              seleccion[sel].checked = true;

Esta sección corrige el valor seleccionado (sel) entre los radios (seleccion).  Dependiendo de la información contenida en los value y referenciada por sel, podrá ser una mejor opción recorrer la seleccion y realizar las comparaciones necesarias para activar (checked) al radio adecuado.

Utilice la aplicación demostración para verificar la presencia del bug en su navegador y para revisar con mayor precisión su código fuente.

Enlace: BugIERadioMovDom 0.1.