Java 7u11 - È più sicuro passare a 6?

3

L'aggiornamento Java 7u11 ha fatto recentemente alcune notizie per un paio di motivi. In primo luogo, si trattava di una patch fuori banda per risolvere le vulnerabilità sfruttate in natura. Quindi è tornato indietro perché ora è stato scoperto che la patch è incompleta. Le notizie che sto leggendo ora sembrano indicare che una o più cose stanno accadendo.

  1. Una vulnerabilità che avrebbe dovuto essere corretta in 7u11 non era affatto corretta.
  2. Nuove vulnerabilità sono state trovate in 7u11.
    • Non è chiaro se questi sono nuovi a 7u11 o vulnerabilità preesistenti scoperte di recente.
  3. Sebbene ci siano stati alcuni sforzi attenuanti introdotti in 7u11, i nuovi metodi di exploit (eventualmente accoppiati con nuove vulnerabilità) stanno consentendo di compromettere la vulnerabilità che si suppone sia stata patchata.

Le note di rilascio per Java 7u11 puntano a una sola vulnerabilità, CVE-2013-0422. Questa vulnerabilità sembra essere esclusiva di Java 7. Tuttavia, Java 6 continua a ricevere aggiornamenti fino a febbraio 2013.

Se rimuovere completamente Java non è un'opzione, passare alla versione più recente di Java 6 è più sicuro per ora? Oppure, ci sono abbastanza vulnerabilità non risolte in Java 6 risolte in 7 in modo tale che la versione più recente sia ancora il minore dei due malvagi?

    
posta Iszi 18.01.2013 - 21:45
fonte

3 risposte

1

Mi azzarderei a indovinare no. Non basato su prove concrete, solo un sospetto su come tornare al software che potrebbe non ricevere le ultime correzioni (le versioni precedenti alla fine vanno nella pila "appena aggiornato"), specialmente se si è un target di alto valore.

Una cosa 7u11 ha fatto è :

Area: deploy Synopsis: Default Security Level Setting Changed to High The default security level for Java applets and web start applications has been increased from "Medium" to "High". This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the "High" setting the user is always warned before any unsigned application is run to prevent silent exploitation.

Quindi, supponendo che non ci siano errori nel codice di controllo delle firme che ti permette di aggirare questo problema - in realtà 7u11 con una buona dose di educazione degli utenti potrebbe rimanere al sicuro se gli attaccanti non riescono a mettere le mani su un certificato valido per firmare il loro exploit con . Nello specifico, il codice non firmato apparirà con una finestra di dialogo "questo codice non è affidabile", come fa un UAC.

Questo, combinato con qualcosa come NoScript per bloccare inizialmente il caricamento di questi oggetti, dovrebbe significare che gli utenti devono almeno fare clic una volta prima che venga attivato un exploit.

Questo è buono - e si spera che si applichi anche a eventuali exploit futuri.

La mia comprensione della situazione di sfruttamento è presa da questo post del blog . La vulnerabilità che consentiva la sovrascrittura di securityManager è stata risolta, ma la vulnerabilità che consentiva a un utente finale di ottenere nomi di classi tramite Reflection che normalmente non sarebbe disponibile a causa della politica di sicurezza non è stata risolta.

Infine, per inciso, ho sperimentato la vulnerabilità su OpenJDK e ho scoperto che questo problema non sembra essere presente - Ottengo un'eccezione "L'eccezione della classe MBean non può essere caricata" (Reflection non funziona).

    
risposta data 18.01.2013 - 23:57
fonte
0

Potrebbe essere abbastanza sicuro da tornare a Java6; sebbene con la storia di Java attraverso molte delle sue versioni personalmente non mi fiderò mai più di nessuna versione di esso.

Mi chiedo cosa stia guidando la tua domanda; hai una specifica esigenza basata su browser per l'abilitazione di Java? In genere è possibile disabilitare Java nei browser che si utilizzano (dato che è generalmente utilizzato) e lasciare Java 7 sul PC per i programmi che lo richiedono; poiché è molto meno di un obiettivo specifico quando non è più accessibile tramite un plug-in del browser.

    
risposta data 18.01.2013 - 22:51
fonte
0

Dubito che qualcuno possa darti una risposta autorevole ... ma la mia reazione istintiva dice che attenersi a Java 7 mi sembra che sia probabilmente più sicuro.

Al momento, Java 7 richiede di fare clic su un'applet prima che inizi a essere in esecuzione. Al contrario, con Java 6 l'applet può essere eseguita senza richiedere un clic dell'utente. Pertanto, oggi l'attacco a Java 7 richiede di trovare sia una vulnerabilità che un minimo di ingegneria sociale per consentire all'utente di fare clic su di te. Certo, la parte di ingegneria sociale non è una barriera altissima, ma penso che valga la pena qualcosa .

    
risposta data 19.01.2013 - 09:00
fonte

Leggi altre domande sui tag