No teórico mumbo jumbo. ¿Alguna vez, alguien, de alguna manera, ha dado a conocer una vulnerabilidad real explotable debido al uso de / dev / urandom? ¿Una que se hubiera mitigado si hubieran usado / dev / random?
No teórico mumbo jumbo. ¿Alguna vez, alguien, de alguna manera, ha dado a conocer una vulnerabilidad real explotable debido al uso de / dev / urandom? ¿Una que se hubiera mitigado si hubieran usado / dev / random?
Sí, hay.
Una búsqueda rápida muestra CVE-2003-0094 por ejemplo:
Un parche para mcookie en el paquete util-linux para Mandrake Linux 8.2 y 9.0 usa / dev / urandom en lugar de / dev / random, lo que causa mcookie utilizar una fuente de entropía que sea más predecible de lo esperado, lo que puede facilitar que ciertos tipos de ataques tengan éxito.
Los problemas de uso de / dev / urandom en lugar de / dev / random pueden ocurrir durante la secuencia de arranque. En ese momento, es posible que el sistema no tenga suficiente entropía disponible para proporcionar números aleatorios seguros.
Concretamente, esta "entropía" designa el número de estados internos posibles para el generador de números pseudoaleatorios (PRNG):
Cuando se inicia la secuencia de inicio, el sistema se inicia desde un estado conocido, siempre igual (particularmente cierto para imágenes virtuales), y en su mayoría también en cualquier otro entorno idéntico.
A medida que el sistema procesa más y más "cosas" (I / O o lo que sea), el número de estados posibles también crece cada vez más.
Pero durante la secuencia de inicio, se están procesando relativamente pocas cosas y, sobre todo, son casi siempre las mismas y en cada entorno idéntico.
El CVE vinculado a los objetivos anteriores mcookie , lo que genera un secreto para la autenticación X. Pero lo mismo, por ejemplo, también se aplicaría a la generación automática de nuevas claves SSH en el primer arranque después de la instalación de un sistema o la implementación de una nueva máquina virtual.
Un atacante bien fundado podría ejecutar la secuencia de inicio inicial de su plantilla de VM decenas o cientos de miles de veces y recopilar las claves generadas cada vez. Como la combinación de formas en que un sistema recién instalado puede arrancar no es infinita, espero que en algún momento el atacante encuentre duplicados.
El atacante puede intentar reutilizar esas claves contra sistemas idénticos que todavía están usando la clave generada automáticamente en el momento de la instalación.
Si bien la secuencia de inicio posterior a la instalación es la más vulnerable, la mayoría de los sistemas (ahora?) almacenan un valor de inicialización en algún archivo que se utilizará al inicio del próximo reinicio. Este archivo no es nada especial, solo una secuencia de bytes aleatoria diseñada para romper cualquier determinismo potencial en los primeros estados de PRNG.
Por lo tanto, en la actualidad, aparte del material generado durante la fase posterior a la instalación, solo el código ejecutado antes de que se haya cargado el valor inicial podría mostrar una vulnerabilidad porque usó / dev / urandom en lugar de < em> / dev / random .
Lea otras preguntas en las etiquetas vulnerability random