HPE entre los líderes de almacenamiento de Gartner
El fiasco de Heartbleed de OpenSSL demuestra sin lugar a dudas lo que muchos han sospechado durante mucho tiempo: El hecho de que el código de fuente abierta esté disponible para su inspección, no quiere decir que en realidad esté siendo inspeccionado y sea seguro.
Es un punto importante, ya que la seguridad del software de código abierto se basa en un gran número de programadores bien informados que escudriñan el código para erradicar y corregir los errores rápidamente. Esto se resume en laley de Linus: “Con suficientes ojos, todos los errores son superficiales”.
Pero fíjese en lo que pasó con OpenSSL. Robin Seggelemann, un programador alemán de la Universidad de Munster, actualiza el código OpenSLL añadiendo una nueva función de mantenimiento de conexión ‘Heartbeat’. Por desgracia, perdió una validación necesaria en su código para comprobar que una variable en particular tuviera un valor realista. Al miembro del equipo de desarrollo de OpenSSL, que protegió el código antes de que se publicara la actualización, también se le perdió. Eso causó el error Heartbleed.
Un crítico, incluso un puñado de críticos, puede olvidar fácilmente una falla como ésta si no saben que hay un error encontrar. Lo que es preocupante es que, durante dos años, existió el error Heartbleed en OpenSLL, en los navegadores y servidores web, sin embargo, nadie en la comunidad de código abierto lo descubrió. No fueron suficientes los ojos que examinaron el código.
Los proveedores comerciales no revisan el código abierto
También es alarmante que OpenSSL fuera utilizado como componente en productos de hardware ofrecidos por los proveedores comerciales tales como F5 Networks, Citrix Systems, Riverbed Technology y Barracuda Networks; los cuales no pudieron examinar el código de manera adecuada antes de usarlo, de acuerdo con Mamoon Yunus, CEO de Forum Systems, un proveedor de puerta de enlace segura para la nube.
“Se podría pensar que era mi responsabilidad como proveedor, si yo comercializo OpenSSLl”, señala. “Usted tiene que tener un nivel de apropiación del código si construye una empresa basada en un componente de código abierto”.
En su lugar, Yunus cree que los proveedores solo consideran a OpenSSL como un ‘bolt-on’ útil para sus productos de hardware -y, puesto que era de código abierto, se supone que otras personas estarían examinando el código. “Todo el mundo asumió que otros globos oculares estaban mirando. Tomaron la actitud de decir que fijarse en el código era responsabilidad de un millón de otras personas, así que no era culpa de ellos”, añade. “Ahí es donde aparece la negligencia desde un ángulo del código abierto”.
Yunus sugiere que los proveedores comerciales deben ejecutar programas eficaces de revisión de pares para cualquier código de fuente abierta que utilicen, ejecutar herramientas de análisis estático y dinámico sobre él y “difuminar” el código para asegurarse de que está lo más libre de errores como sea posible. “¿Qué han estado haciendo estas empresas en los últimos 10 o 15 años? Si yo fuera ellos, estaría tomando una larga y dura mirada a los procesos de control de calidad”.
Incluso, Yunus se pregunta si OpenSSL debió ser escrito en un lenguaje de un relativo bajo nivel como C, haciendo eco del experto en seguridad Bruce Schneier, que sugiere que esto podría ser visto como “negligencia criminal”: usar un lenguaje que carece de gestión de la memoria en una aplicación sensible como la seguridad.
Jeffrey Hammond, analista de seguridad de Forrester Research, contradice esta opinión. Señala que el rendimiento es un atributo clave de OpenSSL, ya que tiene que lidiar con grandes volúmenes de paquetes. “Si tiene acceso a la memoria va a estar abierto a algunos ataques, pero obtiene el rendimiento que desea”, señala Hammond. “Yo no diría que nunca se debió desarrollar OpenSSL en C, pero es cierto que con el rendimiento viene la responsabilidad”.
OpenSSL y TrueCrypt muestran los límites de la revisión del código abierto
Uno de los problemas que enfrentan muchos proyectos de código abierto -y la razón por la que es difícil culpar a Seggelemann o el resto del equipo OpenSSL- es que realizar un examen riguroso de código de seguridad consume mucho tiempo y requiere un alto nivel de habilidad. Eso significa que es muy caro.
Esto se ilustra por otro proyecto de código abierto: El programa de cifrado TrueCrypt. El código es abierto para cualquier persona interesada desde que comenzó el proyecto hace 10 años – pero es solo muy recientemente, a raíz de las campañas de recaudación de fondos en Indiegogo y Fundfill que inyectaron 60 mil dólares, que el código ha sido objeto de una auditoría adecuada de seguridad.
Un reporte inicial, sobre solo el controlador del núcleo de Windows y el gestor de arranque en el programa identificó 11 vulnerabilidades, indicó que la calidad del código fuente era mala y señaló que la compilación de la fuente de TrueCrypt requiere el uso de herramientas de construcción anticuadas (en algunos casos con 21 años de edad) y sin formas que podrían ser modificadas maliciosamente y que son difíciles de acceder desde fuentes confiables.
Los auditores del código señalaron: “En general, el código fuente tanto para el gestor de arranque y el controlador del núcleo de Windows no cumplieron las normas previstas para un código seguro”.
Lo que es preocupante es que esto solo salió a la luz después de que se elevaron los costos para contratar los recursos con el fin de llevar a cabo una revisión de código. La comunidad de código abierto tuvo muchas oportunidades de hacer esto durante los últimos 10 años -pero la verdad es que la comunidad no tiene el tiempo, las habilidades o los recursos (incluyendo dinero) para hacer el trabajo correctamente.
Un nuevo problema afectará a la seguridad de OpenSSL en el futuro: El código está siendo bifurcado, gracias a una iniciativa llamada LibreSSL dirigida por el equipo OpenBSD. LibreSSL pretende ser una versión simplificada de OpenSSL; en la primera semana del proyecto se eliminaron más de 90 mil líneas de código, incluyendo los sistemas operativos de apoyo como VMS y OS/2.
El problema es simple: Ya que es fácil ver lo que está siendo retirado de LibreSSL, y qué bits están siendo reemplazados a medida que se consideran inseguros, los usuarios de OpenSSL quedan expuestos a los hackers maliciosos que pueden explotar las debilidades que LibreSSL descubre y elimina -a menos que el proyecto OpenSSL pueda mantenerse al día con el progreso de LibreSSL.
La seguridad por oscuridad nunca es una buena idea, pero una vez que las vulnerabilidades se hacen públicas, tienen que arreglarse de inmediato. No está claro si el equipo de OpenSSL está en condiciones de hacer eso -se dice que el proyecto tenía solo a una persona de mantenimiento a tiempo completo- o que el software y hardware que utilizan OpenSSL necesariamente serán actualizados puntualmente, incluso si el software OpenSSL en sí lo está.
Tomando en serio la seguridad del código abierto después de Heardbleed
La buena noticia para quienes se preocupan por la seguridad de los proyectos de código abierto como OpenSSL es que la ayuda podría estar en camino en forma de la Iniciativa de la infraestructura principal (CII por sus siglas en inglés), un nuevo proyecto fundado por la Fundación Linux en respuesta a Heartbleed. Su objetivo es canalizar el dinero necesario para los proyectos de software como OpenSSL, que son críticos para el funcionamiento de Internet.
“Nuestra economía global está construida en la cima de muchos proyectos de código abierto”, señala Jim Zemlin, director ejecutivo de la Fundación Linux. “Ahora vamos a ser capaces de apoyar a los desarrolladores y mantenedores adicionales para trabajar a tiempo completo en el soporte a otros proyectos esenciales de código abierto”.
El apoyo de la CII también puede incluir el financiamiento de auditorías de seguridad, la informática y la infraestructura de prueba. Hasta el momento, se han comprometido cerca de cuatro millones de dólares durante los próximos tres años por empresas como Google, Microsoft y Facebook.
Paul Rubens, CIO (EE.UU.)
