🚀 go-pugleaf

On Wed, 10 May 2006 12:31:22 +0200, arrase <arrase@gulcas.org> wrote:

>En la red hay un monton de documetacion sobre que es un buff overflow,
>como explotarlo, como evitarlo,..... pero hay algo que no encuentro,
>�que justificacion tecnica tiene su existencia?
>
>Las principales funciones que son susceptibles de producir overflow son
>de sobra conocidas, impletar una comprobacion de tama�os de los buffer a
> tratar no supondia un cambio en su interface, solo en su comportamiento
>interno.

Yo creo que te equivocas, en muchas funciones es imposible
comprobar el tama�o de un buffer sin cambiar su interface,
ya que una funcion que lleva como par�metro un puntero a 
un buffer (que ser� de entrada) y no lleva un par�metro
que indique su tama�o, no tiene modo de comprobar el
tama�o real del buffer.

Saludos :-)           -Pedro-

  http://www.maicas.net/ 

  e-mail en www.maicas.net

Hola arrase <arrase@gulcas.org>
el Wed, 10 May 2006 12:31:22 +0200 escribiste:

> En la red hay un monton de documetacion sobre que es un buff overflow,
> como explotarlo, como evitarlo,..... pero hay algo que no encuentro,
> ¿que justificacion tecnica tiene su existencia?

Es una consecuencia de la manera en que se utilizan los punteros en C.
Las razones para disponer de un tipo de datos de alto nivel que
represente una dirección de memoria sin imponerle más restricciones
es que a bajo nivel dichas direcciones existen, y algunos lenguajes
aspiran a poder manejarlas directamente, lo cual resulta imprescindible
para programar según qué cosas (acceder directamente al hardware,
por ejemplo).

> Las principales funciones que son susceptibles de producir overflow son
> de sobra conocidas, impletar una comprobacion de tamaños de los buffer a
>  tratar no supondia un cambio en su interface, solo en su comportamiento
> interno.

Esas funciones a las que te refieres no pueden conocer el tamaño real
del buffer a menos que la aplicación les informe de ello. Compara
las funciones sprintf y snprintf en printf(3).

> A si que, teniendo en cuenta que ya estamos en el 2006, ¿por que el buff
> overflow sigue existiendo?¿Para darle emocion a la vida?

Será que la Historia no puede borrarse de un plumazo.

-- 
Gonzalo Pérez de Olaguer Córdoba <gpoc@iies.es>
PGP key 2861C704 --- F206 5671 6789 425D 111C  1302 214F 1934 2861 C704

Gonzalo P�rez de Olaguer C�rdoba wrote:
> Hola arrase <arrase@gulcas.org>
> el Wed, 10 May 2006 12:31:22 +0200 escribiste:
> 
>> En la red hay un monton de documetacion sobre que es un buff overflow,
>> como explotarlo, como evitarlo,..... pero hay algo que no encuentro,
>> �que justificacion tecnica tiene su existencia?
> 
> Es una consecuencia de la manera en que se utilizan los punteros en C.
> Las razones para disponer de un tipo de datos de alto nivel que
> represente una direcci�n de memoria sin imponerle m�s restricciones
> es que a bajo nivel dichas direcciones existen, y algunos lenguajes
> aspiran a poder manejarlas directamente, lo cual resulta imprescindible
> para programar seg�n qu� cosas (acceder directamente al hardware,
> por ejemplo).
> 

Este es el tipo de respuesta que esperaba, muchas gracias :).

>> Las principales funciones que son susceptibles de producir overflow son
>> de sobra conocidas, impletar una comprobacion de tama�os de los buffer a
>>  tratar no supondia un cambio en su interface, solo en su comportamiento
>> interno.
> 
> Esas funciones a las que te refieres no pueden conocer el tama�o real
> del buffer a menos que la aplicaci�n les informe de ello. Compara
> las funciones sprintf y snprintf en printf(3).
> 
>> A si que, teniendo en cuenta que ya estamos en el 2006, �por que el buff
>> overflow sigue existiendo?�Para darle emocion a la vida?
> 
> Ser� que la Historia no puede borrarse de un plumazo.
> 


-- 
<arrase@gulcas.org><http://arrase.no-ip.org><www.gulcas.org>
     <Gnupg Keys: http://arrase.no-ip.org/pubkey.txt>

print "".join(map(lambda numChar:filter(lambda x:(x<"0") or \
(x>"9"),numChar),["0"+chr(104)+"0","1"+chr(111)+"1","2"+chr(108)+"2", \
"3"+chr(97)+"3","4"+chr(32)+"4","5"+chr(109)+"5","6"+chr(117)+"6", \
"7"+chr(110)+"7","8"+chr(100)+"8","9"+chr(111)+"9"]))

Pedro Maicas wrote:
> 
> Yo creo que te equivocas, en muchas funciones es imposible
> comprobar el tama�o de un buffer sin cambiar su interface,
> ya que una funcion que lleva como par�metro un puntero a 
> un buffer (que ser� de entrada) y no lleva un par�metro
> que indique su tama�o, no tiene modo de comprobar el
> tama�o real del buffer.
> 
> Saludos :-)           -Pedro-

Es cierto, ha raiz de esta respuesta he preguntado a Jack, de Gulcas.org
y dado razones tecnicas de ello:


 Imposible del todo.
 Si reservas un buffer de 10 bytes, puedes, en C, hacer buffer[2]=23
 o buffer[100000]=42 ya que C solo se limita a pillar &buffer o &buffer[0]
 y sumarle el tama�o de un elemento x el elemento que solicitas...
 en el caso que la direcci�n calculada no tenga privilegios de acceso
 da un bonito segmentation fault, sino se sobreescribe sin m�s.
 Haz un programa simple, y estudia la pila con el gdb, no hay ninguna
 info referente a cu�nto ocupan los buffers (vectores), es m�s, C solo
 se preocupa en reservarte el tama�o que le pidas, lo que luego pase es
 cosa tuya... bueno, almenos en los vectores reservados "est�ticamente",
 es decir, sin malloc.

Tambien encuentro interesante este otro comentario de Jack:

.....el buffer overflow es una t�cnica un poco pasada de moda a ra�z de
la llegada del kernel 2.6.11 que introduce aleatorizaci�n en las
direcciones de la pila del ejecutable, por lo que es casi imposible
acertar en que direcci�n reside el EIP... aunque tambi�n hay t�cnicas
para acertarlo....

...La aleatorizaci�n tiene un rango de 8 MB.....



Saludetes.


-- 
<arrase@gulcas.org><http://arrase.no-ip.org><www.gulcas.org>
     <Gnupg Keys: http://arrase.no-ip.org/pubkey.txt>

print "".join(map(lambda numChar:filter(lambda x:(x<"0") or \
(x>"9"),numChar),["0"+chr(104)+"0","1"+chr(111)+"1","2"+chr(108)+"2", \
"3"+chr(97)+"3","4"+chr(32)+"4","5"+chr(109)+"5","6"+chr(117)+"6", \
"7"+chr(110)+"7","8"+chr(100)+"8","9"+chr(111)+"9"]))

Pedro Maicas wrote:
> On Wed, 10 May 2006 12:31:22 +0200, arrase <arrase@gulcas.org> wrote:
> 
>> En la red hay un monton de documetacion sobre que es un buff overflow,
>> como explotarlo, como evitarlo,..... pero hay algo que no encuentro,
>> �que justificacion tecnica tiene su existencia?
>>
>> Las principales funciones que son susceptibles de producir overflow son
>> de sobra conocidas, impletar una comprobacion de tama�os de los buffer a
>> tratar no supondia un cambio en su interface, solo en su comportamiento
>> interno.
> 
> Yo creo que te equivocas, en muchas funciones es imposible
> comprobar el tama�o de un buffer sin cambiar su interface,
> ya que una funcion que lleva como par�metro un puntero a 
> un buffer (que ser� de entrada) y no lleva un par�metro
> que indique su tama�o, no tiene modo de comprobar el
> tama�o real del buffer.
> 
> Saludos :-)           -Pedro-
> 
>   http://www.maicas.net/ 
> 
>   e-mail en www.maicas.net

Bueno, por lo visto existe otra manera de hacer que una aplicacion
casque cuando intenta sobrepasar el tama�o de un buffer y no implica
modificar todas las interfaces para que se les pase el tama�o del
buffer, un ejemplo del empleo de este metodo se puede ver con efence -
Electric Fence Malloc Debugger

Esta es su documentacion:

http://www.die.net/doc/linux/man/man3/efence.3.html

Claro que este metodo implica un mayor uso de memoria y no es algo
general pero la verdad me ha parecido curioso el tema de delimitar
buffers con areas de memoria inaccesibles

Saludos


-- 
<arrase@gulcas.org><http://arrase.no-ip.org><www.gulcas.org>
     <Gnupg Keys: http://arrase.no-ip.org/pubkey.txt>

print "".join(map(lambda numChar:filter(lambda x:(x<"0") or \
(x>"9"),numChar),["0"+chr(104)+"0","1"+chr(111)+"1","2"+chr(108)+"2", \
"3"+chr(97)+"3","4"+chr(32)+"4","5"+chr(109)+"5","6"+chr(117)+"6", \
"7"+chr(110)+"7","8"+chr(100)+"8","9"+chr(111)+"9"]))