viernes, 5 de diciembre de 2008

Re: Analisis de un Bug: 'imlib2' Library 'load()' CVE-2008-5187

Bien estos dias voy a estar algo ocupado con lo del trabajo y eso. Solo veremos una tecnica mas de depuracion.
Este nos sirve mas que nada para cuando, el bug se enecunetra en una libreria, tal y como es nuestro caso:

Citar
%truss -f -d -o prueba.truss ./imlib2_convert ./prueba.xpm ./prueba.png

Este comando nos generara un archivo prueba.truss

Mas informacion sobre truss:
Código:
http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?truss+1

De este lo podemos examinar con:
Citar
%cat prueba.truss

Pero lo que nos interesa es ver que librerias carga:

Citar
%cat prueba.truss | grep open
27161: 0.000555657 open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory'
27161: 0.000624940 open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 4 (0x4)
27161: 0.001195124 open("/usr/local/lib/libImlib2.so.5",O_RDONLY,00) = 4 (0x4)
27161: 0.002000254 open("/usr/local/lib/libfreetype.so.9",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.002534400 open("/lib/libz.so.4",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.003249575 open("/usr/local/lib/libX11.so.6",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.003975924 open("/usr/local/lib/libXext.so.6",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.004507276 open("/lib/libm.so.5",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.005050921 open("/lib/libc.so.7",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.005640102 open("/usr/local/lib/libXau.so.6",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.006182070 open("/usr/local/lib/libXdmcp.so.6",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.006825169 open("/usr/lib/librpcsvc.so.4",O_RDONLY,027757765154) = 4 (0x4)
27161: 0.010692141 open("/usr/local/lib/imlib2/loaders",O_NONBLOCK,027757765154) = 4 (0x4)
27161: 0.011528560 open("/usr/local/lib/imlib2/loaders/zlib.so",O_RDONLY,00) = 4 (0x4)
27161: 0.012475049 open("/usr/local/lib/imlib2/loaders/xpm.so",O_RDONLY,00) = 4 (0x4)
27161: 0.013366224 open("/usr/local/lib/imlib2/loaders/tiff.so",O_RDONLY,027757765354) = 4 (0x4)
27161: 0.013917132 open("/usr/local/lib/libtiff.so.4",O_RDONLY,05001126346) = 4 (0x4)
27161: 0.014448764 open("/usr/local/lib/libjpeg.so.9",O_RDONLY,027757765314) = 4 (0x4)
27161: 0.016059583 open("/usr/local/lib/imlib2/loaders/tga.so",O_RDONLY,057765354) = 4 (0x4)
27161: 0.017023113 open("/usr/local/lib/imlib2/loaders/pnm.so",O_RDONLY,027757765354) = 4 (0x4)
27161: 0.017904231 open("/usr/local/lib/imlib2/loaders/png.so",O_RDONLY,027757765354) = 4 (0x4)
27161: 0.018456256 open("/usr/local/lib/libpng.so.5",O_RDONLY,05001126346) = 4 (0x4)
27161: 0.019926275 open("/usr/local/lib/imlib2/loaders/lbm.so",O_RDONLY,057765354) = 4 (0x4)
27161: 0.020819685 open("/usr/local/lib/imlib2/loaders/jpeg.so",O_RDONLY,027757764470) = 4 (0x4)
27161: 0.021755837 open("/usr/local/lib/imlib2/loaders/id3.so",O_RDONLY,027757765354) = 4 (0x4)
27161: 0.022305349 open("/usr/local/lib/libid3tag.so.0",O_RDONLY,05001126346) = 4 (0x4)
27161: 0.023608308 open("/usr/local/lib/imlib2/loaders/gif.so",O_RDONLY,027757764470) = 4 (0x4)
27161: 0.024143571 open("/usr/local/lib/libungif.so.5",O_RDONLY,05001126346) = 4 (0x4)
27161: 0.024733031 open("/usr/local/lib/libSM.so.6",O_RDONLY,027757765314) = 4 (0x4)
27161: 0.025264384 open("/usr/local/lib/libICE.so.6",O_RDONLY,027757765314) = 4 (0x4)
27161: 0.027015165 open("/usr/local/lib/imlib2/loaders/bz2.so",O_RDONLY,01) = 4 (0x4)
27161: 0.027678937 open("/usr/lib/libbz2.so.3",O_RDONLY,05001126346) = 4 (0x4)
27161: 0.028755889 open("/usr/local/lib/imlib2/loaders/bmp.so",O_RDONLY,00) = 4 (0x4)
27161: 0.029659915 open("/usr/local/lib/imlib2/loaders/argb.so",O_RDONLY,027757765354) = 4 (0x4)
27161: 0.030491864 open("./prueba.xpm",O_RDONLY,0666) = 4 (0x4)
27161: 0.031230785 open("./prueba.xpm",O_RDONLY,0666) = 4 (0x4)
27161: 0.031834493 open("./prueba.png",O_WRONLY|O_CREAT|O_TRUNC,0666) = 4 (0x4)

Podemos extender la busqueda solo a libredias con "lib" ya que el anterior tambien nos arrojo los archivos que habre como ./prueba.xpm y ./prueba.png que son los uqe nosotros le pasamos.

Filtremos solo xpm y lib ;)

Citar
%cat prueba.truss | grep open |grep lib | grep xpm
27161: 0.012475049 open("/usr/local/lib/imlib2/loaders/xpm.so",O_RDONLY,00) = 4 (0x4)

;) Vemos que si carga el archivo vulnerable, entonces lo mas probable es que si use la funcion load del archivo loaders_xpm.c para cargar la imagen ./prueba.xpm que le pasamos, seria cuestion de depurarlo un poco mas.

A ver me voy volver loco con tantas archivos.

En el direcctorio de src de imlib2 esta la ruta:

src/modules/loaders

Listo los archivos xpm:
Citar
%ls -l | grep xpm
-rw-r--r--  1 1000  1000  28911 Dec  5 10:55 loader_xpm.c
-rw-r--r--  1 root  1000    344 Dec  5 10:55 loader_xpm.lo
-rw-r--r--  1 root  1000  20032 Dec  5 10:55 loader_xpm.o
-rw-r--r--  1 root  1000    882 Dec  5 10:55 xpm.la


Tenemos:

  • loader_xpm.c
  • loader_xpm.lo
  • loader_xpm.o
  • xpm.la

pero el programa carga /usr/local/lib/imlib2/loaders/xpm.so entonces vemos que al instalar la libreria nos menciona lo siguiente:

Citar
Libraries have been installed in:
   /usr/local/lib/imlib2/loaders

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
 /bin/sh ../../../libtool --mode=install /usr/bin/install -c  'xpm.la' '/usr/local/lib/imlib2/loaders/xpm.la'
/usr/bin/install -c .libs/xpm.lai /usr/local/lib/imlib2/loaders/xpm.la
/usr/bin/install -c .libs/xpm.a /usr/local/lib/imlib2/loaders/xpm.a
chmod 644 /usr/local/lib/imlib2/loaders/xpm.a
ranlib /usr/local/lib/imlib2/loaders/xpm.a
----------------------------------------------------------------------

Bueno seguire buscando.

jueves, 4 de diciembre de 2008

Analisis de un Bug: 'imlib2' Library 'load()' CVE-2008-5187

Bueno toda esta mania surgio de cuando trate de instalar enlightenment sencillamente me decia que habia un bug en alguna dependecia de este, y no me dejaba instalarlo hasta que actualizara o aplicara el parche.

Mas Info:

FreeBSD: Problema con imlib2-1.4.1.000 (Solucion)



CVE-2008-5187

Advisor Original:

Código:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505714

Antecedentes

Imlib2 es el succesor de Imlib, Esto no es una nueva version, solo es una bibliotecas totalmente nueva. Imlib2 puede ser completamente instalado aun existiendo Imlib 1.x esto sin ningun problema, ya que efectivamente son diferentes bibliotecas pero con funciones muy similares.
Si bien no forma estrictamente parte de la EFL, la biblioteca es utilizada imlib2 por la EFL para el manejo, visualización y manipulación de gráficos a bajo nivel. Es capaz de cargar y manipular archivos de gráficos de muchos formatos, y también es capaz de mostrar en un X Window System. Los desarrolladores cuentan con imlib2 que es muy optimizado.

XPM es una formato de imagen, basdo en Texto/ASCII Usado pro el X Window System, Su principal Intencion fue para crear Iconos, pixmaps y soportar colores traparentes.

Código:
http://en.wikipedia.org/wiki/X_PixMap

Un ejemplo de una imagen XMP

16*7 black and white pixels.

Citar
/* XPM */
static char *prueba[] = {
"16 7 2 1",
"* c #ffffff",
". c #000000",
"**..*...........",
"*.*.*...........",
"**..*..**.**..**",
"*.*.*.*.*.*..*.*",
"**..*..**.*...**",
"...............*",
".............**."
};

Version: imlib2-1.4.1.000
Codigo Vulnerable: loader_xpm.c
Funcion Vulnerable: load

Analizando el parche tenemos que:

Funcion vulnerable:

Linea 250:
Código:
                            ptr = im->data;
                            end = ptr + (sizeof(DATA32) * w * h);
                            pixels = w * h;
                         }

Funcion NO vulnerable

Linea 250:
Código:
                            ptr = im->data;
                            pixels = w * h;
                            end = ptr + pixels;
                         }
Viendolo solo desde el diff:

Citar
# diff imlib2-1.4.1.000/imlib2-1.4.1.000/src/modules/loaders/loader_xpm.c /usr/ports/graphics/imlib2/work/imlib2-1.4.1.000/src/modules/loaders/loader_xpm.c
251d250
<                             end = ptr + (sizeof(DATA32) * w * h);
252a252
>                             end = ptr + pixels;



Al parecer solo la variable end, es la que nos ocaciona el desbordamiento, al utilizarla en otra parte del codigo.

Lo que pasa es que end, es un apuntador al final, sin embargo:

Código:
(sizeof(DATA32) * w * h)

Esto da algo mayor a  solo

Código:
pixels = w * h;
end = ptr + pixels;


El punto esta en que la cifra se hace 4 veces mas grande:


Código:
/* standard headers */
#include <X11/Xlib.h>
#include <Imlib2.h>
#include <stdio.h>


int main()      {
        printf("Tamaño de DATA32: %d bytes\n",sizeof(DATA32));
        return 0;
}

Citar
%./imlibtest
Tamaño de DATA32: 4 bytes

Tamaño de DATA32: 4 bytes

Como podemos ver estaba multiplicando el espacio por 4

Las variables pixels,w,h son enteros.
ptr y end son apuntadores a DATA32
im es un apuntador a ImlibImage, el cual es pasao como parametro directamente a la funcion.


Bien ahora probaremos el programa, transformando una Imagen xmp a png xD.

Este ejemplo lo tome de la documentacion de imlib2


Código:
/* standard headers */
#include <X11/Xlib.h>
#include <Imlib2.h>
#include <stdio.h>
#include <string.h>

/* main program */
int main(int argc, char **argv)
{
  /* an image handle */
  Imlib_Image image;
 
  /* if we provided < 2 arguments after the command - exit */
  if (argc != 3) exit(1);
  /* load the image */
  image = imlib_load_image(argv[1]);
  /* if the load was successful */
  if (image)
    {
      char *tmp;
      /* set the image we loaded as the current context image to work on */
      imlib_context_set_image(image);
      /* set the image format to be the format of the extension of our last */
      /* argument - i.e. .png = png, .tif = tiff etc. */
      tmp = strrchr(argv[2], '.');
      if(tmp)
         imlib_image_set_format(tmp + 1);
      /* save the image */
      imlib_save_image(argv[2]);
    }
}
Citar
Now to compile this
cc imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
You now have a program that if used as follows:
./imlib2_convert image1.jpg image2.png

Compilando:

Citar
%cc imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
imlib2_convert.c: In function 'main':
imlib2_convert.c:14: warning: incompatible implicit declaration of built-in function 'exit'

Bueno es un warning pero a mi no me gusta que eso aparezca, le agrego el #include<stdlib.h>
 
Creado la prueba obtenemos que si transforma la imagen a un png, Segun la documentacion puede transformar de culquier extensión a cualqueir extensión!!

Ahora esto solo es una prueba del funcionamiento, ya que obviamente se mando a llamar a la funcion vulnerable sin embargo se cargo con buenos datos.

Vamos a ver como es que se puede hacer caer esto, Segun el advisor Original la falla fue encontrada con una imagen de 32 * 32 pixeles sin embargo como no se da mas informacion, no nos queda mas que depurar, para esto va a ser necesario modificar el make file de los ports en mi caso FreeBSD, en algunos otros casos va a ser necesario modificar el .configure o diferentes.

Bien, antes de depurar las librerias, vamos a depurar la pequeña aplicacion que compilamos.

Citar
%cc -ggdb imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
%cc -ggdb -static imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
/usr/local/lib/libX11.a(ConnDis.o)(.text+0x9e8): In function `_X11TransConnectDisplay':
: undefined reference to `XauDisposeAuth'
/usr/local/lib/libX11.a(ConnDis.o)(.text+0xcbf): In function `_X11TransConnectDisplay':
: undefined reference to `XauGetBestAuthByAddr'
/usr/local/lib/libX11.a(ConnDis.o)(.text+0xf1a): In function `_X11TransConnectDisplay':
: undefined reference to `XdmcpWrap'
Me marca erros al querer incluirlo estaticamente, tendre que probarlo normal solo con -ggdb y vemos que pasa

Citar
%gdb ./imlib2_convert
GNU gdb 6.1.1 [FreeBSD]
....
This GDB was configured as "i386-marcel-freebsd"...
(gdb) list
1       /* standard headers */
2       #include <X11/Xlib.h>
3       #include <Imlib2.h>
4       #include <stdio.h>
5       #include <string.h>
6       #include <stdlib.h>
7
8       /* main program */
9       int main(int argc, char **argv)
10      {
(gdb) break main
Breakpoint 1 at 0x80486c0: file imlib2_convert.c, line 10.
(gdb) run ./prueba.xpm ./prueba.png
Starting program: /usr/home/Anon/imlib2_convert ./prueba.xpm ./prueba.png

Breakpoint 1, main (argc=Error accessing memory address 0x0: Bad address.
) at imlib2_convert.c:10
10      {
(gdb) step
main (argc=3, argv=0xbfbfec9c) at imlib2_convert.c:15
15        if (argc != 3) exit(1);
(gdb) step
17        image = imlib_load_image(argv[1]);
(gdb) step
19        if (image)
(gdb) step
23            imlib_context_set_image(image);
(gdb)
26            tmp = strrchr(argv[2], '.');
(gdb)
27              printf("extensión: %s\n",tmp);
(gdb)
extensión: .png
28            if(tmp)
(gdb)
29               imlib_image_set_format(tmp + 1);
(gdb)
31            imlib_save_image(argv[2]);
(gdb)
36      }
(gdb)
0x08048649 in _start ()
(gdb)
Single stepping until exit from function _start,
which has no line number information.

Program exited with code 0200.
(gdb) quit


Bueno no entro a la funcion deseada debido al funcionamiento de step, pero igual tratemos de nuevo

:S la cosa se complica, vere a donde llego con esto y si veo que de plano es muy complicado, agrego la informacion de las librerias imlib2
Citar
(gdb) disas imlib_load_image
Dump of assembler code for function imlib_load_image:
0x2808cbe0 <imlib_load_image+0>:        push   %ebp
0x2808cbe1 <imlib_load_image+1>:        mov    %esp,%ebp
.....
0x2808cc3e <imlib_load_image+94>:       call   0x280a1190 <__imlib_LoadImage>
....
0x2808cc56 <imlib_load_image+118>:      mov    0xfffffffc(%ebp),%edi
0x2808cc59 <imlib_load_image+121>:      mov    %ebp,%esp
0x2808cc5b <imlib_load_image+123>:      pop    %ebp
0x2808cc5c <imlib_load_image+124>:      ret
....
End of assembler dump.

Interesante: __imlib_LoadImage

Existe esta subfuncion que carga la imagen.. pero ya la vi y son como 1000 Lineas de ensamblador xD asi que mejor no.

Bien, compilado todo con opciones -ggdb tanto el programa de ejemplo como la libreria imlib2


Citar
%cc -ggdb -static imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
%gdb ./imlib2_convert>

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) list
1       /* standard headers */
2       #include <X11/Xlib.h>
3       #include <Imlib2.h>
4       #include <stdio.h>
5       #include <string.h>
6       #include <stdlib.h>
7
8       /* main program */
9       int main(int argc, char **argv)
10      {
(gdb)
11        /* an image handle */
12        Imlib_Image image;
13
14        /* if we provided < 2 arguments after the command - exit */
15        if (argc != 3) exit(1);
16        /* load the image */
17        image = imlib_load_image(argv[1]);
18        /* if the load was successful */
19        if (image)
20          {
(gdb) break 13
Breakpoint 1 at 0x8048224: file imlib2_convert.c, line 13.
(gdb) run ./prueba.xpm ./prueba.png
Starting program: /usr/home/Anon/imlib2_convert ./prueba.xpm ./prueba.png

Breakpoint 1, main (argc=3, argv=0xbfbfec9c) at imlib2_convert.c:15
15        if (argc != 3) exit(1);
(gdb) step
17        image = imlib_load_image(argv[1]);
(gdb) step
imlib_load_image (file=0xbfbfedaa "./prueba.xpm") at api.c:1166
1166       CHECK_CONTEXT(ctx);
(gdb) step
1162    {
(gdb)
1166       CHECK_CONTEXT(ctx);
(gdb)
_imlib_context_get () at api.c:217
217        context = imlib_context_new();

Detengo un poco a la ejecucion para buscar api.c y ver quien es la variable ctx, despues de indagar en todo api.c no veo donde define ctx pero puedeo inferir que se trata de un apuntador a Imlib_Image
Siguiendo con la depuracion vemos hasta donde llega, ahorita solo me interesa saber si el ejemplo que estamos usando, llega a llamar a la funcion load del archivo loader_xpm.c y si esto es asi sabremos
que vamos por buen camino :D



Citar
(gdb) step
imlib_context_new () at api.c:171
171        ImlibContext       *context = malloc(sizeof(ImlibContext));
(gdb)
181        context->anti_alias = 1;
(gdb)
182        context->dither = 0;
(gdb)
183        context->blend = 1;
(gdb)
184        context->color_modifier = NULL;
(gdb)
185        context->operation = IMLIB_OP_COPY;

Cientos de Instrucciones mas y al parecer es, pero creo que no se parace la funcion pero esta pertecene al archivo image.c y la que buscamos es del loader_xpm.c

Citar
(gdb)
__imlib_LoadImage (file=0xbfbfedaa "./prueba.xpm", progress=0, progress_granularity=0 '\0', immediate_load=0 '\0',
    dont_cache=0 '\0', er=0x0) at image.c:979
979        if ((im) && (IMAGE_IS_VALID(im)))
(gdb)
975        im = __imlib_FindCachedImage(file);
(gdb)
979        if ((im) && (IMAGE_IS_VALID(im)))

Despues de unas 2000 Instrucciones queda solo una salida Inesperada

Citar
(gdb)
320        free(l);
(gdb)
322     }
(gdb)
__imlib_FileFreeDirList (l=0xbfbfeba8, num=Variable "num" is not available.
) at file.c:320
320        free(l);
(gdb)
Error

Program exited with code 012.

Jaja que cosas pasan xD ya se voy a editar el archivo loader_xpm.c para en caso de que si se mande a llamar Solo mando un "OK loader :)\n"

Depues de realizar la modificacion xD,vi que no dunciono, o no lo carga el moduo vulnerable:

Citar
%cc -ggdb -static imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
%./imlib2_convert ./prueba.xpm ./prueba.png
Error
%cc imlib2_convert.c -o imlib2_convert `imlib2-config --cflags` `imlib2-config --libs`
%./imlib2_convert ./prueba.xpm ./prueba.png
extensión: .png

No se por que pero si lo compilo con los argumentos -ggdb -static simplemente no lo hace y se le compilo normal si hace lo pedido.

Entonces tendre que mandarle yo mismo el archivo, asi sirve que no paso por tanto filtros. Sin embargo eso sera otro dia.

miércoles, 3 de diciembre de 2008

FreeBSD: Problema con imlib2-1.4.1.000 (Solucion)

Bien, instalando enlightenment, me sale el error de la dependia antes mencionada,  imlib2-1.4.1.000, esto desde los ports

Citar
# cd /usr/ports/graphics/imlib2
# make
===>  imlib2-1.4.1.000,2 has known vulnerabilities:
=> imlib2 -- XPM processing buffer overflow vulnerability.
   Reference: <http://www.FreeBSD.org/ports/portaudit/910486d5-ba4d-11dd-8f23-0019666436c2.html>
=> Please update your ports tree and try again.
*** Error code 1

Stop in /usr/ports/graphics/imlib2.
*** Error code 1

Stop in /usr/ports/graphics/imlib2.

Version del sistema:

Código:
# uname -a
FreeBSD  7.0-RELEASE FreeBSD 7.0-RELEASE #2: Mon Nov 24 09:02:58 UTC 2008     root@:/usr/src/sys/i386/compile/VGN-N350  i386


Ahora El problema no es que no la pueda instalar, dice que es un problema de seguridad:
Citar
imlib2 -- XPM processing buffer overflow vulnerability.
   Reference: <http://www.FreeBSD.org/ports/portaudit/910486d5-ba4d-11dd-8f23-0019666436c2.html>

Si me voy a la pagina de los ports, vemos que ya esta actualizado el make file

http://www.freebsd.org/cgi/cvsweb.cgi/ports/graphics/imlib2/

Citar
- Fix a buffer overflow vulnerability in imlib2. PR: ports/129037 Submitted by...


La informacion acerca del bug esta en

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505714
http://www.freebsd.org/cgi/query-pr.cgi?pr=129037


Aqui muestrare como instalar correctamente Imlib2 desde los pors de FreeBSD.

En otro post se agrergara como Testear la Vulnerabilidad.

Primero hare una copia de seguridad del Directorio imlib2 dentro de /usr/ports/graphics/

Nota que esto yo lo realizo para posterior analisis.

Citar
# tar cf imlib2.tar imlib2/
# bzip2 -k9 imlib2.tar
# rm imlib2.tar
# ls -Gla imlib*.*
-rw-r--r--  1 root  100   2360 Dec  3 11:06 imlib2.tar.bz2

Aqui debemos borrar el directorio imlib2

Código:
#rm -r imlib2/

Descargamos el Tarball del directorio del port de
http://www.freebsd.org/cgi/cvsweb.cgi/ports/graphics/imlib2/imlib2.tar.gz?tarball=1

Descomprimimos

Código:
# tar xvf imlib2.tar.gz
# cd imlib2
# make && make install


Y ahora si podemos ir al directorio de enlightenment y continuar su instalacion.

;) saludos y espero a alguien le sirva

lunes, 1 de diciembre de 2008

En Windows Vista el cliente de telnet no está instalado por defecto. Si queremos usarlo tendremos que marcarlo en Inicio -> Panel de Control -> Programas -> Activar o desactivar las características de Windows.

Ahi buscamos en la lista Telnet u algun otro cliente que queramos.

Esto lo menciono por que se me ha hecho muy dificil poner NC en algunas computadoras por los antivirus.

En sistemas Unix/Linux el NC viene generalmente de forma predeterminada.

domingo, 16 de noviembre de 2008

Torneo de explotacion de servidores

Sabemos que muchos de ustedes querian explotar vulnerabilidades en aplicaciones binarias, como buffer overflows, heap overflows, etc..asi tambien nos han pedido pruebas de vulnerar un servidor.

En fin, creemos eso es una buena idea, pero no podemos montar tales pruebas en un servidor nuestro por seguridad, y no lo podemos virtualizar, por rendimiento.. asi que Anon organizara un wargame de este tipo, y le pedi que si podia hacernos el favor de organizarlo para los usuarios de warzone, y dijo que si! entonces..

El dia Sabado 29 de Noviembre del 2008 a media noche, horario GMT (Meridiano de Greenwich/Casablanca), 6:00 pm en la ciudad de mexico (GMT-6), 9:00pm en Buenos Aires (GMT-3), 1:00 am en Madrid (GMT+1), se publicara en warzone una prueba en la cual los usuarios podran obtener la direccion del wargame, junto con sus datos de inicio de sesion.

El objetivo sera ir pasando desde 4 niveles, explotando vulnerabilidades en los ejecutables dentro del mismo, permisos, etcetera.

Los primeros 5 que pasen la prueba, se les daran 30 puntos en warzone, asi como una promocion de 2 rangos (maximo rango: elite, los que ya esten en elite, pasaran a nightmare.), una cuenta de correo @elhacker.net, asi como acceso a todos sus servicios.

Los siguientes 5, recibiran 15 puntos en warzone, una promocion de 1 rango (no podran pasar a nightmare, los elite).

Todos los demas que pasen la prueba, tendran 10 puntos en warzone, sin promocion de rango.

Hay bonos:
> Modificar el MOTD agregando su nick.
- 20 puntos
> Menor tiempo en pasarlo
- 15 puntos
> Mejor documentacion de como pasarlo*
- 15 puntos (+ cuenta @elhacker.net si no la tienen ya)
* Esta debe ser enviada de forma privada, se le daran los creditos al autor.
> Posiblemente mas, dependiendo de como se desenvuelva el torneo.

El wargame estara online 10 dias, pero podria estar mas tiempo.

En fin, esperamos contar con su presencia! les prometo sera divertido.. mas detalles de la prueba se colocaran en cuanto se acerque la fecha.

Saludos!!

Discutir aqui: http://foro.elhacker.net/warzone/torneo_de_explotacion_de_servidores-t235190.0.html

sábado, 25 de octubre de 2008

Ataques a la implementacion de TCP _ Outpost24

Bien, he estado leyendo sobre el tema, sinceramente les comento que no tengo mucho de haberme enterado de este nuevo DoS en la Pila de TCP ya confirmado por Cisco, que al parecer va a afectar a la mayoría de las implementaciones, Windows, Unix, IOS, ... etc.

Viendo que hay muchos enlaces sin referenciar, hay que agregar el enlace con la información mas Ordenada que es el de fyodor:

http://insecure.org/stf/tcp-dos-attack-explained.html

Ahora la ultima noticia sobre esto marca a Cisco el día 17 donde publica un reporte de alerta de Seguridad Nivel 3 "Sockstress Exploit Tool Exposes Vulnerabilities in TCP Stack Implementations of Multiple Vendors"

También se puede ver que ya tiene su propio CVE: CVE-2008-4609

Bien, pero lo anterior son noticias que ya estaban publicadas y solo se agregan como referencia de lecturas. Ok, el principal punto de partida es la SockStress que usa Cisco, para dar credibilidad a las múltiples Vulnerabilidades en la Pila TCP, bien como menciono sdc se ocupa tener conocimiento de la Pila TCP, los cuales son aportados por sus respectivos RFC’s, Ahora si las vulnerabilidades existen, que ya cisco ha comprobado que si, estas están ahí, en la mayoría de los sistemas Operativos, esto desde hace mucho tiempo.

Buscando en referencias libres (No propietarias) he estado analizado en el código fuente de linux dentro de los archivos tcp.c entre otros, prestando especial atención a los comentarios, he notado algunos comentarios, como que hay que tener cuidado con el tamaño del Window, y otras cosas mas. La verdad no he dado con nada En especifico, pero se que debe de estar ahí, listo para ser encontrado.

Espero que alguien que conozca mas sobre la Pila de TCP nos de una idea mas clara de que estamos buscando y en donde.

Saludos y gracias de antemano por cualquier aporte útil

lunes, 11 de febrero de 2008

Ataques DDoS un Fastidio

Recientemente he leido demasiadas Noticias sobre DDoS y demas, la verdad yo veo estos ataques como un acto de una persona sin Cerebro que lo unico que sabe hacer es Quitar el servicio con sus Estupidos Zombies. Me importa un Comino que sepa Mucho o Poco.

Aqui unos Link sobre lo sucedido:

http://www.error500.net/ataques-ddos-error500

http://www.weblogssl.com/2008/02/07-ataque-de-ddos-a-genbeta

http://blog.meneame.net/2008/02/08/problemas-de-red/

Ahora la comunidad Hacker preocupada y preguntandose como puede ayudar.

http://foro.elhacker.net/index.php/topic,199416.0.html

Ahora sobre seguridad


Citar:
Ya descubrimos bien el tipo de ataque, flood UDP a puertos aleatorios. Hablé con Vicente, procederán a cerrar esos puertos.

Bueno, en parte paquetes UDP, lo cual solucionaron bloqueando los puertos inecesarios.

Citar:
El ataque se hizo desde servidores con Joomla y phpBB, explotaron un bug viejo y conocido que permite incluir ficheros PHP externos.

Ok, estar al dia con las Actualizaciones de seguidad es Basico ya que no queremos estar en la lista de los Zombies Usados como en el ataque anterior. Estar siempre al dia y en contacto con nuestro administrador es Fundamental.

domingo, 10 de febrero de 2008

Re: BoF en inet_network(), afecta a Servidor DNS: BIND

Bien este sera mi ultimo mensaje en este Topic, referente al estudio de este bug, después solo contestare dudas y comentarios.

¿Por que?

Por que debido a que la función en C, es muy Rápida/Eficiente debido a su corto código y gran manejo avanzado de C, genera un código en ensamblador muy Óptimo. Debido a esto y lo poco descubierto hasta ahora, el rendimiento de cualquier aplicacion que use inet_network() como BIND en este caso, no se va a ver tan afectado en gran medida, al menos que se use a manera DDoS o teniendo un gran ancho de Banda puede ser posible.

Sin embargo escribir un exploit/aplicacion que realize el esto se me hace muy Lamer.

Lo ideal seria crear un exploit para obtener acceso al servidor mediante un remote shell o algo parecido, sin embargo como no fue posible encontrar una manera de corromper la pila, tampoco es posible crear el exploit.

Ahora que si alguien quiere realizar dicho exploit/aplicacion solo por practica/conocimiento/interés contra un servidor del cual sea dueño. aquí y en los link presentados esta toda la información necesaria para realizarlo, bueno aparte de sus conocimientos de programacion.

Doy por concluida mi participacion en este tema ya que le he dedicado mucho tiempo en analizar el código, ya me lo se de memoria tongue y se me a hecho infructuoso cumplir mi cometido de realizar un exploit para la función inet_network() vulnerable, sin embargo me queda la satisfacción de haber encontrado una debilidad al código de la función el cual puede representar un pequeño consumo del procesador en cualquier aplicacion que utilice la función mencionada.

Cualquier duda y/o comentario favor de ponerlo en este topic.

Un especial agradecimiento a todos aquellos que me apoyaron en el Topic y por PM Gracias!!

Un saludo a todos.

miércoles, 6 de febrero de 2008

Re: BoF en inet_network(), afecta a Servidor DNS: BIND

Bueno volviendo al tema del Estudio de un bug, y posteriormente el la Creacion de un exploit para el mismo. Lamento informarles que no he dado con nada en este bug pero bueno.

Si nos consentramos en lo que sabemos, lo unico que cambio en la version vulnerable del codigo es que el siguiente fracmento de Cofigo cambio de lugar:
Código
 if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);

De adentro del if, a afuera del mismo:

Version Vulnerable
Código
 if (!digit)
return (INADDR_NONE);
if (*cp == '.') {
if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);
*pp++ = val, cp++;
goto again;


Version NO Vulnerable
Código
 if (!digit)
return (INADDR_NONE);
if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);
if (*cp == '.') {
*pp++ = val, cp++;
goto again;

Ok, aqui lo importante es preguntarnos como cambia el funcionamiento del programa Antes y despues huh.

Bien segun lo he analizado mientras voy en en el camion, mientras como, y hasta mientras sueño el resultado operativo del codigo sigue siendo el mismo, si no es asi que alguien me lo haga saber y me diga lo ciego que estoy.

Lo unico que noto es que el Procesador se ahorra unas cuantas Instrucciones en caso de que la la Condicion del if sea verdadera, en caso contrareo Todo trabaja Igual. rolleyes o no huh

Bueno hasta el momento hago un recuento de lo que he Conseguido hasta el momento.

Es posible Insertarle un valor Invalido para Obtener un Resultado Valido:

Bueno entre las pruebas que estuve haciendo he visto que la aplicacion que tengo de prueba puede recivir cadenas como las que siguen sin colgarse:

Código:
%./test_network 0xfffff00000011.0xfabcd000000003.0xa.0x90
0x11030a90

pero no nos ganamos nada ya que no ponemos nada en la memoria, las ffff se pierden en el corrimiento de bits hacia la izquierda dentro del microprocesador. sad

Lo cual puede representar un consumo de recursos en el servidor BIND, o el programa que use la funcion inet_network() vulnerale esto solo en caso de que se le envie constantememente cadenas Invalidas como las que mostre obviamente de mayor longitud ya que el Procesador tendria que estar dentro del mismo ciclo mientras le manden estas cadenas.



Un saludo!!

martes, 29 de enero de 2008

Re: BoF en inet_network(), afecta a Servidor DNS: BIND

Bien, primero pense que era la variable "val", que sumada al corrimiento de bits que se le hace, podia sobre escribir en la memoria asi que me puse un ejemplo para ver si servia:

Código
int main() {
unsigned long prueba;
long i;
prueba = 0xf;
i = 0;
while(i < 20) {
printf("Prueba: %i\n",prueba);
i++;
prueba = (prueba << 4) + 0xf;
}
return 0;
}

sin embargo no fue asi, me acorde que el corrimiento de Bits se hace en el microprocesador, y el resultado va a la RAM, (Claro que si la variable es register no es asi). cry estoy medio perdido.

Por ahi he oido que los BoF del tipo Off-By-One no son explotables, sin embargo tambien he visto ejemplos en casos donde tienes algo de control del entorno (local) y las condiciones del BoF son casi Optimas, digamos pila Bien alineada capacidad de meter el shell y etc.. el xploit si puede ser posible.

Esto solo me interesa por el reto de poder hacer que una aplicacion Ejecute tu codigo por gusto memeramente educativo. grin

Bueno entre las pruebas que estuve haciendo he visto que la aplicacion que tengo de prueba puede recivir cadenas como las que siguen sin colgarse:

Código:
%./test_network 0xfffff00000011.0xfabcd000000003.0xa.0x90
0x11030a90

pero no nos ganamos nada ya que no ponemos nada en la memoria, las ffff se pierden en el corrimiento de bits hacia la izquierda dentro del microprocesador. sad

Un saludo!!

lunes, 28 de enero de 2008

Re: BoF en inet_network(), afecta a Servidor DNS: BIND

En la pagina de BIND: BIND Vulnerabilities


Impact:

Applications linked against libbind which call inet_network() with untrusted inputs could lead to a denial-of-service or potentially code execution.

Note that none of the applications shipped with BIND 8 or BIND 9 call inet_network().


Veamos La pagina nos dice nuevamente lo mismo Podemos hacer un DoS al servidor BIND, o podemos ejecutar codigo arbitrareo en el equipo que aloja el servidor.


Ahora

Código:
Index: inet_network.c
diff -u inet_network.c:1.5 inet_network.c:1.6
--- inet_network.c:1.5 Wed Apr 27 04:56:21 2005
+++ inet_network.c Tue Jan 15 04:02:01 2008
@@ -84,9 +84,9 @@
}
if (!digit)
return (INADDR_NONE);
+ if (pp >= parts + 4 || val > 0xffU)
+ return (INADDR_NONE);
if (*cp == '.') {
- if (pp >= parts + 4 || val > 0xffU)
- return (INADDR_NONE);
*pp++ = val, cp++;
goto again;
}

Viendo las diferencias vemos que la version, 1.5 del archivo vulnerable es casi exactamente lo mismo solo movieron de lugar la siguiente Intruccion:

Código
 if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);

En la version Vulnerable esta dentro del if (*cp == '.') y la version NO vulnerable esta afuera antes de if (*cp == '.'), lo cual me indica que la clave de esto debe estar en saber manejar el formato de entrada con los Puntos '.'. Ya me he impreso el codigo fuente vulnerable y lo estoy analizando paso por paso, ya que no he podido encontrar un input que vulnere el codigo.

viernes, 25 de enero de 2008

BoF en inet_network(), afecta a Servidor DNS: BIND

Bien, recientemente he empesado a ver en la lista de SECURITY ADVISORIES de FreeBSD, la cual normalmente no veia, sin embargo quiero ser un buen adminsitrador del sistema que utilizo. wink y estar al dia con las actulizaciones grin. he visto que hay algunos bugs, ya descubiertos con todo y parche. Obviamente anuncian esto cuando ya se tiene el parche tongue, pero bueno el Motivo de este mensaje es el siguente:

Ver si somos o mas bien soy capaz de construir un exploit para dicha Vulnerabilidad, he hecho exploits para programas sencillos, y BoF bien ubicados, pero de ahi en mas no lo he hecho con aplicaciones complejas.

Por si alguien me quiere ayudar... se lo agradecere de antemano.



Bien los link de bug que me intereso son los siguentes:


Ahora para los que no sepen y quieran enterarse, BIND, es un Servidor DNS muy extendido hoy en dia, con la ayuda de este, ustedes pueden entrar a google, o al foro.

Mas informacion en BIND by Wikipedia

La funcion donde se encuentra la falla, es una funcion estandar en libc, esto quiere decir y por si no vieron los primeros Links, FreeBSD no es el unico Afectado por esto, tambien hay muchas Versiones de Linux, UNIX, etc. Y ademas todas las versiones del Servidor BIND, hasta ultima version de 22/01/2008.

La pagina de BIND, considera esto como un Riesgo de Seguridad Bajo, y tienen Razon, el parche ya existe, pero cuantos son los Administradores de Sistemas (me Incluyo) que pocas veces (si no es que ninguna) han aplicado parches de seguridad.

La falla Esta en la funcion inet_network(), la cual es usada por BIND.

he hecho un archivo para testearla, pero no consigo burlarla, pero bueno ya que, aqui esta mi codigo de test, creo yo que asi se puede testear. que alguien con mas experiencia me corrija si es que me equivoco.

test_network.c
Código
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(int argc,char *argv[]) {
char *host = (argc > 1) ? argv[1] : "192.168.0.1";
in_addr_t net = inet_network(host);
printf("0x%x\n",net);
return 0;
}

Ahora, todos los links que mostre muestran que si tratas de explotar dicho bug, y fallas ocacionarias un DoS a los usuarios legitimos del servidor. Pero si das en el punto exacto podras ejecutar codigo arbitrario en la maquina remota. lo cual te puede permitir el acceso al servidor.

Successfully exploiting this issue may allow attackers to execute arbitrary machine code in the context of applications that use the affected library. Failed exploit attempts may crash applications, denying service to legitimate users.

He instaldo el servidor BIND en una maquina de prueba para ir probando los avances en la aplicacion mas Afectada por este BoF.



Bien ahora estoy analizando la funcion Vulnerable, cabe mencionar que es casi la misma en mi sistema FreeBSD que la que trae incluida el Servidor BIND.

Código
u_long
inet_network(cp)
register const char *cp;
{
register u_long val, base, n, i;
register char c;
u_long parts[4], *pp = parts;
int digit;

again:
val = 0; base = 10; digit = 0;
if (*cp == '0')
digit = 1, base = 8, cp++;
if (*cp == 'x' || *cp == 'X')
base = 16, cp++;
while ((c = *cp) != 0) {
if (isdigit((unsigned char)c)) {
if (base == 8U && (c == '8' || c == '9'))
return (INADDR_NONE);
val = (val * base) + (c - '0');
cp++;
digit = 1;
continue;
}
if (base == 16U && isxdigit((unsigned char)c)) {
val = (val << 4) +
(c + 10 - (islower((unsigned char)c) ? 'a' : 'A'));
cp++;
digit = 1;
continue;
}
break;
}
if (!digit)
return (INADDR_NONE);
if (*cp == '.') {
if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);
*pp++ = val, cp++;
goto again;
}
if (*cp && !isspace(*cp&0xff))
return (INADDR_NONE);
*pp++ = val;
n = pp - parts;
if (n > 4U)
return (INADDR_NONE);
for (val = 0, i = 0; i < n; i++) {
val <<= 8;
val |= parts[i] & 0xff;
}
return (val);
}

Lo que he hecho es lo siguiente.
  • Instalar BIND en la Computadora de prueba con la opcion -g
Esto es para mayor depuracion del mismo.
  • Active la creacion de archivos core en el sistema de prueba
Esto es por si la aplicacione se llega a caer en alguna de las pruebas, poder analizar esto mejor.
  • Agregar a mi ejemplo test_network.c, la funcion Vulnerable.
La agrege con otro nombre esto para poderlo compilar con la opcion -g -static para poder depurarlo sin tener que terner el server abierto.

Asi mi codigo para testear la funcion vulnerable queda asi.

Código
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

in_addr_t inet_networkbuf(const char *cp);

int main(int argc,char *argv[]) {
char *host = (argc > 1) ? argv[1] : "192.168.0.1";
in_addr_t net = inet_networkbuf(host);
printf("0x%x\n",net);
return 0;
}

in_addr_t
inet_networkbuf(cp)
const char *cp;
{
in_addr_t val, base, n;
char c;
in_addr_t parts[4], *pp = parts;
int i, digit;

again:
val = 0; base = 10; digit = 0;
if (*cp == '0')
digit = 1, base = 8, cp++;
if (*cp == 'x' || *cp == 'X')
base = 16, cp++;
while ((c = *cp) != 0) {
if (isdigit((unsigned char)c)) {
if (base == 8U && (c == '8' || c == '9'))
return (INADDR_NONE);
val = (val * base) + (c - '0');
cp++;
digit = 1;
continue;
}
if (base == 16U && isxdigit((unsigned char)c)) {
val = (val << 4) +
(c + 10 - (islower((unsigned char)c) ? 'a' : 'A'));
cp++;
digit = 1;
continue;
}
break;
}
if (!digit)
return (INADDR_NONE);
if (*cp == '.') {
if (pp >= parts + 4 || val > 0xffU)
return (INADDR_NONE);
*pp++ = val, cp++;
goto again;
}
if (*cp && !isspace(*cp&0xff))
return (INADDR_NONE);
*pp++ = val;
n = pp - parts;
if (n > 4U)
return (INADDR_NONE);
for (val = 0, i = 0; i < n; i++) {
val <<= 8;
val |= parts[i] & 0xff;
}
return (val);
}

Como vemos la unica diferencia entre la funcion existemente en FreeBSD y la del Servidor BIND, es que BIND declara las variables mas utilizadas como register, esto es para que sea mas efeciente. Lo cual me da a entender que va a ser un poco diferente la Explotacion de la funcion inet_network(), dentro de aplicaciones comunes de FreeBSD, que la del Servidor BIND.

Populares Siempre