kali - java ubuntu

Oracle Java 8 x64 para Linux y RandomSource

Question

Realmente pensé que después de unas 200 o más instalaciones de tomcat en varias plataformas, estoy preparado para cualquier tipo de desafío, pero este es complicado.

Creé una imagen de vainilla Ubunutu 14_04 e instalé Java 8 TGZ de oracle en ese sistema. Además agregué un tomcat 8 al juego. Entonces empecé la instalación del servidor de vainilla.

Poco después de colgar en la implementación de las aplicaciones predeterminadas que se enviaron con Tomcat, me pregunté qué pasaría allí e hice algunas subprocesos. Este fue el hilo malo que impidió que Tomcat comenzara:

"localhost-startStop-1" #15 daemon prio=5 os_prio=0 tid=0x00007f37c8004800 nid=0x4d6 runnable [0x00007f37b38b3000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:246)
at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
at sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:192)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:210)
- locked <0x00000000f06e6ce8> (a sun.security.provider.SecureRandom)
at java.security.SecureRandom.nextBytes(SecureRandom.java:457)
- locked <0x00000000f06e71c0> (a java.security.SecureRandom)
at java.security.SecureRandom.next(SecureRandom.java:480)
at java.util.Random.nextInt(Random.java:329)
at org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:234)

Después de más google y amigos, descubrí que el SeedGenerator suministrado con el JDK es la fuente de mi problema. Interesantemente, a veces el SeedGenerator regresó después de varios minutos y otras simplemente se colgó (¿se está quedando sin entropía? ... revisado a través de cat /proc/sys/kernel/random/entropy_avail ). Después de más investigaciones, descubrí que una variable de configuración en $JAVA_HOME$/lib/security/java.security llamada securerandom.source define cuál es la fuente de Random. En mi caso, o mejor en la instalación de Oracle JDK 8 para Linux, fue /dev/random . No soy un experto en Linux (soy un desarrollador de Java) pero lo que entendí es que /dev/random puede quedarse sin entropía (lo que sea que esto signifique) pero quizás en algún punto no pueda generar más números aleatorios). Cambié a /dev/urandom y todo estaba bien con mi gato.

Luego verifiqué cómo se ven otras instalaciones de JDK en mi otro servidor, que era una mezcla salvaje de OpenJDK y las instalaciones de Oracle JDK anteriores. Al menos OpenJDK siempre usó /dev/urandom lo que podría ser la respuesta, por qué nunca antes había tenido el problema.

Ahora a mi pregunta : ¿Es lógico de Oracle confiar en /dev/random cuando puede haber casos de esquina donde el sistema operativo no puede producir más números? Me refiero a servidores como Tomcat y muchos otros que se basan en SeedGenerator del JDK y la depuración de este tipo de error es realmente avanzada. Me tomó 2 horas llegar al punto donde estoy ahora.

Answer 1

lo que entendí es que / dev / random puede quedarse sin entropía (sea lo que sea lo que esto signifique) pero quizás en algún momento no pueda generar más números aleatorios).

Puede quedarse temporalmente sin entropía y bloquear hasta que se acumule lo suficiente para dispensar más. La JVM solo necesita un poco para SecureRandom una instancia de SecureRandom .

El tiempo que demora depende de lo ruidoso que sea su sistema y de cómo el kernel acumula entropía.

¿Es lógico que Oracle confíe en / dev / random cuando puede haber casos de esquina donde el sistema operativo no puede producir más números?

La falta de entropía puede ser problemática en sistemas embebidos o en máquinas virtuales en el primer arranque que vienen con una imagen muy determinista, tienen pocas fuentes de entropía que pueden ser cosechadas en comparación con las PC reales y no tienen instrucciones RDRAND o similares para que el núcleo pueda cosechar para la entropía Inicialización del pool.

La aleatoriedad insuficiente puede ser catastrófica para la generación de claves y otros algoritmos criptográficos, por ejemplo, DSA es bastante sensible a la calidad de su fuente de entropía .

Entonces sí, es bastante sensato esperar que tener un sistema comprometido.

Cita de Mining Your Ps and Qs: Detección de claves débiles generalizadas en dispositivos de red por N.Heninger et al.

Para comprender por qué ocurren estos problemas, investigamos manualmente cientos de hosts vulnerables, que eran representativos de las claves más repetidas y de cada una de las claves privadas que obtuvimos (Sección 3.2). Casi toda la información servida que los identifica como sistemas sin cabeza o integrados, incluidos enrutadores, tarjetas de administración de servidor, firewalls y otros dispositivos de red. Estos dispositivos generalmente generan claves automáticamente en el primer arranque, y pueden tener fuentes de entropía limitadas en comparación con las PC tradicionales.

Además, cuando examinamos grupos de hosts que compartían una clave o un factor, en casi todos los casos parecían estar vinculados por un fabricante o modelo de dispositivo. Estas observaciones nos llevan a concluir que los problemas son causados ​​por implementaciones defectuosas específicas que generan claves sin haber acumulado suficiente entropía.

Si tiene una fuente externa de entropía y privilegios de raíz, puede insertar entropía adicional en el grupo e incrementar su contador (creo que rngd puede hacer esto por usted). Simplemente escribiendo a /dev/random agregará su entropía al grupo pero no aumentará el contador.

Para las máquinas virtuales, también hay controladores de virtualización para obtener la entropía del host.

Señalar a jvm a un hardware RNG dev (/ dev / hwrng, / dev / misc / hw_random o algo así) también puede ser una opción, si están disponibles.

Answer 2

Creo que la respuesta se basa en este enlace para el soporte de WebLogic: https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html donde mencionan que "al azar" es más seguro

y también en el comentario de error de Oracle (ya mencionado por David): http://bugs.java.com/view_bug.do?bug_id=4705093

con especial atención a esta parte:

Debido a que SHA1PRNG es un PRNG basado en MessageDigest, históricamente siempre ha usado / dev / random para la siembra inicial si la aplicación no ha proporcionado datos de semilla. Dado que todos los valores futuros dependen del estado existente del MessageDigest, es importante comenzar con una semilla inicial fuerte.

Cambiar ese comportamiento era preocupante para el desarrollador original. Así que creó un nuevo implemento de SecureRandom llamado NativePRNG, que respeta el valor java.security.egd.

Si llamas:

• nuevo SecureRandom () en Linux y se usan los valores predeterminados, se leerá desde / dev / urandom y no se bloqueará. (De forma predeterminada en Solaris, se usa PKCS11 SecureRandom y también se llama a / dev / urandom).

• SecureRandom.getInstance ("SHA1PRNG") y no especifique una semilla, O el nuevo SecureRandom (), pero ha especificado una java.security.egd alternativa además de "file: / dev / urandom", utilizará el SHA1PRNG que llama a / dev / aleatorio y potencialmente puede bloquear.

• SecureRandom.getInstance ("NativePRNG"), dependerá de lo que apunte java.security.egd.