Oracle arregla la grave vulnerabilidad y eleva la configuración de seguridad

En un tiempo récord, Oracle ha publicado una nueva versión que corrige
el grave fallo en JRE publicado hace unos días. Además ha mejorado la
configuración por defecto. ¿Qué esconde esta decisión? ¿Es efectiva?

Aunque Oracle se ha apresurado a publicar la versión 7u11 de su JRE para corregir el grave fallo de seguridad que estaba siendo aprovechado por atacantes, el paso más importante que ha dado Oracle es subir la seguridad por defecto a «alta» para el plugin web. Con esta nueva configuración, se preguntará al usuario si quiere ejecutar un applet
no firmado. Esto es relevante por varias razones. Hace unas semanas, escribíamos:

«Por defecto (como muy probablemente lo dejarán la mayoría de usuarios), viene configurado para ejecutar sin preguntar applets no firmados

Los atacantes encontrarían un mayor obstáculo si tuviesen que firmar los
applets maliciosos y que fueran validados por una entidad de confianza.
Esto sí podría suponer un pequeño freno».

Oracle incluía esta configuración que permitía de forma cómoda exigir
que los applets estuvieran firmados, tras un 2012 desastroso donde
varias vulnerabilidades se convirtieron en el vehículo preferido para
que los atacantes lanzaran agresivas campañas como la del virus de la
policía. Recién estrenado 2013 aparece otro grave fallo. Ahora mejora el
tiempo de respuesta, pero además marca un importante hito. Al subir por
defecto la seguridad a «alta», está «obligando» a que los applets tengan
que estar firmados por entidades de confianza para que sean ejecutados,
pero deja la última palabra al usuario. Esto, como siempre, es una mala
decisión.

Ver http://mcaf.ee/4qhbr

El usuario no suele hacer buenas elecciones en seguridad, simplemente
porque no entiende y quiere obtener lo que busca de forma cómoda. Este
sistema de diálogo donde la pelota cae de del lado del usuario, sin duda
es un avance, pero también puede suponer un problema para las páginas
legítimas que lanzan applets y no los han firmado. Se bloquearán y los
usuarios menos experimentados puede que piensen que le están atacando.

Este, suponemos, era uno de los temores que estacaban a Oracle en una
configuración insegura. Pero parece que lo van superando. Ya no les
importa «romper» en cierta manera páginas legítimas con tal de detener
una sangría que está dañando la imagen de Java en la web.

Pero esa decisión también puede estar motivada porque Oracle sabe que su modelo de seguridad de los applets de Java es un desastre, y que
funcionar reactivamente parcheando sus versiones no es la mejor manera
de avanzar. Según Adam Gowdiak siguen existiendo decenas de
vulnerabilidades conocidas en Java, esperando ser aprovechadas por los
atacantes. Tantas que, según HD Moore, a Oracle le llevaría dos años
solucionarlas todas. Para colmo, los últimos fallos se basan en el
diseño, no en un problema de programación concreto. Estos son más
difíciles de solucionar de raíz.

Por tanto, ese movimiento forzando en cierta manera que los applets
estén firmados es más importante de lo que parece. Asume que, o bien
comienza a tomar soluciones reales, o Java para la web puede quedar
condenado a la extinción como sinónimo de problemas de vulnerabilidad.

¿Será una solución efectiva?

En principio, no es mala idea. Lo ideal hubiera sido bloquear todos los
no firmados (en la configuración «muy alta»), pero algo es algo. Los
applets de los atacantes no suelen estar firmados, por lo que al menos,
ya no se ejecutarán automáticamente, por defecto y de forma totalmente
transparente. Habrá un diálogo previo. Toca al usuario decidir qué
hacer.

Además, sabemos que el modelo de firma pública no es perfecto, y que
incluso en los últimos años, hemos observado varios incidentes
relacionados con certificados que permiten a los atacantes o bien firmar
nuevos o bien crear nuevos. Se han dado muchos casos de malware firmado legítimamente.

Por tanto, ahora los atacantes pueden o bien intentar firmar sus
applets, o bien continuar confiando en que los usuarios no actualizarán
a la versión 7u11, con lo que seguirán como siempre, solo que con un
mercado de potenciales víctima menor. Pero lo más probable es que no
ocurra nada, puesto que usarán la ingeniería social para hacer que el
usuario piense que es indispensable que deba aceptar el diálogo
propuesto y así seguir infectando como hasta ahora. Más incómodo pero
también muy efectivo.

Ver http://mcaf.ee/cvut7

¿Acaso los usuarios medios saben qué es un applet y qué consecuencias
tiene? Probablemente creerán que es una simple formalidad, y lanzará la
ejecución. Esto, si bien no es la situación ideal para el atacante, no
detiene el problema por completo.

En cualquier caso, si bien Oracle parece apuntar en la buena dirección,
casi siempre lo hace tarde o de forma incompleta. Este movimiento podía
haberse realizado hace varios años, desde que comenzó una vorágine de
vulnerabilidades en su máquina virtual o, lo que es mejor, bloquear
directamente todo lo que no esté firmado. Al final, han acabado tomando
una decisión en la dirección buena… pero en el camino los atacantes
han ganado unos buenos beneficios y Oracle ha perdido credibilidad.

Y posiblemente el impacto para el usuario no sería para tanto ante un
cambio en la configuración por defecto incluso más drástico. Se
adaptarían. Microsoft tuvo que esperar a que pasaran Blaster, Sasser y
otros importantes gusanos para activar el cortafuegos de XP por defecto
en 2004. Muchos usuarios y programadores encontraron un grave problema que les produjo muchos dolores de cabeza… pero mereció la pena. No hay que menospreciar la capacidad de adaptación del usuario, programadores y administradores.

Fuente

Comentario:

Y para los mas exigentes, [Enlace Retirado]

saludos

ms, 16-1-2013