🚀 go-pugleaf

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"]))