Ir al contenido principal

Mejorar y entender la seguridad del plugin de Java (II) (Enero 2013)

Mejorar y entender la seguridad del plugin de Java (II)

El plugin de Java se está convirtiendo en un serio problema de seguridad, llevamos meses comprobándolo. Oracle ha añadido seguridad en su configuración por defecto, y ofrecido más granularidad a los usuarios. Pero todavía es mejorable. ¿Para qué sirven las nuevas funcionalidades y qué se puede esperar de ellas?
Niveles de seguridad y versiones seguras
En este sentido de control de certificados y versiones, en la versión 7u10 se introdujeron los niveles de seguridad y la "autoconciencia" de ser una versión "insegura". Recordemos que la seguridad se basa fundamentalmente en contener la ejecución de applets dañinos que puedan eludir la sandbox y para eso la clave está en la criptografía (hay que luchar contra los applets no firmados) y e la actualización de la propia máquina virtual.
Con respecto a la actualización, el problema (lógico) es que para cuando Oracle emite la "alarma" de que la versión es insegura (no es la última), es porque ya se han encontrado problemas de seguridad.
Con respecto a los niveles de seguridad, actualmente el nivel por defecto es "alto". Veamos los niveles:
  • Bajo: Los applets no firmados se ejecutarán de forma automática en el sistema sin preguntar. Solo se lanzará una pregunta al usuario si los propios applets piden acceso a recursos protegidos o quieran ejecutarse sobre una versión antigua. Una manía de Oracle es dejar que convivan versiones de la máquina antiguas en el sistema y los applets pueden elegir cuál. Hay que eliminarlas.
        
  • Medio: Solo si la versión de Java se considera segura (no se detecta una más reciente), los applets no firmados se ejecutarán en el sistema de forma automática. Si Java detecta una versión nueva online, se ofrecerá un diálogo al usuario antes de lanzar los applets. Lógicamente, la versión más reciente se considera "segura" oficialmente. Así, estando "actualizado", los applets no firmados se ejecutarán de forma automática, con lo que este nivel no protege en absoluto durante la ventana de tiempo entre que se explota un fallo y se saca una nueva versión.
        
  • Alto: Se preguntará al usuario siempre que se intente ejecutar un applet no firmado, independientemente de la versión o su comportamiento. Además aparecerá esta alerta si se tiene una versión antigua.
       

   
  • Muy alto: No se ejecutarán los applets no firmados bajo ningún concepto. Obviamente la opción "Muy alto" es la mejor, puesto que los applets de los atacantes no suelen estar firmados. Si se eleva a ese nivel, aparecerá este mensaje:

¿Qué harán los atacantes para eludir estas nuevas restricciones y seguir infectando a usuarios? Veremos algunas alternativas en la próxima entrega.
Más información:

una-al-dia (28/01/2013) Mejorar y entender la seguridad del plugin de Java (I)
Fuente: 

Comentarios

Entradas populares de este blog

¿Qué es la ejecución de código arbitrario?

En informática , el término código arbitrario hace referencia a código muy largo que no será interpretado por una aplicación o sistema operativo sino que provocará un desbordamiento de búfer de esa aplicación o sistema operativo lo que hará que el trozo desbordado sea interpretado y/o ejecutado por el sistema bajo unas condiciones más favorables. Es utilizado para realizar ataques. Otra forma más simple de definirlo es que la ejecución de código arbitrario es: Una forma fácil en la que un atacante puede ejecutar "comandos" tan sencillo como pensar en que alguien a distancia esta tecleando comandos que pueden ser desde un inocente mkdir "para hacer directorio" hasta un rm "borrar directorio" o abrir puertos etc para troyanizar el equipo "mantener el acceso". Lo que también es conocido como remote code execution .

Codificación de Datos: Una Guía UTF-8 para PHP y MySQL

Desde toptotal nos cuentan.. "La codificación de Datos" esto creo que es una duda que nos ha surgido en algún punto cuando vamos iniciando en el mundo del desarrollo y es el desconocimiento de los diferentes formatos de codificación tenemos varias opciones pero hoy nos centraremos en el uso de UTF-8 y porque deberías usarlo. Como desarrollador  PHP  o  MySQL , una vez que pasas más allá de los confines de los cómodos conjuntos de caracteres sólo en inglés, te encuentras rápidamente enredado en el maravillosamente y extraño mundo de UTF-8. Una Mirada Rápida UTF-8 Primer Unicode es un estándar de la industria de computación ampliamente utilizado, que define un mapeo completo de valores únicos de códigos numéricos a los caracteres de la mayoría de los conjuntos de caracteres escritos hoy en día, para ayudar con la interoperabilidad de los sistemas y el intercambio de datos.  UTF-8 es una codificación de amplitud variable (variable-width encoding) que puede ...

Las Diez Mejores Reglas De Diseño Front-End Para Desarrolladores

Como desarrolladores Front-End, nuestro trabajo es esencialmente convertir los diseños en realidad a través del código. Comprender y ser competentes en el diseño es un componente importante de esto. Desafortunadamente, entender realmente el diseño de Front-End es más fácil a la hora de decirlo que hacerlo. La codificación y el diseño estético requieren algunos conjuntos de habilidades bastante diferentes. Debido a esto, algunos desarrolladores Front-End no son tan proficientes en el aspecto de diseño como deberían ser y como resultado, su trabajo sufre. Mi objetivo es darte algunas reglas y conceptos fáciles de seguir, desde un  desarrollador Front-End  a otro, que te ayudará a ir desde el inicio hasta el final de un proyecto sin estropear lo que tus diseñadores trabajaron tan duro (o posiblemente incluso permitirte diseñar tus propios proyectos con resultados decentes). Por supuesto, estas reglas no te llevarán de malo a magnífico en el tiempo que toma para leer un artí...