🚀 go-pugleaf

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