¿Cómo pasó desapercibido Heartbleed durante tanto tiempo?

Corrígeme si me equivoco, estoy escribiendo esto en base a varias publicaciones que leí sobre Heartbleed. Por lo que entiendo, los softwares desarrollados en grandes empresas como Google, Facebook, etc. se someten a una gran cantidad de pruebas y garantía de calidad antes de ser enviados finalmente. Poseen departamentos separados para analizar cada posible violación de seguridad y se les paga millones por eso.

Ahora llegando al punto de OpenSSL donde ocurrió la violación de seguridad de Heartbleed. El código público está disponible aquí: openssl / openssl
Algunas personas pueden plantear una inquietud común y lanzar una guerra contra el código abierto frente al código cerrado y culpar a la “apertura” del código como la causa principal de la violación en primer lugar. Entonces, ¿eso significa que todos los softwares de código abierto son inherentemente inseguros que los de código cerrado? Pues NO!

Un argumento muy bueno que escuché a favor del código abierto es que “en teoría, esto lo hace (código abierto) más seguro: con suficientes programadores que verifican el código, las fallas se pueden identificar rápidamente”. El hecho sigue siendo que el código inseguro no es un debate de código abierto versus de código cerrado.

La respuesta está en mirar el error en sí mismo. El problema es bastante simple: una pequeña brecha: una simple verificación de límites faltantes en el código que maneja los mensajes de ‘latido’ de TLS. Al abusar de este mecanismo, el pirata informático puede solicitar al servidor TLS que entregue 64 KB de espacio de memoria privada. Permite al pirata informático obtener acceso a las claves privadas del servidor a largo plazo y descifrar las sesiones pasadas.

Si hubiera pasado por pruebas rigurosas antes, se podría haber descubierto la falla simple, pero de alguna manera se pasó por alto. Según el investigador de seguridad Matthew Green “Simplemente no había suficientes ojos en esto, y eso es muy malo”.

Pero bueno, ¿qué tal si las compañías como Google, Facebook, Amazon usan OpenSSL, no podrían sus departamentos de pruebas altamente pagados detectar esta simple violación?
Bueno, sí pudieron y de hecho lo hicieron (Neel Mehta de Google fue el descubridor original). Pero nuevamente OpenSSL no es su producto. Su primera prioridad es probar sus propios servicios y luego tal vez … Bueno, ¡más vale tarde que nunca!

Green dijo: “Si pudiéramos devolver $ 500,000 a OpenSSL y a equipos como este, tal vez este tipo de cosas no vuelva a suceder”. Y eso es exactamente lo que hacen las grandes organizaciones. Es precisamente por eso que las pruebas son una parte crucial del desarrollo de software.

La organización que descubrió el error (independientemente de Google), Codenomicon, utiliza programas impulsados ​​por OpenSSL para asegurar su información, por lo que la compañía apuntó a su propia infraestructura. Entonces, quién sabe, algún defecto o error desconocido podría estar abierto en este momento para los atacantes. Depende totalmente de la cantidad de pruebas y control de calidad que haya detrás del lanzamiento. Así que hagamos de la Web un lugar más seguro e intentemos ser más activos en el desarrollo de código abierto. 🙂

Lee mas:
Insecto sangrante

EDITAR

Más del autor original de Heartbleed: El programador detrás de Heartbleed habla: fue un accidente

OpenSSL es un código complicado, y es un código antiguo (como va el código), y ha sido portado a muchos sistemas. Esto hace que sea extraordinariamente difícil de probar. Solo hay unas pocas personas que entienden lo suficiente de lo sutil que podría mejorarlo, y hay un código feo para calzarlo en sistemas que ya no se usan.

Una vez que un grupo de personas que sabían lo suficiente sobre cómo funcionaba finalmente comenzó a desgarrar todo el código buscando limpiarlo para un uso moderno, encontraron muchos más problemas. Ver

OpenSSL Valhalla Rampage

para una cuenta muy entretenida del proceso de depuración. “Destrozando OpenSSL, un hack arcano VMS a la vez”.

Este documento también es útil.

LibreSSL: más de 30 días después