Es compatible con versiones anteriores de Java peligrosas

2

Tenemos una biblioteca de códigos que es utilizada por los desarrolladores y requiere el uso de Java 1.8. Sin embargo, ha habido solicitudes de soporte 1.7 y sería trivial hacerlo.

La biblioteca es básicamente un contenedor de Java para una herramienta CLI .NET, por lo que no existe una necesidad real de seguridad fuera del ejecutable .NET al que se llama.

Tengo un par de preguntas sobre los problemas de seguridad con Java:

  1. ¿Existe algún riesgo de seguridad con la instalación de Java 1.7 JDK en nuestra máquina de compilación si todo lo que se usa es para compilar el archivo jar?

  2. ¿Ejecutar nuestra biblioteca (que usa 1.7) crea riesgos de seguridad si se usa en un programa que se está compilando con Java 1.8 (o la última versión), o si mitiga los riesgos de seguridad en lugar de los parches de seguridad de versiones posteriores de Java?

  3. ¿Hay algún problema de seguridad importante con el soporte de Java 1.7 cuando se usa como un contenedor para una herramienta CLI?

pregunta yitzih 01.02.2018 - 20:46
fuente

1 respuesta

5
  

¿Existe algún riesgo de seguridad relacionado con la instalación de Java 1.7 JDK en nuestra máquina de compilación si todo lo que se usa es para compilar el archivo jar?

Probablemente no, pero no hay necesidad de hacer eso: javac proporciona el indicador -target , que le permite generar archivos de clase compatibles con cualquier versión (siempre que no utilice las funciones de origen o los métodos de biblioteca de llamadas que no eran compatibles con esa versión).

  

¿Existe algún problema de seguridad importante con el soporte de Java 1.7 cuando se está utilizando como un contenedor para una herramienta CLI?

Probablemente no. Las preocupaciones de seguridad con Java generalmente involucran problemas de implementación en la JVM (Máquina Virtual de Java) o las bibliotecas que utiliza. También hay algunos problemas con las bibliotecas de terceros que permiten comportamientos explotables (por ejemplo, Apache Commons Collections que admiten una implementación Map que podría ejecutar código arbitrario).

Si simplemente está compilando el mismo código para diferentes arquitecturas de destino (1.7 en comparación con 1.8), está casi garantizado que obtendrá la misma salida de código de bytes. Puede comparar el bytecode generado para cada versión con el programa javap .

  

¿La ejecución de nuestra biblioteca (que usa 1.7) crea riesgos de seguridad si se está utilizando en un programa que se está compilando con Java 1.8 (o la última versión), o mitiga los riesgos de seguridad e implementa parches de seguridad de versiones posteriores de Java?

No puedo entender la pregunta que estás haciendo, así que responderé a la pregunta que creo que estás haciendo: si ejecutas una clase compilada compatible con 1.7 en una JVM 1.8 actualizada, entonces usted recibe todos los beneficios de seguridad de esa JVM. Si se ejecuta en una JVM 1.7 o una JVM 1.8 más antigua, está sujeto a las fallas de seguridad presentes en esa máquina virtual.

Tenga en cuenta que muchas bibliotecas de código abierto están dirigidas a 1.6 e incluso 1.5. La única razón real para apuntar a una versión más nueva es si utiliza funciones de idioma (por ejemplo, Lambdas) o funciones de biblioteca que no estaban disponibles en la versión anterior. En ese caso, elegir la versión de destino mínima necesaria evitará que una instalación anterior se compile con la clase, porque cada versión de Java usa una versión de archivo de clase diferente y los compiladores más antiguos no aceptarán archivos más nuevos.

    
respondido por el guest 01.02.2018 - 21:13
fuente

Lea otras preguntas en las etiquetas