🚀 go-pugleaf

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