¿Cuáles son las implicaciones de seguridad de un tiempo de ejecución de Java fuera de soporte?

2

¿Cuáles son las posibles implicaciones de seguridad de dejar la versión de enero de 2019 del tiempo de ejecución de Java 8 de Oracle instalada de forma indefinida?

Para el contexto, tenemos el tiempo de ejecución de Oracle Java 8 ampliamente implementado, pero después de enero, las actualizaciones solo estarán disponibles para usuarios domésticos o mediante un contrato comercial, a precios que no podemos permitirnos. Esto se realiza en un entorno académico, y debido a la gran cantidad de aplicaciones de Windows (más de diez mil) cualquiera de las cuales puede tener una dependencia conocida o desconocida de Java, cambiarse a una distribución alternativa como el tiempo de ejecución AdoptOpenJDK será difícil y parece Es poco probable que se complete pronto.

Para ayudarnos a establecer prioridades, me gustaría tener una idea del tipo de riesgos a los que nos enfrentamos aquí y de los pasos que podríamos tomar para mitigarlos.

Mi investigación hasta ahora sugiere:

  • Los applets de Java ahora están deshabilitados en Firefox y Chrome, y deberíamos poder usar políticas de grupo u otras herramientas para deshabilitarlos también en Internet Explorer. (Para empezar, ¿son comunes los ataques basados en applet? ¿O es probable que se vuelvan más comunes el próximo año?)

  • Los navegadores no ejecutarán las aplicaciones Java Web Start sin el permiso explícito del usuario, por lo que incluso si se rompe el entorno limitado por una vulnerabilidad recién descubierta, esto no es más peligroso que un usuario que descargue y ejecute una aplicación convencional. / p>

  • Las aplicaciones Java de escritorio, por ejemplo, los archivos .jar , no se encuentran en un espacio aislado de todos modos, por lo que las vulnerabilidades de seguridad en el tiempo de ejecución no deberían importar a menos que den como resultado vulnerabilidades en la aplicación. Eso significa que tendremos que hacer algo con la cantidad (relativamente pequeña) de máquinas que ejecutamos Tomcat, pero eso debería funcionar perfectamente en cualquier distribución de Java, y la mayoría de las demás aplicaciones de Java no deberían estar expuestas directamente al ataque.

Así que, en general, la situación no parece tan mala como parecía. Pero tal vez estoy pasando por alto algo? ¿A qué otros riesgos nos enfrentamos?

    
pregunta Harry Johnston 05.12.2018 - 23:22
fuente

1 respuesta

2

La gestión de riesgos consiste en dar sentido a una inversión de $ para protegerla de perder más dinero. Los ataques basados en applet ocurren, pero son cada vez menos comunes. Dicho esto, si su organización está dirigida, pueden optar por usar estos ataques simplemente porque pueden saber que usted todavía está usando esta versión.

Aparte de eso, tu evaluación es bastante precisa. Para priorizar personalmente, probablemente intentaría identificar aplicaciones que dependen de su Java Runtime obsoleto pero que se ejecutan con diferentes privilegios (por ejemplo, privilegios más elevados) o que están conectados a la red. Estas aplicaciones probablemente serían más expuestas e interesantes para un atacante.

También supervisaría de forma activa si se están publicando vulnerabilidades para el JRE8 mientras tanto.

    
respondido por el Lucas Kauffman 06.12.2018 - 07:22
fuente

Lea otras preguntas en las etiquetas