Vulnerabilidad en Java Web Start

Hace algunas semanas, en el twitter de Ruben Santamarta, un conocido investigador Español, podíamos ver el siguiente comentario:

Con la liebre correteando por ahí y todos nosotros desinstalando Java de nuestros navegadores, Rubén publico en su web algunos detalles más sobre la vulnerabilidad, que parece haber sido descubierta casi simultáneamente por él y por Tavis Ormandy, otro conocido investigador.

Según parece, la vulnerabilidad reside en una mala validación de ciertos parámetros que se pasan por linea de comandos al binario java.exe/javaws.exe en el momento que un navegador quiere ejecutar contenido Java.

Voy a tomarme la pequeña libertad de comentar el código publicado por Rubén, en su página web. También añadiré alguna captura mía de algún trozo de código que me parece interesante y que no aparece en la publicación de Rubén.

Aunque parezca raro, creo que en esta ocasión lo mejor para entender la vulnerabilidad es comenzar desde el final, es decir, desde el momento que se llama a javaws.exe. Si nos fijamos en el final del código seleccionado por Rubén, vemos que se apilan un montón de parámetros (push) antes de llamar a la función CreateProcessA. Esta función va a ser la encargada de crear un nuevo proceso con los parámetros que nosotros le hayamos pasado a través de la pila, es decir, todos esos parámetros que justo antes de la llamada estaban siendo apilados. Podemos obtener más información sobre estos parámetros acudiendo a la documentación oficial de Microsoft.

De entre todos estos parámetros, el afectado por la vulnerabilidad es lpCommandLine, mediante el cual le especificamos a la función con que parámetros en linea de comandos deberá llamar al binario (javaws.exe). En este caso, vemos que se está realizando un "push esi", es decir, en el lugar de la pila de donde CreateProcessA va a sacar el valor de lpCommandLine estamos metiendo el valor contenido en el registro ESI.

Perfecto.

Y...

¿Qué narices hay en ESI? :P

Evidentemente, el registro ESI podría haber sido cambiado en cualquier sitio y posteriormente haber hecho un salto a la zona de código que vemos, pero si no me equivoco si esto fuera así el IDA Pro nos habría etiquetado la linea con un "loc_direccion", y no es el caso. Dicho esto, vemos que solo existen dos posibilidades:

1. La ejecución viene de la dirección 6DAA3EB7 y al llegar a 6DAA3EC6 hace un salto a 6DAA3ED4 (jmp short loc_6DAA3ED4).
2. La ejecución ha saltado de una zona anterior al código que no vemos a 6DAA3EC8 y desde ahí ha seguido su ejecución normal hasta llegar a 6DAA3ED4 sin ningún tipo de saltos, ya que su código es consecutivo.

Vamos a seguir trazando hacia atrás a ver si vemos donde se ha definido el contenido del registro ESI. En este caso, para ambas opciones vemos que ESI contiene la dirección de memoria de un Buffer donde se va a guardar la cadena de texto resultado de la llamada a la función wsprintfA. Esta función es prácticamente idéntica (solo cambia el soporte para Unicode, que yo sepa) a la típica función de C "sprintf", en la que definimos un buffer de destino (al que apunta ESI), una cadena de formato del tipo "%s loquesea %d blablabla %s" y las referencias a los datos que irán en los "huecos" que hayamos dejado en la cadena de formato (en mi ejemplo, 3, cadena de texto, entero, cadena de texto). Como antes, podemos obtener más información sobre esta función acudiendo a la documentación oficial de Microsoft.

En el caso que nos ocupa, podemos ver que estamos utilizando 3 cadenas para formar una cadena de la siguiente forma:

Aplicacion [-docbase OpcionesDocBase] Opciones

Siendo esto así, vemos que tanto "OpcionesDocBase" ([ebp+arg_4]) como "Opciones" ([ebp+arg_0]) están saliendo DIRECTAMENTE de los argumentos con los que se ha llamado a la función, por lo que no parece existir ningún tipo de filtrado que impida que introduzcamos espacios en blanco, guiones u otros caracteres que nos permitan modificar los argumentos con los que se creará el nuevo proceso.

Las preguntas evidentes que nos surgen ahora son:

1. ¿Podemos controlar esos parámetros de forma remota de alguna manera? Porque sino... para poco nos va a servir todo lo que acabamos de ver.
2. Suponiendo que controlamos los parámetros que se le pasan a estos binarios, ¿para que sirve eso? ¿es peligroso para la seguridad?

Las respuestas son SI, podemos controlar esos parámetros y es peligroso para la seguridad.

Mañana: "Explotando Java Web Start"