OpenSSL es la implementación de protoclos de seguridad SSL/TLS más famosa y usada. Los mencionados protocolos son los que se usan para encriptar información en internet. Y se usan en, por ejemplo, https (el candadito en la url), ftps, ssh, etc.
La idea de usar esta encriptación, es por ejemplo en https (lo más usado por los usuarios entre los mencionados anteriormente), que nadie pueda leer la información entre tú y la página web. De esta manera puedes pasar una contraseña a la página web y estar seguro que nadie podrá leerla y saber cuál es haciendo un análisis de tráfico web (o sea por ejemplo alguien espiando tu internet, como puede incluso ser gente de los proveedores de internet o la policía que analice tu tráfico).
Para compartir tráfico encriptado entre usuario y servidor, hay que iniciar una sesión TLS entre ambos, tras lo cual se comparten de manera segura la clave que usarán para cifrar y descifrar los mensajes. Ahora, el problema en SSLv2 y anteriores, es que si pasaba cierto tiempo desde que se inició la sesión tls y no habían paquetes entre las partes, la sesión TLS se cerraba, teniendo que inicarla nuevamente, creando las claves y todo eso, lo cual era tiempo y gasto computacional. Eso se mejoró con la versión 3 de SSL, que implementa un sistema llamado "heartbeat" (latido del corazón, como para avisar que aún sigues vivo), con el cual podías mantener abierta una sesión TLS más tiempo.
Para ello, el cliente manda un mensaje de tipo "TLS1_HB_REQUEST", con dos campos: El payload (el mensaje), y el tamaño del payload. Luego el servidor le manda otro mensaje de vuelta llamado "TLS1_HB_RESPONSE" que copia el payload y lo manda de vuelta, para 'configurar' la respuesta. Los campos del mensaje response del servidor incluyen el mismo payload y el mismo largo.
El truco viene en que OpenSSL no comprueba que el payload tenga el mismo largo que el que se mandó en el campo "largo". Esto hace que OpenSSL "crea ciégamente" que el payload tiene ese largo (sin comprobarlo), y envía de vuelta lo que debiera ser el payload. Pero el truco consiste en mandar un payload de 1 byte, y un campo "largo" diciendo que nuestro payload mide 64KB, es decir varios miles de veces más. Lo que hará OpenSSL será empezar copiando desde el payload, hasta 64KB más adelante de lo que haya en la memoria ram (el payload reside en la ram, entonces copia desde el comienzo del payload hasta 64kilo bytes más adelante, haya lo que haya), copiando así trozos de memoria ram pertenecientes a OpenSSL que no eran parte del payload, sino de trozos de código y datos del mismo OpenSSL.
El problema es que OpenSSL contiene contraseñas, las claves de cifrado, y muchas otras cosas sensibles; de manera que mandando continuamente mensajes truqueados, obtendremos cada vez 64kb de memoria de trozos aleatorios del programa, pudiendo obtener potencialmente gigas y gigas de trozos, que incluyen contraseñas, claves, etc.
Dejo un mono explicativo:
Este fallo se reportó varios años antes, pero no ha sido sino hasta el reciente 7 de abril 2014 que se ha publicado el parche para que no siga ocurriendo. Hasta que las páginas no actualicen su versión de OpenSSL seguirá ocurriendo el problema, y los servidores serán potenciales víctimas de ataques. Eso sí, esto sólo roba las contraseñas que están en la memoria RAM, es decir sólo los ingresos recientes, o activos, así que la recomendación sería no ingresar hasta que sea reportado el que actualizaron el software y repararon el problema.
Fuentes:
Blog de Chema alonso, un experto en seguridad http://www.elladodelmal.com/2014/04/heartbleed-y-el-caos-de-seguridad-en.html
Video explicativo en inglés del fallo, con monitos http://parkerati.com/my-quick-video-post/
