prácticamente el título, cómo saber si la vulnerabilidad de Heartbleed (para OpenSSL) afecta a otras bibliotecas como SSLStream o BouncyCastle de .NET.
(Perdón por la ignorancia, pero no he encontrado información sobre cómo explotar, para ver si está relacionada con bufferoverruns y otras cosas que no deberían suceder en Java / .NET).
El llamado exploit "heartbleed" es una saturación del búfer. Una saturación de lectura , para ser específico: el sistema atacado es inducido a leer y enviar bytes desde un búfer que es mucho más corto que la longitud de lectura, por lo tanto, la lectura de los bytes que residen en la RAM más allá del búfer. Dado que los bytes se envían de vuelta al interlocutor, esto da una ventana para mirar dentro de la RAM del sistema de destino.
Es poco probable que alguna otra implementación de SSL comparta el mismo error exacto. Es plausible que otras bibliotecas SSL tengan sobrecargas de búfer de algún tipo (nadie sabe realmente cómo escribir código libre de errores), pero no exactamente ese. O, dicho de otro modo, si otra implementación de SSL tiene el mismo error relacionado con el latido del corazón, entonces probablemente sea un spin-off de OpenSSL.
Además, para las implementaciones escritas en un idioma en el que los accesos de la matriz se verifican sistemáticamente en busca de límites (generalmente Java o C # o Python o Scheme o OCaml o casi cualquier idioma que no sea muy bajo como C), el Las consecuencias de un exceso de búfer son diferentes y, por lo general, son preferibles: en lugar de leer los bytes adicionales y enviarlos de vuelta, el código infractor atrapa, lo que genera una excepción que implica la terminación del subproceso o proceso o conexión. El error todavía está allí, no la hazaña de gran alcance; la fuga de datos secretos se ha convertido en un potencial de denegación de servicio básico, que a menudo se limitará a cerrar la conexión afectada, por lo que no se niega mucho el servicio, después de todo.
Lea otras preguntas en las etiquetas heartbleed