Supporta la versione precedente di Java pericolosa

2

Abbiamo una libreria di codici che viene utilizzata dagli sviluppatori e richiede l'utilizzo di Java 1.8. Tuttavia, ci sono state richieste per supportare 1.7 e sarebbe banale farlo.

La libreria è fondamentalmente un wrapper Java per uno strumento CLI .NET, quindi non c'è bisogno di sicurezza al di fuori dell'eseguibile .NET chiamato.

Ho un paio di domande sui problemi di sicurezza con Java:

  1. C'è un rischio per la sicurezza di avere il JDK Java 1.7 installato sul nostro computer di compilazione se tutto ciò che viene usato è per compilare il file jar?

  2. L'esecuzione della nostra libreria (che utilizza 1.7) crea rischi per la sicurezza se viene utilizzata in un programma che viene compilato con Java 1.8 (o l'ultima versione), oppure attenua i rischi per la sicurezza e sul posto le patch di sicurezza delle versioni successive di Java?

  3. Esistono problemi di sicurezza importanti con il supporto di Java 1.7 quando viene utilizzato come wrapper per uno strumento CLI?

posta yitzih 01.02.2018 - 20:46
fonte

1 risposta

5

Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?

Probabilmente no, ma non c'è bisogno di farlo: javac fornisce il flag -target , che consente di generare file di classe compatibili con qualsiasi versione (purché non si utilizzino funzionalità di origine o metodi di libreria chiamate non supportati da tale versione).

Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

Probabilmente no. I problemi di sicurezza con Java generalmente implicano problemi di implementazione nella JVM (Java Virtual Machine) o nelle librerie che utilizza. Ci sono anche alcuni problemi con le librerie di terze parti che abilitano comportamenti sfruttabili (per esempio, Apache Commons Collections supporta un'implementazione Map che potrebbe eseguire codice arbitrario).

Se si sta semplicemente compilando lo stesso codice per diverse architetture di destinazione (1.7 contro 1.8), è quasi garantito ottenere lo stesso output bytecode. Puoi confrontare il codice byte generato per ogni versione con il programma javap .

Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?

Non riesco a capire la domanda che mi stai ponendo, quindi risponderò alla domanda che penso tu stia chiedendo: se esegui una classe compilata compatibile con 1.7 su una JVM 1.8 aggiornata, allora ricevi tutti i vantaggi di sicurezza di quella JVM. Se si esegue su una JVM 1.7 o una JVM 1.8 precedente, si è soggetti a qualsiasi difetto di sicurezza presente in quella VM.

Si noti che molte librerie open source hanno come target 1.6 e persino 1.5. L'unica vera ragione per scegliere come target una versione più recente è se si utilizzano funzioni linguistiche (ad esempio, Lambdas) o funzioni di libreria che non erano disponibili nella versione precedente. In tal caso, il prelievo della versione di destinazione minima necessaria impedirà a un'installazione precedente di compilare la classe, poiché ogni versione di Java utilizza una versione di classfile diversa e i compilatori meno recenti non accettano file più recenti.

    
risposta data 01.02.2018 - 21:13
fonte

Leggi altre domande sui tag