Aparentemente, Apple toma esto en serio, ya que "deshabilitaron Java" en las computadoras de los usuarios, lo cual es un movimiento bastante drástico. Esto realmente huele como un pretexto para acabar con la tecnología, como parte de una estrategia más amplia.
Para este agujero específico, hay algunos detalles allí . Se trata del modelo de applet de Java. Para entender:
-
Java es un lenguaje de programación y una enorme biblioteca de código, todo se ejecuta dentro de una máquina virtual . La VM significa que el código es mucho más fácil de portar entre arquitecturas. Hasta ahora tan bueno; lo mismo se aplica a varios otros marcos, incluido .NET.
-
La escritura fuerte de Java y la VM permite conceptualmente una característica adicional, que no se puede tener (al menos no fácilmente) con lenguajes más simples como C ++: la posibilidad de que ejecute de forma segura un código potencialmente hostil . Con C o C ++ o ensamblado o lo que sea, tal hazaña requiere ayuda del hardware y del sistema operativo (es decir, los niveles de privilegio del modo protegido o, para los casos extremos, la especialización opcodes de virtualización ). Los tipos fuertes y la máquina virtual permiten una solución de sandbox solo para software, que podría integrarse, por ejemplo, en un navegador web.
-
Los applets de Java son solo eso: una zona de pruebas para ejecutar el código Java que se descarga desde la web, como parte de una página web. Sin embargo, las personas en Sun / Oracle no sabían dónde parar y estaban un poco ansiosas. Dado que el código de espacio aislado está muy limitado en lo que puede hacer, solo hay dos opciones: aprender a vivir con limitaciones (eso es lo que hacen los desarrolladores de Javascript), o incluir en la caja de arena un mecanismo de escape que permita a algunos applets de algunos haga cosas fuera de la caja de arena, como leer y escribir archivos, abrir sockets arbitrarios y ejecutar código nativo. La VM lo permite, siempre que el applet tenga un buen nivel , lo que conlleva permisos específicos, una firma digital y una ventana emergente de autorización explícita.
-
Resulta que la administración de este sistema de "permisos" es muy difícil para la VM y la biblioteca; a saber, la biblioteca es muy rica en código que ofrece acceso a varias instalaciones del sistema operativo, y todas deben estar conectadas sin olvidar ninguna. Hay cientos, tal vez miles de "llamadas delicadas" que deben preocuparse. La larga historia de agujeros de seguridad en Java es un testimonio de la casi imposibilidad de la tarea. Si la tecnología competidora de Microsoft ( Silverlight , construida sobre .NET) parece un poco menos afectada, es sobre todo porque es mucho menos utilizado en todo el mundo, lo que le da mucha menos exposición.
Por el momento , lo más seguro es desactivar el soporte para applets de Java en su navegador. Tenga en cuenta que las aplicaciones de Java, y en particular cualquier cosa que se ejecute en el lado del servidor, no se ven afectadas.
El problema de ejecutar código hostil de manera segura, mientras que al mismo tiempo mantiene una funcionalidad rica y un control de acceso detallado, no es un problema nuevo. Lo que muestra este otro percance de Java es que este problema anterior aún no se ha resuelto.