Si tiene Java 6 instalado, CUIDADO !

Oracle dio por finalizado el soporte público para Java versión 6 el

pasado febrero. Las versiones públicas de Java poseen un soporte de tres
años. Pasado ese tiempo solo los clientes que tengan una licencia
comercial del producto podrán tener acceso a los parches críticos,
periodo que se extiende cinco años adicionales.

¿Cual es el problema? Java 6 aun se encuentra instalado en millones de
sistemas, no tiene soporte y existe una vulnerabilidad con exploit
publicado que se está usando activamente para infectar equipos.

En concreto se trata de la vulnerabilidad etiquetada con el
CVE-2013-2463. Un error en el índice de un array al invocar la función
nativa ‘storeImageArray’. Dicha función pertenece a la capa nativa del
paquete AWT (Abstract Widget Toolkit) encargado entre otras cosas del
tratamiento de imágenes, un paquete disponible desde la versión 1.0 de
Java.

Podemos ver parte del código de la función aquí:

static int storeImageArray(JNIEnv *env, BufImageS_t *srcP, BufImageS_t *dstP,
mlib_image *mlibImP)
{
int mStride;
unsigned char *cmDataP, *dataP, *cDataP;
HintS_t *hintP = &dstP->hints;
RasterS_t *rasterP = &dstP->raster;
int y;
…
if (hintP->packing == BYTE_INTERLEAVED) {
/* Write it back to the destination */
cmDataP = (unsigned char *) mlib_ImageGetData(mlibImP);
mStride = mlib_ImageGetStride(mlibImP);
dataP = (unsigned char *)(*env)->GetPrimitiveArrayCritical(env,
rasterP->jdata, NULL);
if (dataP == NULL) return 0;
cDataP = dataP + hintP->dataOffset;
for (y=0; y < rasterP->height;
y++, cmDataP += mStride, cDataP += hintP->sStride)
{
memcpy(cDataP, cmDataP, rasterP->width*hintP->numChans);
}
}
…
}

(fuente: http://packetstormsecurity.com/files/122777/)

La variable ‘dataP’ se inicializa a través de la variable miembro ‘data’
del objeto Java ‘sun.awt.image.BytePackedRaster’ (1). Dicho objeto es la
instanciación de una clase que pertenece al paquete ‘sun’. Esto
significa que estás clases no deberían ser instanciadas directamente ya
que pertenecen a funcionalidad que el fabricante usa para la parte
pública, es decir, aquellos paquetes que comienzan por java, javax o org
por ejemplo. Pero, por supuesto, nada impide crear objetos sobre las
clases de dichos paquetes si estos tienen un constructor público o a
través de una factoría.

‘data’ es un array del tipo primitivo ‘byte’ y contendrá un array de
bytes correspondientes a una imagen. El valor ‘dataP’ se suma a
‘hintP->dataOffset’. Este último valor se extrae del campo miembro
‘dataBitOffset’ del tipo ‘int’ o entero. La suma de estos dos valores
nos da ‘cDataP’ que es la dirección destino donde vamos a efectuar una
copia de datos en memoria.

El problema comienza cuando creamos un objeto del tipo
‘BytePackedRaster’ a través del método ‘createWritableRaster’ de la
clase ‘java.awt.image.Raster’. Dicho método necesita varios objetos para
crearnos un ‘BytePackedRaster’. El primero de ellos es de la clase
‘java.awt.image.MultiPixelPackedSampleModel’. Uno de los parámetros
necesarios para el constructor es ‘dataBitOffset’. La clave es que la
validación de dicho miembro, efectuada a través de la función miembro
privada ‘verify’, falla.

Veamos la implementación:

private void verify (boolean strictCheck) {
// Make sure data for Raster is in a legal range
if (dataBitOffset < 0) {
throw new RasterFormatException(“Data offsets must be >= 0”);
}

int lastbit = (dataBitOffset
+ (height-1) * scanlineStride * 8
+ (width-1) * pixelBitStride
+ pixelBitStride – 1);
if (lastbit / 8 >= data.length) {
throw new RasterFormatException(“raster dimensions overflow ” +
“array bounds”);
}
if (strictCheck) {
if (height > 1) {
lastbit = width * pixelBitStride – 1;
if (lastbit / 8 >= scanlineStride) {
throw new RasterFormatException(“data for adjacent” +
” scanlines overlaps”);
}
}
}
}
Para comenzar, cuando se construye el objeto ‘BytePackedRaste’, se llama
a ‘verify’ con el parámetro a ‘false’ por lo que la parte final del ‘if
(strictCheck) …’ no será llamada.

Pero si observamos bien cuando hace el ‘if (lastbit / 8 …’ está
permitiendo que ‘dataBitOffset’ pueda alcanzar un valor mayor que la
capacidad del array para ciertos valores manipulados de la imagen. Por
ejemplo en el exploit el constructor de ‘MultiPixelPackedSampleModel’ se
llama con los valores:
width = 4, height = 1, numberOfBits = 1, scanlineStride = 4,
dataBitOffset = (44 para 32 bits, 44+8 para 64 bits)

MultiPixelPackedSampleModel sm = new
MultiPixelPackedSampleModel(DataBuffer.TYPE_BYTE, 4,1,1,4, 44 + (_is64 ?
8:0));

Frente a un búfer creado de manera expresa:

DataBufferByte dst = new DataBufferByte(16);

Esto nos va a permitir que cuando vayamos a escribir en dicho búfer a
través de la función nativa ‘storeImageArray’ podamos escribir fuera de
los límites del búfer. En dicho búfer, sobre el que tenemos control de
escritura, podemos alojar un objeto y modificar sus permisos para
ejecutar código fuera de la sandbox de Java.

En el exploit, como prueba de concepto, nos va a invocar la calculadora
(el hola mundo de los exploits), pero prácticamente deja la puerta
abierta a la imaginación.

Esto no es nada nuevo ni es noticia, ya que dicha vulnerabilidad se
conoce desde hace meses y está parcheada para Java 7 revisión 25. El
exploit sí que se publicó hace relativamente poco, a principios de
agosto.

La noticia es que está siendo activamente explotado(2) por varios kits
de exploits y no hay ni va a ver parche para Java 6. Al menos para la
gran mayoría de usuarios. Esto significa que mantener una versión de
Java 7 sin actualizar o tener Java 6 en el sistema y visitar una página
infectada significa el compromiso del sistema.

Quizás el verdadero problema se encuentre en aquellas empresas que
dependen de la versión 6 de Java para funcionar y aun no hayan realizado
la migración (o no puedan permitírselo) a la versión 7. En este caso se
deberían extremar las medidas de seguridad oportunas para evitar
incidentes y recordar el riesgo que supone mantener activo un producto
sin soporte.
 Fuente