Apple a quanto pare lo prende sul serio, dal momento che ha "disabilitato Java" nei computer degli utenti, che è una mossa piuttosto drastica. Questo in realtà odora come un pretesto per eliminare la tecnologia, come parte di una strategia più ampia.
Per questo specifico buco, ci sono alcuni dettagli lì . Riguarda il modello di applet Java. Per capire:
-
Java è un linguaggio di programmazione e un'enorme libreria di codici, tutti in esecuzione all'interno di una macchina virtuale . La VM significa che il codice è molto più facile da portare tra le architetture. Fin qui tutto bene; lo stesso vale per molti altri framework, incluso .NET.
-
La strong tipizzazione di Java e della VM concettualmente consente una funzionalità aggiuntiva, che non è possibile (almeno non facilmente) con linguaggi bare metal come il C ++: il possibilmente di in grado di eseguire codice potenzialmente ostile . Con C o C ++ o assembly o qualsiasi altra cosa, tale impresa richiede un po 'di aiuto dall'hardware e dal sistema operativo (vale a dire i livelli di privilegio della modalità protetta, o, nei casi estremi, specializzato opcode di virtualizzazione ). I tipi forti e la VM consentono una soluzione sandbox solo software, che può essere integrata, ad esempio, in un browser Web.
-
Le applet Java sono proprio queste: una sandbox per l'esecuzione del codice Java che viene scaricato dal Web, come parte di una pagina Web. Tuttavia, le persone di Sun / Oracle non sapevano dove fermarsi ed erano un po 'troppo ansiosi. Poiché il codice sandboxed è severamente limitato in ciò che può fare, ci sono solo due scelte: imparare a vivere con limitazioni (questo è ciò che gli sviluppatori Javascript fanno), o includere nella sandbox un meccanismo di escape che permetta di alcune applet a fare cose fuori dalla sandbox, come leggere e scrivere file, aprire socket arbitrari ed eseguire codice nativo. La VM consente che, a condizione che l'applet richieda con cura , che comporta autorizzazioni ben definite, una firma digitale e un popup di autorizzazione esplicita.
-
Si scopre che gestire questo sistema di "permessi" è molto difficile da fare per la VM e la libreria; vale a dire, la libreria è molto ricca di codice che offre l'accesso a varie strutture del sistema operativo, e devono essere tutte collegate senza dimenticarle. Ci sono centinaia, forse migliaia di "chiamate sensibili" di cui preoccuparsi. La lunga storia dei buchi di sicurezza in Java è una testimonianza della quasi impossibilità del compito. Se la tecnologia concorrente di Microsoft ( Silverlight , costruita su .NET) sembra un po 'meno influenzata, è soprattutto perché è molto meno usato in tutto il mondo, dandogli molta meno esposizione.
Per il momento , la cosa più sicura da fare è disabilitare il supporto per le applet Java nel tuo browser. Nota che le applicazioni di Java, e in particolare tutto ciò che viene eseguito sul lato server, non subiscono alcun impatto.
Il problema di eseguire in sicurezza il codice ostile, mantenendo allo stesso tempo funzionalità avanzate e controllo degli accessi a grana fine, non è un nuovo problema. Ciò che questo ennesimo incidente di Java mostra è che questo vecchio problema è ancora irrisolto.