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 ...

Por Qué Los Startups Necesitan Una Guía De Estilo

Incluso para un diseñador con experiencia, crear una nueva guía de estilo para un producto es difícil—hay muchas direcciones de diseño posible, y el proceso puede rápidamente convertirse en algo abrumador. La vida del  startup  es bastante agitada, rápida, y llena de clichés como “la perfección es la enemiga de tener algo hecho”, “muévete rápido y rompe cosas”, o “lancemos ahora, arreglemoslo después”. Crear una guía de estilo bajo dichos eslóganes y prioridades fluctuantes es desafiante, pero es necesario si queremos que el diseño de un producto tenga éxito a largo plazo. La  Experiencia Global de Lenguaje (GEL) de la BBC explica el propósito de cada componente y cómo deberían ser utilizados. En años recientes, hemos escuchado mucho sobre sistemas de diseño, guías de estilo, librerías de patrones, y  diseño atómico . Y si bien estas herramientas son muy útiles, usarlas puede sentirse como un exceso cuando lo único que quieres es crear un par de pantalla...