Me gustaría que me explicarais por qué el desbordamiento de búffer supone una vulnerabilidad tan grave en los programas como puedo leer casi a diario en un boletín de seguridad. ¿En qué consiste? ¿Por qué permite el acceso a datos ocultos o controlar remotamente?
Gracias.
Viendo que nadie dice nada, me aventuro a decir algo sin ser ni mucho menos un experto.
Más o menos las palabras lo indican. Un buffer es un lugar donde almacenar cosas. Por lo que no es más que conseguir que un programa almacene más información de la que cabe en uno de los buffers que esté utilizando (aunque sea una simple tabla o array). Si eso se produce, se accedería a una zona de memoria que no está reservada para almacenar dicha información, e incluso podría llegar a machacar otros datos que esté manejando el programa. Normalmente, las consecuencias de eso es el cuelgue del programa y la salida del mismo (a cualquiera le ha pasado esto mientras está realizando un programa). Sin embargo, ese fallo del programa manejado por alguien con la maestría suficiente y tras un estudio del mismo, podría llegar a conseguir que se ese programa ejecute un código distinto y amenazar de esta manera la seguridad del sistema.
Suele ser bastante común ver fallos de este tipo desbordando la pila del programa, que puede conseguirse al obligar al programa en cuestión a realizar sucesivas llamadas a funciones propias o del sistema. De esta manera, como la pila se usa (entre otras cosas) para almacenar datos al saltar a la ejecución de una función podría llegar a desbordarse. No sé si me he explicado bien.
Como bien has dicho es una de las vulnerabilidades más extendidas en las aplicaciones. Por ello, últimamente, en las aplicaciones Unix/Linux se tiende a que éstas ejecuten el menor número de líneas de código bajo la identidad de root. También cada día más aplicaciones permiten ser ejecutadas en jaulas (chroot) y han aparecido muchas aplicaciones para controlar el uso de memoría de otras aplicaciones (como el caso de softlimit de daemontools) para controlar los agotamientos de memoria.
Lo dicho, no es seguro 100% pero creo que no andaré muy mal encaminado si me estoy equivocando.
Salu2.
Buenas tardes
Yo tambien iba a postear pero no controlo demasiado la progamacion.
Yo siempre he entendido los overflow como un desbordamiento de pila controlado.
Que creo que es lo que hace, pero algo resumido... :-P
El caso es que iba a poner un link, creo que era de una pagina del tal fernad0, que te ponia un ejemplo buenisimo pero no la he encontrado :P.
A primera vista he encontrado una, ya que le he dado para postear el susodicho link y pongo este de suplente :).
(link roto)
Bueno ya se sabe que no es para FreeBSD sino para xavigonoso, que estamos los dos pelados :-).
Saludos
En memoria, un programa suele tener intercalado partes de codigo, con partes de datos, buffers etc.
entonces, si se da el caso siguiente
CODIGO
DATOS
CODIGO
BUFFER
CODIGO
DATOS
Si el programa no se asegura de que lo que va a meter en el buffer cabe en el espacio de memoria asignado a el, y se le pasan mas datos de los que caben en el buffer, el programa continua escribiendo despues de el y machacandose la parte de codigo que venia despues del buffer.
Entonces, si le mandas a el programa datos con la longitud del buffer + codigo y haces bien los calculos, puedes sobreescribir la parte de codigo que sigue al buffer, y cuando esta se ejecute por el programa (pensando que ese codigo es el mismo que habia antes del buffer overflow), lo que estara ejecutando sera tu codigo, no el del programa, si no el tuyo, si el programa tiene acceso como administrador, el codigo tuyo se ejecutara como tal, asi que solo con eso ya puedes tener las puertas abiertas de par en par.
Un saludo.
P.D.
Bueno, no demasiado resumido pero lo he intentado.
Me has iluminado, tio.
Yo tb estaba un poko mosca con eso del buffer overflow, pk lo habia leído en varias paginas de hacking y seguridad y no tenia ni idea de ke significaba.
P.D.: Mola la firma :-P
Me has dado una alegria, yo suelo tener bastante claro lo que posteo, pero como profesor no valgo gran cosa, una cosa es entender algo y otra muy distinta conseguir explicarselo a alguien y que lo comprenda en la misma medida.
Asi que normalmente no tengo muy claro si consigo que se entiendan las cosas cuando intento explicarlas.
Un saludo.
Pues intentaba decir lo mismo pero a ti te ha quedado más claro, un 10 ;-) .
Yo no estaba muy seguro de lo que estaba diciendo, pero si los dos pensamos así hay bastantes posibilidades de que estemos en lo cierto. Sólo una pregunta que espero que no te moleste, stendall: ¿por qué no lo has posteado antes si lo sabías? ¿o te pasaba como a mi que no estabas muy seguro? Es una curisidad tonta, ya lo sé.
Salu2.
No lo he posteado antes por que no estaba en casa, he estado toda la tarde en casa de un amigo montandole un ordenador nuevo que se ha comprado, instalandole todo etc, y lo he posteado cuando he llegado a casa y lo he leido.
Vamos, que no es que no haya contestado antes por que esperase que alguien lo hiciese antes ni ninguna cosa por el estilo, nomalmente posteo cuando veo que sé algo de lo que se pregunta y lo suelo hacer en el momento.
Un saludo.
P.D.
Por cierto, que no me ha parecido mala tu explicacion para nada, y creo que no merezco el 10 :), para una cosa que parece que explico y alguien entiende, hago otras 10 que no las entiendo ni yo :P.
Ya q te has animado te invito a que me ayudes en el foro de Hardware (quizás lo tenía que haber puesto en el de Windows XP) en el post "Problemas con tarjeta de puertos USB 2.0 PCI". jejejeje :-D
Por fin he pillado lo de " por que pasaba de mi" :), para nada, si no contesto a algo solo puede ser por dos motivos, que no sepa nada del tema, o que no lo haya leido.
Anda no me seas lloron a estas alturas, y mucho menos me digas que paso de ti despues de toda la historia del Zone y similares :)
Un saludo.
Una d las partes mas complicadas n la programacion es el filtrado d los datos d entrada (uno d mis profesores d programacion solia probar nuestras aplicaciones pegandole un manotazo al teclado, a ver q pasaba, si estaba bien hecho no tenia por q hacer nada al no ser validos los datos d entrada.)
El desbordamiento d buffer es basicamente eso, la saturacion de un buffer d la aplicacion (normalmente el d entrada d datos aunq depende d la aplicacion) bien sea intencionadamente o accidentalmente.
El resultado, es muy variable, aunq mayoritariamente hay dos consecuencias, una vez saturado el buffer d entrada d datos no es capaz d filtrar los comandos q recibe y ejecuta lo q sea segun lo recibe, incluyendo codigo arbitrario/malicioso. Otras veces sencillamente revienta la aplicacion, q si se trata d un firewall o un servicio vital deja el culo al aire.
No obstante la definicion q mencionas del mapa d memoria no es 100% aplicable, si bien la memoria qda mas o menos como dices los sistemas operativos modernos ejecutan las aplicaciones n areas separadas para q un error n una no afecte a las vecinas. Los "buffers desbordables" son mas bien lo q dice freebsd, o vectores (arrays unidimensionales) o tablas.
Creo que con lo del mapa de memoria te refieres a que tanto windows como linux y otros sistemas utilizan un esquema de memoria protegida para evitar que una aplicacion escriba en el sepacio de memoria de otra, pero en el tema del buffer overflow no tiene ninguna importancia, por que la memoria que se sobreescribe es la del propio programa, no hace falta que un buffer overflow afecte a el espacio de memoria de otra aplicacion distinta de a la que se le esta intentando llevar a cabo el ataque, asi que la protecion de memoria no sirve para evitar el buffer overflow, es mas, da exactamente igual.
En cuanto a si es posible o no que se vea afectado un array, sea unidimensional o multdimensional tampoco estoy de acuerdo, un buffer overflow se puede ejecutar incluso contra una variable cualquiera, a condicion de que despues de el espacio reservado para la variable, exista codigo ejecutable y el programa no verifique la longitud de los datos a insertar en la variable.
Un saludo.
La ejecucion n areas d memoria protegidas valida la integridad del codigo tb (es por donde identifica al programa) si algo machacase el codigo del programa n memoria automaticamente el sistema lo quita d memoria (a veces n linux qdan procesos zombies). Lo q dices solamente serviria para hacer reventar el programa sin mas, la gracia d los exploits por desbordamiento es forzar al programa a q haga (o no haga) cosas a tu voluntad, y para es imprescindible q no se pisotee a si mismo, si se inutiliza ya no sirve d nada.
Cuando fuerzas una variable provocas un error d tipo (asignar como int cuando deberia ser longint y darle un valor muy alto) al no caber da un mensaje d error pero eso no es un desbordamiento d buffer.
Yo he hecho mis "pinitos" programando tanto en C, como en el duro ensamblandor. No se puede evitar el overflow comprobando la longitud de los datos que le llegan al programa? Para asi impedir escribir en memoria más de la cuenta ?
Saludos
Si pese a ser uno de los fallos mas extendidos es tambien uno de los mas faciles de solucionar.
Lo que pasa es que como en cualquier programa tienes un monton de rutinas a las que se le pasan datos, es un exploit muy facil de encontrar.
un saludo.
Editado.
Perdon, no queria pisar a lofter, pensaba que lo habias preguntado al hilo del post mio.
Mil disculpas a los dos.
Asi podrias filtrar los accidentales, pero si alguien hace un debbug del programa buscando por donde se le puede desbordar, antes o despues cae (vease el ie xD)
Siempre te puedes despistar con los tamaños, aparte de asignar mal los tamaños por error sucede con las cadenas de texto que si no estan terminadas en '\0' se comportan de manera distinta a lo esperado.
La siguiente cadena no esta bien terminada:
char txt[4] = {'h', 'o', 'l', 'a' };
Si ahora hago esto:
char buffer[10];
strcpy(buffer, txt);
Es posible que buffer se desborde, aunque buffer mide 10 y aparentemente txt solo mide 4, si en las posiciones siguientes a txt no hay ningun caracter de fin de cadena '\0' la cadena podria medir incluso varios kb efectivos. Strcpy copia caracteres de txt a buffer hasta que encuentre un caracter de fin de cadena, por eso a veces es recomendable usar strNcpy, que no pasa de un determinado limite al copiar.
