Pero para finales de junio, apenas dos meses después, los esfuerzos por poner un parche contra Heartbleed en los servidores de inte et se había estancado, con más de 300.000 aún en inte et. OpenSSL, el proyecto de código abierto en cuyo software se encontró el defecto, afirma que aún no tiene los recursos suficientes para mantener el código seguro. Es más, nuevas investigaciones sugieren que las circunstancias que convirtieron a Heartbleed en un problema a gran escala, son de lo más común.
Kymberlee Price, de la empresa de seguridad Synack y Jake Kouns, director ejecutivo de la organización sin ánimo de lucro Open Security Foundation, presentaron los resultados de una encuesta sobre el uso y la seguridad de las bibliotecas de código abierto el jueves pasado en la conferencia Black Hat celebrada en Las Vegas (EEUU). Destacaron varias bibliotecas de código abierto que se usan muchísimo pero cuya seguridad es dudosa. Un fallo en una de estas bibliotecas podría tener un impacto parecido al que tantos titulares acaparó en abril. "Sin ninguna duda podría volver a pasar con cualquier biblioteca de terceros", declaró Price a MIT Technology Review en la conferencia.
"Lo que llama la atención es que determinados programas o productos que hay en el mercado pueden incluir cientos de estas bibliotecas", explica Kouns. "Ahora todos están expuestos a este riesgo sistémico".
Una de las bibliotecas identificadas por Price y Kouns como un problema potencial es la fuente de Heartbleed, OpenSSL. Desde que se descubrió Heartbleed ya se han encontrado varios fallos más en OpenSSL, algunos de los cuales pueden ser más peligrosos, según Kouns.
Y cabría esperar que se hicieran esfuerzos mayores. A pesar de la publicidad conseguida por Heartbleed, OpenSSL aún no tiene dinero suficiente para enfrentarse a estos problemas. Después del incidente el proyecto llevó a cabo un examen y calculó que necesitaba seis desarrolladores a tiempo completo para poder mantener el software adecuadamente. El dinero puesto por IBM, HP, Google y otras grandes empresas tecnológicas tras el fallo sólo sirve para pagar a dos desarrolladores a tiempo completo. "Incluso algo así, que es como si te lo pidiera tu madre a la hora de cenar, no está recibiendo el apoyo necesario", afirma Price.
Otra biblioteca potencialmente problemática es FreeType, que se usa para ver distintos tipos de letra y se incluye en más de mil millones de dispositivos fabricados por empresas como Apple, Google y Sony. Kouns y Price han contabilizado más de 50 vulnerabilidades en FreeType a lo largo de los siete últimos años. Una de ellas formó la base de un ataque denominado “Jailbreakme” que permitía hacerse con un iPhone a distancia (ver "¿Tiene un iPhone? Ya existe una aplicación para piratearlo").
Otras bibliotecas de código abierto destacadas por esta pareja de investigadores incluyen LibPNG, que se usa en cientos de dispositivos y software de uso común para mostrar imágenes, y FFMpeg, de la que Apple, Google, Microsoft y Sony dependen para reproducir vídeo.
La mayoría de estas bibliotecas de uso generalizado se actualizan múltiples veces al año, incluyendo arreglos de seguridad, explica Price. Pero a los ingenieros de software de las empresas no les resulta fácil mantenerse al día de todas las actualizaciones, ni de qué versiones de qué bibliotecas está usando su empresa. Y pocas empresas aplican todas las actualizaciones de todas las bibliotecas en cuanto salen, sostiene Price. Lo habitual es que las empresas actualicen las bibliotecas sólo cuando lanzan una nueva versión de su propio producto. "Si sólo estás actualizando cuando haces un lanzamiento, probablemente estés pasando por alto algunas vulnerabilidades importantes", afirma.
Hay expertos que creen que las empresas de software deberían ser responsables legales de los problemas de seguridad generados por sus productos. Una opción de la que han hablado los ejecutivos en BlackHat es que los inversores tengan la potestad de pedir auditorías a terceros del código de una empresa, ampliando un proceso de auditoría que ya es una parte estándar en el caso de las fusiones y adquisiciones, explica Price.
El director de Seguridad de la Información de In-Q-Tel, el fondo de inversiones de la CIA, Dan Geer, hizo una sugerencia más radical en su conferencia del miércoles. Pidió legislación que hiciera responsables a las empresas de software de los daños producidos por problemas de seguridad en sus productos.
"Los únicos dos productos que no están cubiertos por responsabilidades son la religión y el software, y el software no debería librarse mucho más", afirmó Geer. Sugirió que las empresas de software sean responsables de todos los daños ocurridos debido a fallos en su software; y que las que permitan la inspección de todo su código fuente sólo estén obligadas a la devolución del dinero por el producto en caso de daños.
Esta propuesta se enfrentará a una fuerte oposición dentro de la industria del software y es poco probable que cuaje. Price afirma que la solución más práctica, aunque parcial, es hacer consciente a la gente del riesgo que suponen las bibliotecas de terceros y crear herramientas que faciliten la notificación de los últimos fallos y la actualización de los paquetes. "No podemos eliminar el riesgo, así que habrá que gestionarlo", sostiene.