¿Las protecciones de OpenBSD mitigan el daño causado por Heartbleed?

No.

OpenBSD tiene medidas (específicamente, páginas de guarda malloc () y borrado de la memoria desasignada) que debió haber convertido Heartbleed en un bloqueo o una fuga de un montón de bytes "0x0d". Sin embargo, como se indica en la publicación del blog aquí , OpenSSL utiliza su propio sistema de gestión de memoria personalizado que Actúa para derrotar esas medidas.

Parece haber algunos conceptos erróneos aquí acerca de cómo funciona la administración de memoria en OpenSSL.

OPENSSL_malloc y OPENSSL_free de forma predeterminada, simplemente llame al sistema malloc y gratis (hay algo de indirección, por lo que una aplicación puede redefinir estas funciones si lo desea, pero OpenSSL no hace eso por sí mismo). Sin embargo, para algunas estructuras de datos, en particular los buffers de entrada, mantiene algunos elementos previamente asignados pero no utilizados en una lista de distribución gratuita, sin liberarlos realmente. Debido a que no desinfecta el contenido del búfer después de su uso, si se toma un búfer de la lista gratuita y se reutiliza, es posible que el contenido anterior aún esté presente (incluso si el sistema gratuito lo hubiera borrado).

Sin embargo, dado que en la mayoría de los otros casos, OpenSSL está de hecho simplemente llamando al sistema malloc y libre, mitigaciones como páginas de guardia (que habrían hecho una lectura más allá del final del bloqueo del búfer de entrada de 16K) y borrar la memoria liberada (que habría detenido algunas de las grandes fugas de datos que la gente ha visto) habría ayudado, incluso con la gestión de memoria actual de OpenSSL. No habrían ayudado con la exposición de los contenidos del búfer de entrada anterior o con datos privados grandes que se encontraban en ubicaciones de pila válidas (sin autorización) (a menos que se usaran páginas de protección para evitar que se produjera la sobreimpresión).