¿QUÉ ES UN DESBORDAMIENTO DE BUFFER?
Estos días ha saltado a la opinión pública una serie de errores provocados por desbordamiento de buffer (buffer overflow) los cuales permitian o bien a un atacante remoto, o bien a gusanos / virus (Blaster, por ejemplo) que usan dicha vulnerabilidad el tomar control absoluto de nuestra máquina.
"desbordamiento de buffer" es una de las frases que muchas veces asumimos sin preguntar -aunque solo sea en plan curiosidad-, que es lo significa. En el presente articulo, creado para neofitos en informatica vamos a intentar clarificar este concepto, que es lo que realmente significa, y el porqué sucede. Esto es inherente a cualquier sistema operativo, por lo que no es exclusivo de Microsoft.
Vamos a utilizar en varios puntos de este articulo la palabra "exploit". Un exploit no es nada mas que una manera, o un codigo, o lo que sea, de manejar una vulnerabilidad para tomar el control de una máquina, o bien para hacerla malfuncionar y provocar la caída de sus servicios.
¿COMO FUNCIONA UN PROGRAMA?
Un programa, tiene su area de codigo ejecutable, y usa en memoria un espacio para almacenamiento del propio codigo y tambien para almacenamiento de los datos que vaya a utilizar. Igualmente, si el programa recibe parametros o datos, debe guardarlos temporalmente en memoria.
Por ejemplo, imaginemos un programa servidor de paginas web. Cuando el usuario teclea en un navegador:
http://www.microsoft.com/directx, el texto tecleado: www.microsoft.com/directx viaja como dato al servidor web de Microsoft. Dicho servido es un programa que recibe ese texto, y que tiene que almacerlo en memoria.
Imaginemos que desde nuestro navegador, podemos teclear lo que queramos sin tener un tamaño maximo para escribir. Es decir que tecleamos
http://www.microsoft.com/xxxxxx y el texto que ponemos en las xxxxx es enorme. Pongamos que enviamos 10.000 caracteres... a ver que pasa.
Si el programa servidor que se está ejecutando en los servidores de Microsoft, no tiene presente que pueda recibir toda esta cantidad de datos y el programador que lo ha realizado ha previsto solo una cantidad, digamos razonable de 1000 caracteres, el propio programa al intentar guardarse esos 10.000 caracteres, está "machacando" areas de memoria que pueden ser de contenido de otros datos (en cuyo caso se machacan) o incluso de codigo ejecutable del propio servidor. En cualquier caso, hay destruccion de informacion que provocarán en el mejor de los casos o un malfuncionamiento, o lo mas probable una "caída" del programar servidor web por machacarse parte de su propio codigo.
Evidentemente, la solucion pasaría por comprobar el tamaño tecleado antes de moverlo a zonas de memoria.
Este es un caso muy sencillo y muy simplificado, pero nos puede servir como idea de lo que sucede. Generalicemos un poco: un programa, se descompone en funciones. Dicho programa recibe parametros o datos, se los guardan, y se lo pasa al resto de funciones o subprogramas que lo necesiten.
El problema es cuando el propio programa o los propios subprogromas o funciones, tiene reservados tamaños inferiores de la longitud de los datos que reciben. La solucion, por supuesto, es que cada programa, funcion, modulo, librería, DLL, ect no se fie de nadie y verifique exhaustivamente todo antes de tomar ninguna accion y ni tan siquiera guardarlo en memoria.
Normalmente, los controles anteriores no se hacen excepto en entrada de datos, y es debido a que esto implica sobrecargar excesivamente de codigo de comprobacion, y en tiempo de ejecucion todos los parametros y todas las zonas de memoria a las que accede el programa.
El problema surge, cuando muchas de las funciones diseñadas para ejecutarse internamente y que no tienen controles de los parametros, deciden reutilizarse en otros programas de nivel superior los cuales pueden no tener tampoco dichos controles. En este caso, y aunque su funcionamiento sea normal, pueden encontrarse situaciones en que alguien malintencionado lo descubra y decida "explotar" esta vulnerabilidad. Es vulnerable un programa desde el momento en que somo capaces de hacerlo "cascar". Si somos capaces de ello, tambien seremos capaces de hacer lo que queramos: es decir de tomar control de él. Veremos un poco más adelante y de una manera sencilla, el como.
VIENDO UN POCO DEL DIAGRAMA DE CAPAS DE EJECUCION
-
Continúamos con el ejemplo sel servidor web anterior. Aunuqe nos estamos ciñendo a un servidor web, pensemos que en nuestras maquinas hay muchos pequeños, llamesmoles, micro-servidores, es decir, programas, rutinas, funciones que están a la espera que alguien les active, o a la espera de recibir datos. El ejemplo del servidor web que estamos viendo, no deja de ser anecdotico, sino que además describe una vulnerabilidad real que ha existido en los servidores y que en su día (hace unos años) fue explotada con exito por el mundo hacker.
Veamos muy por encima las capas que componen un servidor web, o mejor, veamos que sucede desde que hacemos una peticion de una URL (direccion de internet) hasta que el servidor nos devuelve datos.
Primero, existe una serie de capas del tcp/ip que reciben los mensajes. Estas capas lo que hacen es pasarlo al sigueinte nivel. En nuestro caso, al punto de entrada de los datos del servidor web. Este a su vez, analiza completo el mensaje solicitado. Pensemos que una URL pueden viajar muchas cosas: usuario / password, la maquina que lo va ejecutar, y en el contenido de la URL, la pagina, o incluso instrucciones de ejecucion. Por ello, si nos fijamos nos podemos encontrar URL's larguísimas que están enviando instrucciones al servidor.
Este a su vez, está compuesto por modulos o capas: por ejemplo, un modulo para autenticar al usuario si este fuese en el mensaje, otro, por ejmplo, para nalaizar el literal del mensaje y si se encuentra instrucciones que entiende como de jecucion, pasarselo al modulo ejecutivo, etc. al final, si todo es correcto, se construye la pagina o se muestra directamente una pagina almacenada y se envía. Pero lo importante, es que se ha llamado, pasando los datos tecleados por nosotros a un monton de programas y modulos. Si cualquiera de estos no tiene previsto un analisis detallado de la URL, o en algun caso falla al analizarlo en este sentido,. se provocará probablemente un desbordamiento de buffer: un machaque de areas de memoria que llevaran al programa a caerse casi con toda probabilidad.
EL ATAQUE
Si un hacker, en algun momento, consigue en este ejemplo hacer que un servidor se caiga por enviar una URL inválida.. ya tiene todo resuelto. Si es capaz de hacer "cascar" al programa servidor, tambien será capaz de enviar dentro de la URL código ejecutable en unas posiciones muy determinadas de la URL. Si este "trozo" de codigo enviado entra en ejecucion, ya tenemos el "exploit". Es decir, antes que el servidor se "caiga", habrá ejecutado un codigo dejado por el hacker.
Este codigo puede hacer cualquier cosa: si el hacker ha tenido la imaginacion y ha sido capaz de realizar pruebas para encontrar un agujero que antes no se le había ocurrido a nadie, ni al programador, ni al equipo de programacion, ni tan siquiera al equipo de pruebas, y que posiblemente lleve oculto años sin que haya sucedido nada, si ha tenido dicha imaginación está claro que tambien la tendrá ahora para saber que "codigo" nos va a "inyectar" en nuestra maquina. Estas inyecciones de codigo ya estan muy estudiadas por el mundo hacker. Estudiadas, realizadas y probadas: unicamente consiste ahora en buscar la vulnerabilidad para "inyectar" el codigo.
EL MUNDO HACKER
El mundo hacker se ha idealizado porque interesa mucho dicha idealización, y porque quizás los primeros hackers no perseguian fines claramente dañinos, sino simplemente la posibilidad de entrar en una maquina ajena, bien para usarla, o bien como un reto. Pero esto es una idealizacion.
Un hacker es un delincuente. Aunque dejemos la puerta de nuestra casa mal cerrada o por descuido abierta, si encontramos a alguein dentra de nuestra casa no será con fines "educativos" ¿no?. Pues bien, eso es lo que es un hacker: alguien que sin nuestro permiso entra en nuestra casa. Aunque no haga nada más que dejarnos un mensaje en el espejo del baño diciendo "he pasado por aquÍ", no creo que nos gustase mucho. Y es un delito.
Los hackers "buenos" o "eticos" no existen. Serán consultores de seguridad, expertos de seguridad, empresas de seguridad que venden sus servicios o su trabajo para evitar accesos no autorizados. Pero no serán hackers.
Dentro de este submundo de delincuentes existen los llamados script-kiddies (o niños script). Son simplemente gente sin conocimientos informaticos pero con ganas de hacer daño, o por sentirse importantes, o bien por ser graciosos (patetico). No saben informatica, pero aprenden de una manera mecanica a usar "exploits", codigo, o lo que sea, para entrar en una maquina. Tienen ademas muchas horas libres, por lo que unico que hacen, es de una manera rutinaria y sin saber lo que hacen, lanzar "scripts" o miniprogramas preparados para ir buscando maquinas potencialmente vulnerables. Es como llamar aleatoriamente a bloque enteros de numeros del listin telefonico, diciendo "Soy tu primo Juan". Antes o despues, alguién picará y se lo creerá realmente ya tenemos "al incauto".
Jose Manuel Tella Llop
MS MVP - DTS
jmtella@compuserve.com
Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Leer las respuestas