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);
}
}
...
}
La variable 'dataP’ se inicializa
a través de la variable miembro 'data'
del objeto Java 'sun.awt.image.BytePackedRaster'. 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 por varios kits de exploits
y no hay ni va a haber 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.
Más información:
public class:
BytePackedRaster
Java 6 exploit found in the wild
Oracle Java SE Support Roadmap
Packet Storm Exploit 2013-0811-1 - Oracle Java
storeImageArray() Invalid Array Indexing Code Execution
David García
Twitter: @dgn1729
