Con este nuevo agujero Microsoft deja la puerta abierta para que se puedan leer archivos de los sistemas de los usuarios mientras visitan una página web con Internet Explorer. El problema, que parte de una mala implementación en la máquina virtual de Java, permite construir applets que tengan acceso a los ficheros locales, incumpliendo de esta forma uno de los pilares básicos en los que descansa la seguridad en Java.
Si bien no se trata, ni mucho menos, del primer agujero de seguridad en la MV Java de Microsoft, éste tiene la particularidad de que es muy fácil de reproducir. Cualquier programador novel puede construir fácilmente un applet para explotar la vulnerabilidad y conseguir acceder a ficheros sensibles de los sistemas de los usuarios que visiten su web, de ahí que se agrave el peligro potencial que ya tiene de por sí el agujero.
La seguridad en los applets de Java
La potencia de los applets, entre otras características, reside en la posibilidad de que el c¢digo de un programa viaje a trav’s de la red y pueda ser ejecutado en cualquier sistema. Tanta versatilidad puede traer aparejada una serie de problemas de seguridad: por ejemplo introducir virus, recoger informaci¢n confidencial del usuario, o utilizar la m quina donde se ejecuta como pasarela para llevar a cabo otros ataques. Para evitar estas situaciones los applets de Java poseen, por dise_o, una serie de limitaciones que a grosso modo se resumen en que no pueden acceder al disco duro local ni utilizar otro servidor distinto al de su origen.
Los applets nos llegan desde los servidores de Internet con un c¢digo precompilado, lo que se denomina c¢digo byte, que es ejecutado en nuestro navegador por un interprete como es la M quina Virtual de Java de Microsoft en el caso de Internet Explorer. El que sea un lenguaje interpretado permite al c¢digo byte ser independiente del sistema operativo y la plataforma hardware. Un applet deber¡a ejecutarse de igual forma en Internet Explorer 5 para Windows que en Netscape bajo Linux, ser el interprete de cada navegador el encargado de procesar el mismo c¢digo byte y que se ejecute adecuadamente bajo la plataforma correspondiente.
El interprete tiene como una de sus misiones la de verificar el c¢digo byte bajado desde el servidor para comprobar que no viola los requisitos de seguridad impuestos por el lenguaje Java. La realidad es que, si bien la mayor¡a de las implementaciones cumplen los est ndares Java, existen algunas diferencias que se agravan en el caso de Microsoft y que pueden -suelen- tener efectos nocivos.
La vulnerabilidad
El agujero consiste, como hemos explicado, en la permisividad que presenta la M quina Virtual de Java para que un applet pueda leer ficheros del sistema local del usuario que lo ejecuta. Las limitaciones, o condiciones, son que es necesario conocer la ubicaci¢n y nombre del fichero, as¡ como encontrarse dentro del directorio de trabajo que tenga asignado la M quina Virtual de Java.
En el caso de Internet Explorer 4, el directorio por defecto es «C:», lo que significa que todos los archivos del disco duro pueden ser accesibles por un applet de Java. En el caso de Internet Explorer 5 el directorio es «C:Windowsdesktop», por lo que el acceso se limita al contenido del escritorio, lo que incluye sus subdirectorios. En el caso de sistemas Windows NT el acceso a los ficheros vendr condicionado por los permisos que tenga el usuario que haga uso del sistema.
Adem s de estos directorios por defecto, ser n accesibles todos aquellos que est’n en el mbito de la variable CLASSPATH, esta ampliaci¢n, si bien no es muy usual, suele darse en los sistemas de los programadores de Java.
El exploit
Como ya adelant bamos, la peligrosidad de esta vulnerabilidad se ve agravada por la sencillez de su puesta en pr ctica. Mediante una simple funci¢n, getSystemResourceAsStream(), un programador puede a_adir una l¡nea en el c¢digo de su applet para leer un fichero, por ejemplo:
InputStream is = ClassLoader.getSystemResourceAsStream(fichero);
Una vez logrado el objetivo el atacante puede hacer que la informaci¢n viaje hac¡a su servidor web o que se env¡e adjunta por correo electr¢nico.
Para probar la vulnerabilidad podemos recurrir a un applet demostrativo de Hiromitsu Takagi, uno de los participantes en «Java House Mailing List», una lista de discusi¢n japonesa sobre Java donde se descubri¢ el agujero.
http://java-house.etl.go.jp/ takagi/java/test/microsoft_insecurity/Test.html
En este applet se nos solicita un fichero local, por defecto autoexec.bat, y muestra su contenido. Deberemos de tener en cuenta la versi¢n de nuestro navegador, si es Internet Explorer 4 estaremos situados en «C:»., en el caso de la versi¢n 5 el directorio de partida ser «C:Windowsdesktop», por lo que seguramente ser necesario modificar la entrada por defecto y poner en su lugar otro nombre de fichero que se encuentre en nuestro escritorio para poder visualizar la demostraci¢n. Si solicitamos un fichero no accesible el applet responder con el mensaje «java.lang.NullPointerException».
Parche
De momento Microsoft, conocedora del problema, no se ha pronunciado sobre este importante agujero ni proporcionado un parche para solucionarlo. Las soluciones pasan, mientras tanto, por desactivar Java en Internet Explorer, utilizar otro navegador como Netscape, o instalar el plug-in Java de Sun para el navegador de Microsoft que se puede encontrar en
http://java.sun.com/products/plugin/index.html
M s informaci¢n:
C¢digo fuente del applet-demostraci¢n
http://java-house.etl.go.jp/ takagi/java/test/microsoft_insecurity/Test.java.txt
Applet demostraci¢n
http://java-house.etl.go.jp/ takagi/java/test/microsoft_insecurity/Test.html
Acerca del applet y la vulnerabilidad
http://java-house.etl.go.jp/ml/archive/j-h-b/030411.html
Java (Sun)
http://java.sun.com/
Java (Microsoft)
http://www.microsoft.com/java/
Bernardo Quintero
bernardo@hispasec.com
